My UX Design Process

ux-process-chart
OVERVIEW

My UX design process is a continuous cycle of discovery, conceptualizing, communication, testing, and validation. The end goal is to build a digital product that satisfies users’ needs, in a way that is useful to them, and easy to understand. My process can be summarized into 5 phases:

  1. Understanding - Getting a feel for the problem space. Communicating and empathising with people involved, finding gaps that can be filled in currently available solutions.

  2. Exploration - Brainstorming and prototyping possible solutions to turn the ideas into concrete examples. Testing the general concept with users to see if it works to solve their problem.

  3. Refinement - Fleshing out the MVP into a complete product. Testing ideas that are new to the users, to catch any points that are confusing. Improve the ideas before resources are spent to develop it.

  4. Development - Coding of the product. Providing design support for the developers, and conducting the user acceptance test or beta test before the launch.

  5. Review - After the product has been launched, evaluate its effectiveness, take in feedback, re-scope these into design problems and prioritize the problems to solve. Repeat the 5 steps from the start to continually improve the product.

Note: Each project is different, and the UX process shown in the chart above is not necessarily linear. Steps may be skipped in smaller projects. There may be times that I will need to take a step back as well. For example, an early user test with a low-fidelity prototype may show that the solution fails to solve the users’ needs. This failure is not a bad thing, as it brings me closer to a good solution, by proving what not to build. However, it does mean that I may need to go back to the Understanding stage to re-define the problem.

1. Understanding
Project Brief

Start of the project. It may be a design problem from a client, or an internal project from the team or myself.

Discussion with Stakeholders

Stakeholders are people who would be interfacing with the product. This is not limited to the client themselves, but could also extend to their staff, their partners etc. The discussion is to identify requirements of the product from the stakeholders.

Research

This includes research on the context and history of the problem, competitor research, finding out if there have been similar problems and solutions, etc. The aim is to gain knowledge about the problem.

User Interviews

I conduct user interviews in order to put myself into the users' shoes. I ask general questions to understand how and when they could be using the product, and to find out if they had any suggestions on features that would be useful for them.

Project Scoping

After understanding the problem space, and the time and resources available, I collaborate with the team to determine a realistic scope for the project - what would the MVP look like, what features we could include at launch and what features would be left out till later. This scope could be reviewed later on in the project.

Estimation of Timeline

From the scope, I give a general estimation of the timeline. This includes milestones such as when the MVP testing should be complete, when the medium-fidelity prototype should be complete, when the UAT would be conducted, etc. This timeline could be adjusted later on based on testing results.

2. Exploration
User Flows/Sitemap

Before starting on the design of the individual pages, I map out the user flows and/or sitemap to determine what pages are needed to be built, and how these would be connected to each other. This would influence the content and layout of each of the pages.

Low-Fidelity Prototypes

A typical format of my low-fidelity prototypes is sketching on paper or on the whiteboard. This is mainly to capture ideas into a concrete design that the team can reference so that we are on the same page for discussions. In the early stages, the prototype is used to capture the main essence of the product; the MVP.

MVP Concept Testing

There may be one or several ideas of the MVP, at this stage it is important to bring these concepts and low-fidelity prototypes to the stakeholders and users to quickly get an idea of whether the solution is in-line with their needs and requirements.

3. Refinement
Medium-Fidelity Prototypes

At this stage, the core concept of the product should be clearly defined. The medium-fidelity prototype would look like a greyscale, clickable version of the final product, and captures all the flows and features that will be launched. Greyscale is preferred so that during user tests and discussions, we can focus on the functions instead of gravitating towards colours or styles.

User Testing on Specific Functions

Functions that are new require testing to ensure that the flow is not confusing to users. These tests can focus on just specific  functions. The users can be given specific tasks to see if they are able to complete them without assistance. Parts that confuse multiple users will need to be redesigned and tested again.

High Fidelity Prototypes

Since the flows and layouts should have been finalized in the medium-fidelity prototype, the interface design (UI) takes a larger role in this part of the project, rather than the UX. UI work is a separate process that involves deciding what emotions the product should trigger in users, then selecting the colours, fonts, and creating illustrations, etc.

User Testing on General Flow

When the final prototype is complete, a general user test is carried out to see if users understand the flow of the product. Tasks can also be set to ensure that they are able to navigate through the whole product to find what they need. It is important to test the MVP features again to make sure that the core needs of the users are still being satisfied.

4. Development
Development

The final prototype, assets and design specs are handed over to the developers. I mainly provide design support at this stage, such as clarifying certain interactions. There may also be instances where the developers finds that a certain part of the design is not feasible for implementation. In those cases, I work closely with the developers to come up with alternative designs.

User Acceptance Test

The aim of this test is twofold. One, to find and resolve bugs in the product. Two, for the client and stakeholders to do a final check to ensure that the product is able to meet the original requirements that were set out. 

Launch

The launch of the product is always an exciting time, when the design is put to the test in the real world. Teething issues and bug reports are common, even with comprehensive testing. At this stage, I provide design support in case parts of the product needs to be mocked up and changed.

5. Review
Analysis of User Data

Aggregated user data tells us a lot about how the product is used, which features are used most and least, and where users spend most time on. These data can be used to validate the assumptions we made during the design process, and if they are not what we expect, then we can look deeper into the issue and identify any problems.

Feedback

Feedback directly from the users can come in the format of contact forms, verbal comments, reviews on websites and app stores, as well as organized focus groups. These qualitative data are very useful to know what users liked or not liked, and what kind of features they would want in the product.

Iterations

With the user data and feedback, there will be a list of features and improvements to be made to the product. The team and stakeholders have to prioritise these. One way to prioritise is to place these improvements on a chart of impact vs resources needed to implement them, and identify those which have high impact, and require the least amount of resources. To work on these improvements, we start the whole design process again. 

Contact me at vivieatto@gmail.com.

Made with ❤ using Blocs.