What is an Alpha Inception?

The alpha inception is where you try to understand your end state service in more detail. You also aim to identify areas of business, technical and usability risk of this end state and start to form your alpha phase team and figure out what you are going to test with users.

As in discovery, in alpha you are still learning but now you are going to be testing some proposed solutions with actual users.

An important part of the alpha process is understanding what you are trying to achieve. It is a time to regroup as a team after your discovery phase and understand more fully what your end state is. This is where the alpha inception phase comes in.

There are a number of key activities to complete in the inception.

Discovery phase retrospective

You are likely just coming out of an intensive discovery phase and there may not have been too much time to reflect on it all.

Hold a retrospective with the team so you can get input on what went well, what could have gone better and how you can improve going forward before you get into your alpha inception.

Service blueprint creation

Now is a good time to map out your best guess at what you think the end state service will look like based on your current knowledge and what you learnt in discovery.

You should try and identify:

  • The different stages each user will move through as part of their end to end journey
  • The functional or back-end requirements and capabilities you think you will need to enable those journeys
  • The business processes and resources that might need to be in place to enable it

This map will form a key part of your discussions. Tools such as storiesonboard.com can be a nice fast way to mock these up.

You can do this using post-its if you wish. However, this blueprint will be an artefact you will revisit numerous times during your alpha as you learn so it may be best to have it digitally.

Key design assumptions

Alpha inception design assumptionsWhat assumptions are you making when building out your service and prototypes? You won’t know everything yet so it is important to figure out what assumptions you are making in order to move forward.

For example, you are assuming a 3rd party supplier will be handling credit card transactions or you will only be designing for desktops. You may also decide which groups of users are included or excluded. It is good to agree as a team as to why you are making those assumptions.

Areas of risk

These are the key questions you have unresolved from your discovery or other investigations and are the main things you are looking to reduce uncertainty around in your alpha phase.

You may have user needs which need exploring further or questions around content and technology.

Use your service blueprint as a guide to help you locate these risk areas.

GDS recommends that you map these out into three distinct categories:

  • Usability risk – e.g. how do we make identify verification easy?
  • Technical risk – e.g. what infrastructure is needed or what legacy systems do we have to work around?
  • Business risk – e.g. what staff need to be in place to provide this new service or what training will they need?

There may be other types of risk here depending on what sector you are working in such as legislative, competition or so on.

You will need input from lots of different types of people for this stage whom you may not have engaged with before.

Creating a backlog and sprint plan

After identifying your risks and mapping out your initial service blueprint you can start to come up with ideas for your alpha phase backlog.

Normally this is done by identifying the areas where the team has agreed most of the risks exist and grouping them into epics, or themes to explore.

Mapping out a timeline

How long your alpha lasts will depending on a number of things:

  • The amount of things you have to explore
  • Whether you have a key milestone date to meet
  • Availability of team members
  • Other factors

The sprint runway

A useful way of visualising your alpha is to use the sprint runway technique where you aim to user test a prototype for a certain epic in a particular sprint. You then work backwards from that point to work out the activities that need to occur before to enable that to happen.

The pattern repeats as follows in each sprint:

  • Doing initial research and investigation for the lab in sprint n+2
  • Doing prototyping for the lab in sprint n+1
  • Doing the lab for the focus epic for that sprint

Begin with your proposed end date, work out the amount of sprints you can get through before that date (and their length) and then try to map out your activities using an approach similar to below:

Sprint 1 2 3 4 5
Epic 1 Investigation Prototyping User Testing
Epic 2 Investigation Prototyping User Testing
Epic 3 Investigation Prototyping User Testing

Sprint heartbeat

For some teams it can help to map out an idea of what you think the sprint may look like day to day.

A suggested plan which has worked well on projects I have worked on is as follows, you can tweak it as required. It is based on a 2 week sprint, with weekends not included.

Day 1 2 3 4 5
Activity Sprint changover Lab prep day (n) Lab testing (n) Lab analysis (n) Lab analysis (n)
Initial research (n+2) Initial research (n+2)
Day 6 7 8 9 10
Activity Ideation (n+1) Prototyping (n+1) Prototyping (n+1) Prototyping (n+1) Contingency (n)
Pub

Identifying your alpha team

Alpha phase teamOnce you have your rough sprint timeline and epics mapped you can start to understand what resources you will require to deliver it.

For instance, some epics may rely heavily on input from operations or some may be particularly research intensive. Even though you may not know the exact shape of what you will be testing you should have an informed opinion on the sort of people you may need.

We will have a full team guide in our next post on the alpha phase itself.

Common pitfalls

The inception is another intense couple of days for your team and is a time of great uncertainty which can be unnerving as the scale of the problem can seem huge.

  • Ensure the team is all familiar with the discovery phase outputs so you are all starting from the same level of understanding.
  • Keep conversations on track. By it’s nature you won’t have all the answers now. Mark points of disagreements or questions against the relevant epics and move on.

Chris Mears

Chris is co-founder of UXmentor.me. He has worked with clients such as the UK government, Just Eat & Which? with a focus on service design and transformation.