By This is the second in a series of posts about the development of any user-centered service. The first post was about the discovery phase. This post is about the alpha phase.
Experiment
The alpha phase is all about experimentation. Its main output is one or more potential solutions to a problem.
So imagine we were asked to come up with a solution to a problem. Naturally, our first question is going to be: what is the problem?
That’s why the alpha phase needs inputs from the discovery phase which define the problem.
Inputs like:
- proto-personas or personas – who are we dealing with?
- user stories – what do those people want?
- storyboards, scenarios, user journeys/wireflows – what are those people trying to do? What does the business want them to achieve?
- sitemaps – What is the structure of the problem space?
So, we have a problem definition. Our potential solutions to that problem should be things like a proof of concept, wireframe, paper prototype, or in fact anything which people can see or use.
Users and stakeholders should get a feel for what the proposed solution is going to look like. And as developers we should be able to get useful feedback from users about our proposed solutions.
Whatever the actual output, the idea is that we can test our potential solution very quickly with users.
No babies!
Come up with several different ideas early on. Test them on users. Get feedback.
Get used to throwing ideas away. You do not want to become attached to a particular solution or prototype because it’s your “baby”. Do not feel like the solution is something that you’ve invested lots of time into and which will be a personal affront to you if users or stakeholders don’t like it.
This is in fact a highly Agile approach.
We don’t have endless feature lists.
We get stakeholder and user feedback very quickly.
We build prototypes for features which people actually want, not what they said they wanted in a boardroom meeting 3 months ago.
Method
There are all kinds of things you can use in the alpha phase. What you choose depends very much on how much time you have and how complex the problem is. But some things you might want to try are:
- sketching and sketch games
- paper prototyping
- wireframes – can be very basic or relatively sophisticated
- mobilify design game – useful for working out key navigation areas
- KJ technique – a technique for using other people’s ideas to feed your own
- guerilla testing
The point is… do anything that is quick, collaborative, and involves users.
You’ll probably find some of your own techniques based on your group dynamics and problem space.
The alpha phase need not be a lengthy process. Certainly a sprint, perhaps two or three for bigger projects. It’s light, quick, and very much led by user and business needs.
Outputs
The outputs for the alpha phase are:
- decision to progress to the beta phase. The decision may already have been taken by senior management, although the alpha phase may have highlighted technical limitations which have a cost implication to that decision.
- high level (‘epic’) story cards. We got plenty of user feedback, so we should have plenty of stories about what users need.
- working basic system that provides limited functionality that can be shown to a number of users.
It’s ok to build a working prototype if you have the technical tools available. For example some people find it useful to build a working web page with frameworks like Bootstrap.
Personally I’d recommend against getting too far into technical solutions unless you’re really certain that you’ve found an ideal solution very quickly. For one thing, getting something too shiny too early on may convince your stakeholders that you are much nearer your ideal solution than you actually are. This raises hopes and expectations, and kind of digs an unnecessary hole for yourself.
Summary
The alpha phase follows the discovery phase. It requires a good definition of the problem space: user needs, business needs, scenarios, and personas.
The idea behind the alpha phase is to experiment and rapidly develop some kind of tangible prototype(s) that we can test with users, and get their feedback.
Stay clear of technical detail if at all possible. That’s the job of beta phase development.