Alpha phase

The alpha phase is about testing hypotheses and experimenting. The purpose of alpha is to determine how to best meet the user needs that you identified in discovery.

Alpha gives you the opportunity to quickly test many different approaches with users before actually building a service so you can find and fix potential issues before investing too much time and money into one design.

The same team that worked in the discovery phase should continue to work in alpha phase. This keeps the existing empathy, context and momentum. Depending on the service you are building you may need to add roles for completing alpha such as a business analyst, technical architect and agile coach.

Turn insights into design

Building and testing multiple concepts and hypotheses is a great way to determine what solution will best meet user needs. This will help identify potential issues while there is still time to make corrections.

Work in design sprints

It can be difficult to know how to transition from discovery to alpha. Taking research insights and turning them into prototypes can often feel overwhelming. Design sprints provide a structured way to bridge the gap between research and design.

A design sprint is a short one- to two-week process for solving important business or design challenges. It includes a series of brainstorming activities that results in a prototyped solution that is tested with real users – all within the span of a week!

During a design sprint the team will:

sketch – explore potential design solutions through a series of individual and group brainstorming activities
decide – select a single option to move on to testing
prototype – create a simple prototype to test the chosen solution
test – test the prototype with real end-users and get their feedback
share – share the week's work with decision makers and stakeholders

It's important that all team members take part in a design sprint. This is not an exercise that designers should complete alone. Developers, subject matter experts and content designers all have a valuable role to play in the process.

You can learn more about design sprints from Google Ventures.

Co-create with users

Co-creation means designing services directly with users as opposed to designing services for users. It's based on the belief that users are essential to the design process and know best what will meet their needs.

Co-creation can drastically condense project timelines because, by bringing users and stakeholders together, you can get instant feedback and make on-the-spot decisions.

This approach sparks conversation between people that don't often interact. Beyond uncovering new insights, co-creation helps participants understand each other's motivations and creates shared empathy between service providers and users.

Prototype and test ideas

Prototypes are physical, experimental versions of a service that are used to get user feedback on ideas and concepts before building the service.

Prototypes only need to be realistic enough to get meaningful feedback. The goal is to test how well the proposed design solves user problems, not to showcase a polished or finished product. Prototyping can be done with:

simple paper sketches
interactive digital mock-ups that mimic a working website
physical models of a product or service made with Lego or cardboard boxes
role playing activities or simulations

Usability testing is a common method of testing prototypes with real users. Participants are asked to interact with the proposed service and complete a series of tasks while observers watch, listen and take notes. This helps to identify potential design issues and gather constructive feedback that can help inform the next iteration of the design.

Making sure everyone can use your service

With an online prototype, you can't apply the full range of technical accessibility tests you'd use for production code. But at alpha, you should be able to show that you:

understand the WCAG accessibility principles – this will help you identify and test any specific accessibility challenges you're likely to face with your service
are inclusive of people with disability in your user research

You don't have to get an accessibility audit at alpha, but it's worth starting to think about it because they can take time to arrange. And if you appoint your auditor during alpha, they can review your alpha designs or prototypes for potential accessibility problems giving you plenty of time to fix things.

Either way, by the end of alpha you should have a plan for how you're going to tackle accessibility at beta.

Inclusive design means better design for all

Anyone can find it hard to use a product or service - these barriers can be temporary, situational or permanent. These all create needs that can be met by accessibility features – which is why we should build them in by default and make them easy to find.

Throughout alpha don't just approach accessibility as meeting a minimum mandated standard, but work to understand how your service will be used by people with different needs or contexts.

Beyond accessibility, you should also be able to show that you've considered inclusion in the wider sense.

Share the service vision

Government services are complicated. There is often much more involved in creating a successful service or policy than what you can include in your prototype.

Documenting a clear service vision helps create alignment on the details of the proposed solution and what the team will need to make it a reality.

Our UX design methods guide will provide you with some common tools to help you capture a service vision. You may need to use more than one to fully capture your proposed approach.

Some methods you might use include:

Method	Description	Purpose
Annotated prototypes	Prototypes that include brief notes or comments that explain the rationale behind features and design choices.	Help give context behind decisions and reminds team members why specific design elements were selected.
Storyboards	Sequential images showing the main interactions or events that take place throughout a service.	Help team members and stakeholders visualize the intended user experience.
Future-state service blueprint	A diagram that visualizes a new process or service and how the organization's internal processes, people, systems and policies will support it.	Helps organizations understand what will be needed for a successful implementation.
User stories	Short sentences written from the perspective of users, describing their need and the reason behind it. Example: as a <type of user>, I want <some need> so that <some reason>.	Help document the different needs that a service must address, shifting the focus from creating detailed requirements to discussing user needs within a specific context.

Completing alpha

All services are different, but most projects need 8-12 weeks to complete alpha.

By the end of 'alpha', expect to have:

thoroughly tested prototypes that show the design of the service
a clear vision for the service that will be built in beta
a plan and prioritised list of features to be completed in beta
a clear understanding of how the service will need to be supported

After completing alpha, it may make the most sense to stop and not continue to beta. Don't consider stopping at this point a failure – it's better to stop building a service that won't work before spending more resources.

Consider stopping the development of a service if alpha indicates:

there is no user need for the service
policy, technology, financial or other constraints will prevent the service from meeting user needs
adapting or developing another service is a better option

If you need to stop, it might be best to go back to discovery or restart at alpha. Though it may feel like a setback, the lessons you've learned will improve the quality of the final service.

This content is based on Ontario.ca's Service design playbook and GOV.UK's How the alpha phase works guide (licensed under the Creative Commons Attribution 4.0 Licence).