Digital Experience Toolkit

Team for the Alpha stage  

You’ll work with the same team in the Discovery and Alpha stage. This keeps the existing empathy, context and momentum.   

You may need to add some roles and capability in the Alpha stage. Such as: 

• business analyst 
• technical architect 
• delivery manager or similar, for example, scrum master. 

What to do in Alpha 

At the start of the Alpha stage, you’ll have a good understanding of the user journey and the major stages the user takes. As your knowledge grows, you will continue to work in an agile and iterative way, updating the journey map as you learn and understand more.  

When the team has some certainty about the journey of users, create a user story map. This will help you define the minimum viable product (MVP). 

In Alpha stage, you: 

• take your hypotheses from Discovery and create high-level concepts 
• continue to develop a vision for the service using your user journey and user story map 
• create storyboards to see possible solutions 
• create prototypes to test hypotheses with users, you should explore hypotheses with different kinds of prototypes, including paper and HTML 
• complete the stage by defining the minimum viable product. 

Decision register 

The knowledge kanban board you set up in Discovery is even more important in Alpha. It will help you trace your reasons for solutions and provide evidence to guide what you will build, including: 

• an explanation of the problem 
• empathy map 
• insight map 
• results of affinity mapping 
• pain points 
• hypotheses and concepts for solutions 
• user feedback and actions 
• decisions about direction or why work on solutions stopped. 

The knowledge kanban board should be saved and stored appropriately so it is discoverable to others in your agency and can be used for future reference once Alpha is complete. 

Service performance  

In Alpha stage you will need to decide which metrics you use to track performance so that you can meet Criteria 9 – Monitor your service. To do this you should: 

• have an analyst as part of your team, or available to your team, so you can start working out how you’re going to measure service performance 
• use your hypotheses to help you define your goals and benefits 
• develop a measurement plan that starts to define the metrics your service will report on 
• clearly define the start and end points for your service 
• engage with stakeholders to raise their awareness of your measurement plan and to decide the process for signing off and publishing the metrics. 

Activities for each sprint 

Each sprint, the team should: 

• hold a short meeting to prioritise user stories  
• conduct user research with at least 5 to 6 users who are representative of actual users of the service 
• capture learnings and insights from the research findings 
• showcase or share back to stakeholders to give them visibility of the prototypes and user research 
• have a team retrospective to reflect on the sprint and capture improvements. 

This aligns with Scrum methodology and helps keep the team focused on delivering something of value to users every sprint. 

Test with different kinds of prototypes 

Alpha is all about testing a hypothesis with real users. The best way to do this is by building and testing prototypes. Alpha prototypes are like a proof of concept. A prototype will not be functionally complete. It would be wasteful to produce a finished product before making sure it captures the most important and meaningful steps the user takes. Test with users using paper or other low-fidelity prototypes first. This allows you to test assumptions and ideas quickly and cheaply before getting attached to any solutions.  

Your team will decide which prototypes, if any, will be carried forward. From there you will update the prototypes based on feedback and test again.  

As you learn from your research, you will move on to testing with more interactive, higher fidelity prototypes. 

Create a good prototype 

A good prototype has enough information for users to interact and can be quickly adapted or thrown out. You may choose to re-use some designs or components when you build in the Beta stage but never confuse a prototype with a minimum viable product. 

It’s strongly recommended that you throw away prototypes that don’t work. Don’t spend too much time building prototypes, as you will build new ones based on user feedback. 

Low fidelity prototypes 

Some examples of low-fidelity prototypes include: 

• storyboards 
• card sorting. 

Low fidelity prototypes are an excellent first step as they are inexpensive, can be quickly updated or changed and are disposable. 

High-fidelity prototypes 

High-fidelity prototypes provide greater detail on the final product including the design. They’re usually introduced once low fidelity tests have been explored and the team has a stronger idea of how a service will work. 
 
There are some known downsides to high fidelity prototypes: 

• users are more likely to comment on superficial parts of a service, like colour, design and layout, rather than the content  
• they take longer to make and update than low-fidelity prototypes 
• they may give users a false idea of how the final service will look or perform. 

Tools to create high-fidelity prototypes 

There are many tools on the market you can use to build interactive, high-fidelity prototypes. These allow you to sketch in code, using HTML, CSS and JavaScript. Others work like web-builder apps allowing you to drag and drop buttons, images and sequence out a user experience path.  

Some teams have even used slide decks with basic animation to simulate an online service.  

Whatever you choose, remember: 

• show a seamless user journey that results in a positive user experience ‘ 
• include content and data that looks real 
• respond with alerts and feedback in the right places 
• make it look and feel like a real digital service 
• use familiar design patterns. 

Don’t support every browser 

Support a specific browser or version if a group of users or stakeholders depend on it. 

Users are likely to use the prototype in a controlled environment, such as a user research lab or on a team member’s computer. This means you need to support fewer browsers than a public website. 

Test for users with accessibility needs

As part of the user research, test your prototypes with users who have accessibility needs. Test with screen reader software and other assistive technology. 

Mobile first 

More users are accessing government services using mobile devices than ever before. If you design and build for mobile first, you can test prototypes in a more realistic context. To design for mobile, you should make a simple screen, with only 1 or 2 things on each page. This means users with larger screens will also have an easier experience. 

Define the minimum viable product 

By the end of Alpha, you will have a developed the user story map in depth. The team should agree on a line across the user story map. What is above the line should reflect what is most important for the user and what the team can achieve. This will inform your minimum viable product (MVP). This is the simplest thing you can build that meets the user need. 

The minimum viable product will scope what gets built in the Beta stage. The research and testing you have been doing in Discovery and Alpha will help you make choices about the technology you will use to build it. 

Decide if you will continue to Beta

End your service at Alpha stage 

You may decide to end your service work in Alpha stage rather than continue into Beta stage. 

For example, you may find that: 

• user needs for the service are already being met by another government service or the private sector 
• it costs too much to build the service based on the number of people who will use it 
• there’s a better non-digital solution 
• adapting or developing another service is a better solution. 

Start a new Alpha stage 

At the end of Alpha, you may decide to start a new Alpha stage or even Discovery stage because you need to focus on different things.

For example, you might find a completely different user need that you want to explore through further research.