Skip to main content

Alpha

What is an aplha?#

Alpha is where we identify and try several different solutions to the problems we learnt about in discovery. We spend our time building prototypes so that we can test different ideas and explore new approaches.

Alphas do not involve iterating on our best ideas, we try lots to see what works.

During alpha we do not need to test every step of the users' journeys. Some things will be more mundane and therefore less valuable for us to test. For example, we may not want to test a login or register screen. Working this way is important as it allows us to test our riskiest assumptions and help mitigate that risk.

It is important to find the correct balance of effort versus reward when prototyping. We aim for the "Golilocks zone", enough effort so that we can test different ideas and simple enough so that it is made as a disposable prototype.

At the end of Alpha we should know which ideas we want to take forward into beta, so that we can next start delivering a quality product or service. Equally valuable will be our knowledge of what not to take forward.

How long is an alpha?#

There’s no rule on how long should be spent on an alpha but they generally take between 6 and 8 weeks. The project itself should dictate the length of time needed.

If the team feels that they are running out of things to test and they have already tested several different ideas and risks, then you may want to shorten the alpha. Conversely, if the team identifies a big problem or risk at the end of alpha, then they may extend the alpha phase so that this problem can be tackled rather than carry the risk into beta.

Why may we need an alpha?#

In most cases, there are several ways in which we can implement the technology agnostic ideas from discovery. We use this to work out the best way to do something so that we are not building a best guess in beta that can be full of assumptions and risk.

What does an alpha consist of?#

Alpha phases generally consist of multiple short closed loops that allow the team to build, test and learn multiple times. This may result in several discreet prototypes that look at and test different problems or risky areas.

We should save our prototypes and learnings so that we can know why we made the decisions we did and why things did or did not work.

We may also spend time performing tech spikes to investigate technology we may use. This allows us to:

  • check several different technologies that meet the same need
  • identify problems, constraints or quirks that we need to work with
  • understand how the technology we want to use may affect infrastructure

Alpha outputs#

At the end of alpha we should:

  • have an idea of how we may solve the whole problem for our users
  • know how this work may be used as part of a wider product or service
  • started building relationships with people responsible for technology that we want to use and those responsible for other parts of the journey that we do not directly control
  • understand the technological,legal and ethical constraints that will impact us

We may produce or refine artifacts such as:

  • problem statements based on research
  • service blueprints
  • storyboards
  • user journey maps
  • user-needs statements
  • personas
  • prototypes that explore different problems in multiple ways
  • specifications for integrations with other software or services such as APIs (application programming interfaces)