Phase 4: alpha

Alpha phase

Alpha is the fourth User Centred Design (UCD) phase and the second of the delivery phases.

What Alpha is not

Alpha is not about building a working service - it shouldn’t be perceived as building ‘phase one’ of the Beta.
Alpha is not about validating what users like and dislike - your success measures should be focussed on how well prototypes meet users’ actual needs.

Don’t constrain prototyping ideas based on current business, technical or time constraints. Think big and explore a vision for the future, that way you can validate if the effort to implement this over time will be worthwhile.

Why do we need the Alpha phase?

The aim of this phase is to test your hypotheses by building prototypes and exploring different ideas to meet your users’ needs. Alpha ensures the team builds the right thing the right way before actually building it as making changes to a fully functioning live service can be a costly exercise.

What happens in the Alpha phase?

To ensure the right thing is built during Alpha:

Be bold with service design, challenge traditional approaches to solving user needs, and quickly validate them with user research.
Be ok with (and highly recommend) throwing away prototypes you build when you decide the final approach.
Establish the team’s delivery approach and ways of working.
Apply the user centred, cross-functional and multi-disciplinary principles from the Discovery phase when making the prototypes.
Form a routine of continuously building, collaborating and testing new ideas around prototypes.
Regularly present your findings to stakeholders.
From what you learn, define the future vision for the service – what a real solution could look like to users. A solution that works across the boundaries of agencies or tiers of government.
Scope the Minimum Viable Product (MVP) – the smallest thing you can build that meets user needs. The MVP will set out the scope of what is built in Beta.

How long does the Alpha phase last?

Typically, Alpha takes five weeks.

Starting the Alpha phase

Before starting Alpha, re-visit the Discovery phase to ensure there are well-defined, quantified hypotheses.

It is best if the existing Discovery team continue to work on Alpha - keeping the existing empathy, context and momentum within the team. See Building a UCD Team to obtain the resources required for this phase.

With an already-established team from Discovery, kick-off for Alpha should be shorter and simpler. For example, you’re likely to continue performing the same team rituals, like retrospectives and planning, and you will already have a good idea of roles and responsibilities.

Duration	Participants	Objectives
1 day	All team members	Restate the user needs and hypotheses formulated by the team in the Discovery phase.
		Determine the overall success criteria for the Alpha phase (and the key milestones along the way).
		Determine the development approach to building prototypes, and how user stories will be worked on, reviewed and completed.
		Determine what ‘good’ looks like for the prototypes that are built (e.g. accessibility, design patterns, code quality).
		Create a rough plan for user research throughout the Alpha phase, and continue feedback loops from the research findings.
		Determine the stakeholders involved, and how the team will share progress updates.
		Determine how the technology stack for the Beta phase will be chosen, and who needs to be involved in the discussions.
		Determine what ‘done’ looks like. This will make it easier for pieces of work to be accepted by the product manager. A recommendation is that 'done' is when changes to the prototype reflect insights from your user research.

Alpha teams should take a similar approach to Discovery, adhering to agile techniques and practices, working in weekly sprints, with daily stand-ups and regular retrospectives. For more information see Working in Agile.

During Alpha, user stories will be introduced to guide prototype development. User stories are a way of defining and prioritising user requirements. For more information see Defining User Stories.

As teams move from Discovery into Alpha, they will make greater use of the team wall to track work-in-progress. Your wall needs to be kept up-to-date each day to give the team greater clarity on progress.

What is a prototype?

The term ‘prototype’ can be interpreted in many ways. A prototype in the context of building digital services is a high-fidelity mock-up of a potential user journey.

A good prototype:

looks and feels like a real (digital) service
provides a seamless user experience along the ‘happy path’
uses familiar design patterns
includes content and data that looks real
responds with alerts and feedback in the right places.

Of course, a prototype shouldn’t be functionally complete - build only the journeys and use cases that you need to test.

Show the thing

The best way to quickly challenge assumptions and begin to tailor your prototype to the real needs of users is to ‘stop talking and start doing’ - make your concepts and theories tangible, and test them.

This is also really important because it:

creates a common understanding of what you’re aiming for
helps eliminate confusion or misunderstanding within the team
enables you to get back in front of the user to find out what’s relevant to them
will boost you out of theory and into practice.

Start sketching in code as soon as possible

It is fine to start sketching out ideas for a user journey on paper - it can be an easy way of thinking through solutions to a design problem. However, it is important that these paper sketches move to sketches in code, or mimic what the initial solution could look like as soon as possible, to quickly test out the idea to see if it works.

