Government Digital Service Design (GDS)
The famous British government service design principles are a design approach driven by user needs, including user research in every phase of the product development.
The different phases of product development
Discovery phase: discover user groups & user needs
The discovery phase should start with a problem statement workshop to get alignment on what problem you are trying to solve. You will also define what success looks like and, if possible, how you would measure success (success metrics). With an assumption mapping exercise, you will get an overview of what you know about your users and how sure you are about it. This exercise will help you with creating the research plan and the research questions.
In discovery, you will not create a prototype. You will collect data and conduct research to explore your user groups and their motivations, goals, needs, and pain points. You might research competitor products/services.
At the end of discovery, you should clearly know your user group(s), their needs and what you should build. To summarise that knowledge, you can create personas and lists of prioritised and categorised user needs.
For the next phase, alpha, you need to decide what to focus on. You should define your alpha goals. Usually, you will concentrate on the most important user groups and their most urgent needs. It can pose a risk when the scope of alpha is too broad. When you think about the double diamond: After going broad in discovery, you need to narrow it down at the end of discovery.
Typical activities in discovery
- Problem statement workshop (the Five Whys technique)
- Assumption mapping
- Stakeholder interviews
- Review of existing research
- Social listening, any existing user feedback
- User interviews
- Field studies (contextual research, call centre listening, etc.)
- Requirements & constraints gathering
- Competitor analysis or research
Alpha phase: Iterate on a prototype & get user feedback
In alpha, you start creating the product/service. You develop a prototype and iterate on it. The prototype can be paper-based or consist of screenshots, even PowerPoint slides. More advanced prototypes are designed with Figma, InVision, Marvel, or Sketch.
You will have several rounds of research and improve the prototype iteratively, step by step. At the same time, you are increasing your knowledge about your users. You can try different concepts and variations with your users. You should avoid focusing on one specific solution too early.
Suppose there are still missing gaps from the discovery phase. In that case, you can continue exploring these and adding to your knowledge about your users (e.g., when you haven't managed to do research with some target groups in discovery).
At the end of alpha, you have a validated prototype (often called MVP, Minimum Viable Product - I like to call it Minimum Valuable Product). You can take this prototype into development in beta. The user needs you discovered in both discovery and alpha should be the basis for the user stories for development. Often a BA - Business Analyst - is writing the user stories. As a researcher, you have to make sure every user story is based on a real user need.
Typical activities in alpha
- Journey mapping (what do users do, think, feel in each step of the user journey, what are opportunities for the product/service)
- Task analysis
- 'How might we….' exercise (brainstorming how to solve user problems)
- Prototype creation
- Design reviews with the team
- Content reviews (subject-matter-expert input, e.g., when legal content)
- Iterative usability testing with a prototype (several rounds)
- Continue with persona building (refine and update, add new knowledge about users and their needs)
- Card sorting (information architecture)
- Accessibility evaluation
- Mapping user needs to user stories
Beta phase: Test your service with a larger audience
In beta, the actual product/service is already built. You will collect feedback from a larger group of people using the product. The product can be already live as a beta version, or selected users get a beta version of the software to test it and give feedback. In beta, it is important to collect feedback over an extended time period to get insights about product usage from newbies (onboarding and learning) to expert or power users (efficient use). Some beta research is similar to a diary study.
The purpose of collecting feedback in beta is to iron out usability issues or bugs. In this phase, you ensure that when the product goes live, it will give users a smooth experience.
You have already found out earlier in discovery and alpha about your target groups and how your product solves their problems. Therefore, in beta, you will not make any major changes regarding the concept, only minor tweaks. The product should already address the most important user needs and pain points; it should solve the problem from your problem statement at the beginning of discovery. You will check whether you have achieved the success metrics you defined at the beginning of the project (what does success look like).
At the end of beta, you should have removed all remaining usability issues and bugs so the product can go live.
Typical activities in beta
- Longitudinal study/diary study
- Analytics review
- Search-log analysis
- Usability-bug review
- Frequently-asked-questions (FAQ) review
Live phase: Continuously get user feedback & improve
A live product/service doesn't mean the end of user research! User research and product/service improvement are continuous activities. Research in this phase is similar to beta research, but you will have much more long-term data to analyse. You should continue to track and analyse any success metrics you have defined in the earlier product phases.
Some companies track the NPS score for customer satisfaction. You can also analyse Google Analytics data or data from tools like Hotjar. You might be able to see trends and patterns in the data. You can also analyse user feedback from online forums or app stores. Some organisations (like the government) have a feedback option directly on the service page.
Typical activities in live
- Analytics review
- AB testing
- Social listening
- Feedback from online forums, app stores
- Feedback from customer surveys or NPS score
- Data from tools like Hotjar
The double diamond
The double diamond is a simple model of the design process which is also the underlying basis of the different phases of product development:
The process starts by questioning the challenge and quickly leads to research to identify user needs.
The second phase is to make sense of the findings, understanding how user needs and the problem align. The result is to create a design brief which clearly defines the challenge based on these insights.
The third phase concentrates on developing, testing and refining multiple potential solutions.
The final phase involves selecting a single solution that works and preparing it for launch.
Source: The Double Diamond: A universally accepted depiction of the design process, Jonathan Ball, 2019. Read more about the story of the double diamond from the famous British Design Council!
The Nielsen Norman Group UX Research Cheat Sheet
The UX Research Cheat Sheet by Susan Farrell, 2017, gives a good overview of methods and activities in the different product and service development phases.