UX Process
The mission of a UX architect is to help people understand and intuitivley navigate the cyberspace of a given project, while delivering a unique and appropriate style that gives meaning and structure to it's content.
Creating an experience that logically flows and enables utilization with minimal onboarding.
I use the UX principles in a series of steps that make up the UX design process
use the sidebar to learn more about these UX process steps
- Collect requirements
- Empathize - understand the user
- Understand - the project goals
Discovery is where I find out all I can about the project from its initial conception. These initial notes are taken very hastily, as I conduct an interview about the requirements and goals.
It is important to know who the end user will be to empathize with and divine what is the most efficient organization of the data at hand. What does this user want to do? How can we make the experience good for that user?
The result of completing this stage should be a full understanding of the project from the point of view of the client as well as the intended users.
- Research
- Observe
- identify any troublesome items
- User Flow
Defining the project is to organize the data and findings into a tangible structure. At this point, I am primarily focused on functionality and content parameters.
If applicable, I will research existing similar apps, and their users. For upgrading current apps, I observe usage and flow of the OG apps and conduct interviews to find problems and successes of the UI.
I will evaluate all my findings and create an exhaustive list of all parts of the project. I separate items into screens/pages and define a rudimentary user-flow for the app. It is important to break the list into core functionality components that are relative to the development plan while still understandable to the client.
I will use the outline to consult with the client and ensure we have included all requested items. Before I discuss with the client, I make sure to consolidate functions and formulate the most streamlined outline of all necessary features as I understand it.
Now it's time to meet with the client and confirm all the details of the initial outline. If anything is incorrect, missing, or unnecessary, we can make edits to this list. I will refine the list until the client accepts it. Through these meetings, I can also get some feedback from the client regarding the next step.
- Brainstorm
- Sketch
- Iterate
- Wireframing
Now its time to flesh out some ideas about the app's layout and look. Keeping in mind the client's requested style for the app, this step is as much about visually representing the various sections of the outline plan, as it is to visualize the functionality and data structure.
With the eventual goal of packaging the whole app in a cohesive theme package, we brainstorm and notate ideas about project. While we Ideate, any and all ideas are welcome and will be sketched or mocked up regardless of their validity or potential. Most ideas are not good, but even the worst ideas can have an element of genius that is worth preserving or recycling into another idea.
It is now on the UX Architect to quickly identify the rubbish from the gems, and to recognize the potential of individual elements. Items that don't make the cut are archived. The remaining items are then expanded upon as we iterate these idea seedlings into less abstract schematics and wireframes that can be represented well enough to show the client.
- Layout
- Color Scheme
- Fonts and Typography
- Make Decisions
- Produce initial assets
Up until now, our idea and the app are in flux, anything can still change, and not many decisions have likely been made about specific details, as the focus has been on the overall project and its potential in several different directions. Now it's time to get into the details and make decisions to go one way or another. We will now use the wireframe plans to guide the design of high-fidelity renderings. Fonts, and colors will be injected, and enough graphical assets will be produced for the design to accurately represent an example app screen. Up to three variations of the same screen are created, evaluated, and iterated before presenting to the client for feedback. We will repeat this process until the client accepts a single set of fonts, colors, and layout styles. Now we can expand on the theme and generate a UI kit and color list to be used in making subsequent layouts and screens. The app has taken on a distinct look and feel by this point, and we want to make sure the client is pleased with the direction the design has grown in. Any discrepancies or contingencies are dealt with until we are left with a single clear aesthetic that we all agree on. All major layout and page variations are to be produced with the prevailing theme aesthetics and approved by the client before proceeding to the next step.
- Mockups
- User Flow
- Interactions
- Implementations Details
The Prototype brings the app to life! Select sections, screens, or blocks of the app are given limited functionality, interaction. A prototype is built to look like the finished product, including asset pixel dimensions, font point-size, and screen viewport size. No coding decisions need be made yet, as we use a layout tool, like Adobe XD or Figma to build the example screens that include a set of interactions, such as, navigation links, hover effects, tabs, or other types of IU.
A much clearer vision provided by the Prototype shows of how all the parts fit together and removes any ambiguity that may still exist in the minute details. The prototype can be shared with stakeholders to comment on and test its usage and flow. We can edit and iterate the prototype quickly and easily until it has the exact specs desired within a browser or device.
Since it is not built with any specific codebase, the Prototype is nonadaptive regarding screen size, it is browser agnostic, and it is non-font reliant. This means that we can be sure that viewers are seeing exactly what the designer is seeing as it will look and function the same on any device. Of course, if you are looking at the widescreen prototype on a tiny screen mobile device, or vice-versa, it won't adapt aside from scaling the entire object to fit, but the aspect ratio of elements and layout will remain consistent.
- User Testing
- Reevaluate
- Find Improvements
- Determine tech needs
Now that we have partially functioning example of the app, we can do some usability testing and see how it is perceived to the intended audience. First, the designer will evaluate usability and attempt to eliminate foreseeable issues. Then the client should be able to view and click through the Prototype to give feedback on the project's accuracy regarding the overall vision.
As this is not a fully-featured example, it will be shared with a limited number of testers along with the information on the functioning elements to be tested, and what else to expect - or not expect. We want to get feedback on the usability of the app controls and UI, so it is important to clarify the Prototype's scope to reduce responses regarding functionality intentionally omitted.
Upon receiving feedback from user testing, we will make improvements and republish the prototype to be tested further. If necessary, we will create additional screen sizes or functionality to be tested. Once everything is approved; we are ready to start building.
While the design team may continue to flesh out the rest of the pages and sizes, it's time to give the developers a place to start. Using all the info gathered thus far, we can determine the best tech stack to provide the core functionality and write a dev plan appropriate to the project.
- Dev Environment
- Code - html/css/js/php, etc.
- Database and Content Management
- Services and Network
Using the mockups and prototype as a guide, it is time to start building the app. We will determine the tech and services needed, such as server hosting, database, code compatibility, or api connections. The dev plan is tailored to the specific tech and needs of the project, and then split into individual sections.
A staging development environment is set up to begin building. From the dev plan, elements of the project are assigned to the appropriate specialists. Using GIT, and other collaboration tools, devs can simultaneously build and update elements at the staging directory without stepping on each other's toes.
Using a combination of HTML, CSS, JS, and PHP, we can build virtually anything you can dream of and keep compatibility throughout any type of device. While we are adept in using a variety of programming languages and techniques, we will attempt to select the best language for the job while also considering its longevity.
Whether we use other conventions, like: REACT, C#, or COBOL, is determined by the platform and implemented when required or otherwise desired. Resources are optimized, minified and compressed to get the best performance possible. The app on the staging site can be shared and tested to a wider audience than the prototype, and more feedback is always appreciated.
Once the application on the staging site has been finished, tested, and tweaked, it's time to GO LIVE! We can move the site to the proper URL, or move the APP to the app store, etc.
Like art, an app is never actually completed, it is either constantly being tweaked and maintained, or it is abandoned. As your app hits the market and real users are enjoying your idea, (isn't that a great feeling?) You will inevitably find more things you want to do with the app. Maybe you find some fixes, maybe you want to remove something that now seems superfluous, or maybe you just thought of another feature to add. Its all part of app development, it never ends, its like your seedling that you have now grown into a small tree, and, well, you want it to keep growing, because when it stops being nurtured, it dies - such as the old websites that have not updated their scripts in years will be riddled with errors and terrible Search Results.