A well defined UX process is key to getting the right result in product design. Without a deep understanding of the users we can't design a product that fits their needs.
Please read below to find out more about my design process.
Discovery / Research Phase
1.
Understand the problem / user research
Hold workshops with key stakeholders to determine what the problem is we are solving first, getting details from the product team to determine next route for investigation.
At this point we can reach out to users with surveys / interviews to gather insights to drive the design direction.
Use data to define/update archetypes. Set the scene, look at user goals, behaviours, and pain points all framed around a problem or common theme.
Mental models are essential tool for UX as you can see the problem through the users’ eyes and unveil insights.
All gathered data can be organised into affinity maps to identify common themes of feedback and create actionable items for the design process.
2.
Competitive analysis
It’s essential to know the market that the product is operating in. What is our the position in the market? Who are the main / indirect competitors? What is the competitive edge? This is all important for validating the business reasons behind the work.
As well as defining strengths / weaknesses this research can be used to build a UX strategy, learn from others’ failures, and find patterns and solutions to similar problems.
3.
Summarise research and plan
All research is gathered, clear directions of design have become apparent and now we can focus on what are the key design outcomes for this body of work.
A simple problem statement can then be defined that clearly and concisely illustrates the perceived outcomes of the work.
The work can be divided into sprint-size chunks with tickets created, then the design work can commence.
4.
Define workflows / user journeys
Build out workflow diagrams to cover all possible scenarios for the items that have been identified through the research stage. This maps out the user journey and considers the different routes and road blocks the user can encounter during their experience.
This can be presented to the stakeholders for verifying that it meets technical / business requirements.
Ideation Phase
5.
Low resolution designs / wireframing
Start with low res designs through sketching / wire framing etc. The main focus at this stage is layout, content and the main user workflows. If working with a design system it is a preference to use a wireframe kit that matches the design system components for accurate representation and easy transfer to high resolution designs.
Continuous feedback from stakeholders is key at this stage to ensure designs match the product vision and business requirements as well as satisfying user requirements.
6.
High Resolution Designs
After the wireframes have been validated with the stakeholders , the designs can start to a be brought up to design system standards. Being an advocate of reusable design I strive to use components and design system components as much as possible so maintenance is easier for amendments / future revisions.
7.
User Testing / Prototypes
Either low or high resolution designs can be brought in at this stage, depending on how comfortable the users are with wireframes. Work with users to test the features, asking questions to gain further understanding of the effectiveness and any issues the users are having. Refine the designs based on feedback, and reiterate until there is a viable solution.
Delivery Phase
8.
Developer Handoff
The designs have been validated and are ready for passing on to the developers. All flows will be built out and documented with callouts for any information that is unobvious in static designs. Sometimes prototypes will be provided for solutions requiring deep interactivity.
Patterns are established or updated where they have been part of the process. These tend to be presented in a more anatomical format and provide a lot more detail about the behaviours / inner elements. Patterns will get referred to in designs to remove duplication and additional maintenance.
9.
Design Reviews
I prefer to build a design review into the developer process where possible so I can assist the process and ensure quality delivered at release time. It would be common practice to have a design review at the end of the developer cycle (post peer code reviews). The objective is to provide feedback on everything from sizing, alignment issues to improvements in flows and interactions.
10.
Continuous Improvement
Once a feature is in the wild we can get a clear indication of how well it is performing and gather further insights. Monitoring usage for the next 12 weeks and reaching out to focus groups for feedback can bring new insights and routes for improvements which should be addressed at the next available opportunity.