At the Beta phase, you should
- define a minimum viable product from your successful prototype in Alpha
- build this as an accessible and secure service
- allow the public to trial the Beta alongside the existing service
- use their feedback to improve the service.
The aim of user research in the Beta phase is to test the service with likely users to make sure it meets their needs and to understand and resolve usability issues. You should make further iterations to the service based on user feedback of the Beta MVP.
You must continue to do research with a broad range of users including:
- those with limited digital access and know-how
- people with disabilities
- people for whom English is a second language
- people who use assistive technologies, such as screen readers or speech recognition software (you can do this once you start working with production code).
You should also include public servants who will both deliver and use the service.
In Beta, you can learn how well your service meets your users’ needs by:
- conducting face-to-face and remote usability tests to uncover issues
- commissioning an accessibility audit to uncover accessibility issues and decide how they will be fixed
- running private or public Beta tests of the end-to-end service with real users, including support options
- reviewing web analytics and other agreed success metrics to measure performance
- using surveys or follow-up interviews to collect detailed feedback from users.
- More about how different kinds of users experience and use your service
- Usability and accessibility issues that need fixing
- Areas for improvement.
You’ll have done enough research when you have solid evidence your service works well for users and meets their needs, including those with support and access needs.
During Beta, what your users value will have matured through testing design prototypes with them. By the end of Beta you should be able to show:
How your service has been shaped by user needs
Demonstrate how you have made changes in the service and interaction design in response to user research and usability testing. You can demonstrate this by showing how the design has changed over time, along with the research findings that have driven this change.
You have tested the system in the users’ setting with a full range of users
Use artifacts from research, for example, video clips and outcomes analysis, to show you have included those with varying needs in your research.
You also need to know how you will measure and monitor your service to ensure it is serving users well.
You are prepared for ongoing user research
Plan to continually test the system with users and have an ongoing research plan and budget to support this.
What issues you haven’t solved
Identify any significant design challenges, and outline how do you plan to tackle them.
If your design is working
Use data from real use to understand which parts of the service users are finding difficult. Design experiments to reduce friction and increase success for users.
- DTA - guide to Discovery
- DTA - guide to Alpha
- GDS blog - Doing user research in the discovery phase
- GDS blog - Understanding the problem is key to fixing it
- GDS blog - Users research not just usability
- GDS blog - User research for government services 8 strategies that worked for us
- GDS blog - How we do user research in agile teams
- GDS blog - Including users with low digital skills in user research
- GDS blog - Using prototypes in user research
- GDS blog - How designers prototype at GDS