Build for mobile devices first

If the prototype is digital then it is important to understand that a greater proportion of users are accessing government services from mobile devices than ever before. Taking a mobile-first approach to building prototypes means that more user research can be performed in a realistic context.

The constraints of the smaller screen size means that services designed to be mobile-first are simpler, with only one or two things on each page. When scaled-up to larger screen sizes, the simpler service design is easier for everyone to use.

Tools and technology

When choosing the technology for building prototypes, you should choose lightweight tools that allow for quick experimentation and rapid validation of the hypothesis. Technology should not be a blocker in prototyping a potential user journey, no matter how radical.

If the prototype is digital, then all teams should prototype by sketching in code, using HTML, CSS and JavaScript. Be careful not to use tools that don’t support a collaborative, multi-disciplinary working environment.

Testing prototypes

Thorough testing of your concepts and prototypes is critical to choosing the best approach for Beta.

Concept testing

In the early stages of testing, you should focus on testing concepts, not interfaces. This kind of testing could equally be described as ‘hypothesis-led research’, and it’s very similar to the research done in Discovery. However, this time you also have some concepts to share with your users, in the form of a prototype.

In concept testing, you’re looking to answer these kind of questions:

Does this validate our hypothesis?
Is the problem really a problem?
Does this solve the users' underlying problem?
How well does your concept solve the problem? Does it go far enough?

User testing

As your prototype progresses in fidelity and you’re increasingly confident that you’re solving the right problem in the right way, you’ll move into user testing. This testing is less about the concept and more about the execution.

When talking to users, follow a script which is focussed on how useful the concept is, not whether users like it or not. Don’t expect users to give you direct or straightforward answers to your questions, you’ll need to read between the lines. For further information, follow the guide for User Research.

After some initial questions to find out more about the person and their prior experience with your service, place the prototype pages/website/sketches, etc. in front of them. Give the participant a series of scenarios to navigate, and observe what they do with the prototype.

Ask your participants to:

navigate the prototype as if they were using it in their own environment and observe how they interact with it (e.g. did they get frustrated, show that they understood how to use it. If the prototype is digital, did they click where you expected them too?)
speak their thoughts out loud so you can have a deeper understanding of what motivates their decisions.

If possible, the note taker should write notes on post-its, this will make things easier in the analysis stage.

After interviewing, make some time to go through your notes and transfer them to post-its (if you haven’t already). This is also a good time to add any further notes that may have been missed during the session.

Analysis of user testing

Create a profile for each user. If you have a photo of them, attach it to your wall along with any post-it notes that relate to the person’s situation and experience. This is particularly important for members of your team that were not involved in the research as it allows them to develop empathy for the situation of those users.

Place the prototypes used in your research in order, on your wall. For example, if the prototype is a website then take screen shots of each page; if it’s a new process, print each stage.
Stick the post-it notes created during your research sessions against each of the prototype screens that they relate to.
Group the post-it notes for each screen shot/page into themes and affinity map them.
Prioritise the areas that need most attention and work with your team to find solutions to these problems.
Iterate the prototype based on the prioritisation.

Finishing Alpha

By the end of Alpha, you will need to have defined your Minimum Viable Product (MVP).

Eric Ries describes the MVP as “a version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time" (Eric Ries, The Lean Startup, 2011, page 77).

You should start with the vision you’ve been prototyping and validating throughout Alpha. The MVP should be the first step that delivers value towards that vision.

A Minimum Viable Product:

provides value to users - it actually helps get something done
may focus on the specific needs of only a subset of users
works end-to-end along the ‘happy path’ (or ‘steel thread’).

We recommend you de-scope generic functionality like user registration, business rules engines or content management systems, as these can quickly inflate the size of the MVP and are not critical to building the service. Instead, just choose the simplest approach that meets the user need.

At the end of Alpha your team should be confident that you still meet the first three criteria of the Digital Service Standard. Progress also needs to be demonstrated against all other criteria.

Understand user needs. Research to develop a deep knowledge of the users and their context for using the service.
Establish a sustainable multi-disciplinary team to design, build, operate and iterate the service, led by an experienced product manager with decision-making responsibility.
Design and build the product using the service design and delivery process, taking an agile and user centred approach.

The Digital Service Standard Kanban poster will help teams to track the activities and artefacts as they occur, demonstrating how the team is meeting the Standard.

Example of the Digital Service Standard kanban board in use.