My UX Process

My UX process is made of 10 steps and follows the structure of the Double Diamond. I keep it a bit generic as I tailor it for each specific project and its constraints. Its steps are not set in stone, and it could align with the product owner role too, expanding the scope to cover technical specifications and release notes.

Writing my UX Process down helps me in situations, such as job interviews when you’re asked: “what is your UX process?”; or when starting a project with people new to UX and they are keen to know what will happen; or what your plan is at a high level. Listing the steps of my process brings clarity to the stakeholders and guides me to start planning the activities ahead.

The ten steps are:
1. Establish hypothesis/goal
2. Research Plan
3. Research Execution
4. Analysis
5. Present results / Align strategy
6. Prototyping & Testing
7. Define specifications
8. Development guiding
9. Testing & Fixes
10.Release

1- Establish Hypothesis / Goal

This step is to understand the business goal of the project and the driving factors. Who are the stakeholders? What are the assumptions guiding the goal?

If you are working in a “traditional” environment, there is probably a business case or project plan of what needs to be done.

For this step, what is important to me is understanding the goal, getting the team out of “solution mode”, and getting the stakeholders into an open-minded state.

In many cases, the original goal might not be the best thing to do, depending on the research results. That’s why it is important to differentiate the goal from “the solution” or “the how-to”.

Establish that we will go to the research to validate the goal or explore other possible solutions.

2 — Plan Research

This step is to see which people or users are the best to reach [SC1] [BC2] and how to get to them. Define what type of research method to use, etc.

At this point, I usually get asked how many people I will need to reach for the research. When the information about the project is limited, my default or minimum numbers are for a survey, at least 30 completed surveys and five for interviews.

Additionally, in this step, I would investigate what other resources are available. For example, tech support usually is a good source of information, such as know issues, pain points, common problems and other data. Tech support data can also help with key performance indicators (KPIs). For example, if a fix or new feature can reduce downtime of a system, that measure can be converted into a dollar value that can support investment in UX.

Gathering knowledge of known issues or previous work, or people that might be working on similar things is paramount[BC3] to success. If the project will bring about some changes, it is best to engage with the people inside the organisation that might be impacted, as I will need their support to make things happen.

A key factor is to engage with people that can help with communication (there is never a thing like over-communication), marketing or branding if required. I would also want any new UI or colours to be aligned with the latest organisation guidelines to avoid future objections.

3 — Execute Research

After the research plan is approved, it is time to execute the research. When doing interviews, five is the maximum number of interviews per day, I would recommend.
It is very common that the time required for research is not included in project plans or is perceived as a delay. A good practice is to establish an email list of people, (depending on the case, internal or external users), who would like to participate in UX research activities that you can reach out to quickly.

4 — Analysis

In this step, I always aim for stakeholders to help with some part of the analysis. Their collaboration is part of bringing them along the journey to acceptance and advocacy . The activity I might ask for assistance with could be something as simple as grouping user responses into similar categories. When the stakeholders collaborate on the analysis, or synthesis of the findings, they get a sneak preview and start sensing what will be shown when the findings report is presented.

Stakeholder collaboration in the analysis works as a warm-up. It means the results/findings will not be a complete surprise to them. They also have more time to process the results of the research. Most importantly, they will be more easily persuaded to make adjustments to the project’s goal.

5 — Present Results / Align strategy

At this point, I show the slides with the results/findings and recommendations, which I share with the stakeholders along with the associated records. But it is at this point; I get confirmation if the project’s original goal will be the best path forward or whether the shared recommendations to adjust the goal to take into consideration the insight from the research is the right path to follow.

Having the stakeholders as part of the analysis in the previous step makes the conversation about adjusting the project’s goals much more effortless.

6 — Prototyping and Testing

For prototyping and testing, the more cycles of prototyping and testing, the better. The process of building and testing help with polishing and battle proofing the design.
I consider what I want to achieve from the testing and the prototype when choosing how to build the prototype. The prototype can start with a low-fidelity prototype if I don’t want the users to get distracted with colours and visuals.

I can even start without visuals as Card Sorting exercises can be a good starting point to define menu navigation elements.
The work I did in step 2 comes in handy for high-fidelity prototypes, so whatever I design, I make sure I follow the design system or branding guidelines.

The point here is to build a prototype that is ‘fit for purpose’, which allows me to best opportunity to test the design and make adjustments based on user feedback.

7 — Define specifications

At this point, I usually would work with a business analyst or someone with technical knowledge to describe and write the specifications of the application/feature that will be delivered to the developers.

One image or video can be worth more than 1000 words, so the images and prototype made in the previous step become very handy to illustrate or even animate the specifications.

8 — Development Guiding

In many cases, what I have designed in the prototypes can’t be developed exactly as planned in production. There can be many reasons for this; e.g. not having the resource to do it, budget constraints, technical debt etc. But my personal philosophy is that there is always something that can be done to improve current state.

During development, I might not have time to go back to the users for additional validation research; while the developers wait. Time is money, as they say, and decisions need to be taken fast. As the UX designer representing the user’s voice, I would decide what I think would be the best out of the options available.

The importance of steps 1 and 5, having clarity on the goal of the project, and steps 2 and 4, gaining knowledge of the users’ current experience, is what enables me to make quick, informed decisions with the development team that align with the project goal.

9 — Testing and Fixes

Compared to the prototype testing, the difference here is that, we are using what would become the real product in an environment closer to the real deal.
In this step, I would carry out usability testing and work with quality assurance to check that any displayed data is correct, testing smaller values, bigger values, edge cases, and make sure that blank states are working correctly.
The fixes required can be: reporting bugs or adjusting the design for unexpected situations that usually appear when using real data and design for unknown edge cases.

10 — Release

The release step is about communication. Once the feature or product is ready for production and users, it’s time to let them know the feature or update is ready for use and how to access it or activate it if necessary.
The communication can include different outwards channels; sending release notes via a newsletter, social media, or marketing campaigns (if required).
Communication also includes internal channels and support material, like updating ‘help’ material, and offering online training or recorded videos on how to use the new feature(s).

Where possible it is good to get in touch with users that requested the new feature to let them know it is now available or include evidence that the feature developed has taken into consideration the feedback from users as this show responsiveness and builds ‘early adoption’ for the users.
Depending on the size of the team or organisation, the communication tasks could be done by other teams. It is still good practice to engage with all communication efforts to ensure that the new feature’s value and technical details are communicated correctly.

Remember, communication is a two-way street. It is an excellent time to capture feedback from users about the new feature and any measurements that can help with the KPIs, like increased usage or reduced delay/availability periods.

Conclusion

What all the steps share is communication. The interaction with different audiences at different levels. Communicating the high level strategies to minor details like the colour of a button. Each step is about bringing everybody along the journey and keeping everyone on the same page.

A UX designer would be like the glue that allows different teams to work together. This process guides me, and each step builds on the built understanding of the previous step. Taking the time and care of each step will help a UX project to succeed.