Alpha and beta. Are we learning enough?

Alpha. The service design phase that excites designers the most.

We’ve done research in discovery to understand the problems we need to solve. Now we have the freedom to explore our ideas for solving them.

We make quick, cheap prototypes, and test them with the people we think need our service. We expect the first things we make won’t be the right things. We throw lots away. But we don’t worry. By testing early, we fail fast, learn more about the problem, and figure out how best to solve it.

The discovery continues with each iteration of the prototype and with each creation of a new prototype. When to stop iterating a prototype and create a new one? When you stop learning anything new from the people you ask to use it.

So alpha should be a period of great freedom for service design teams. But it doesn’t always work out that way.

Too often we restrict our ideas, worse yet, dismiss them entirely without testing with users.

I often hear people ask how something we’ve prototyped will work with current processes or technology?

The answer is often the same: it won’t.

But if we’re serious about delivering better services (I believe we are), we should accept that processes and technology need designing too. They shouldn’t become constraints to the design process.

Prototyping and gaining feedback from users is quick and cheap. But replacing legacy technology and processes takes longer. Often it will require significant investment.

There’s a danger in selecting only the design that most easily fits with these constraints. We might miss the opportunity to prove in beta the service that best meets our users’ needs.

I think we should approach beta differently.

We should build and release to a small number of users the service we’ve seen (from research) best meets their needs.

I think we should build only enough supporting technology and processes to run the service for this small group. We shouldn’t worry initially about automation and whether the technology we’ve built will scale.

Most importantly, we should measure the value of what we’ve built. Value to the user in meeting their needs, and value in how successful it helps us achieve business outcomes.

If we’ve succeeded in proving value, we’re then left with the need to scale the service to be used by more people. For that we may well need to invest more in technology and automation. But by proving the value of the service first, we can better justify that investment.