We’ve written before about things to consider when designing in alpha. One thing we have not talked about in detail is how important it is for designers to think - even at the alpha stage - about how the service they’re working on will be delivered.
It’s easy when you’re prototyping to create a service with all the features users could possibly want. But doing this is not much value if the technology cannot deliver it, or other constraints mean it’s not feasible.
It’s important, when testing approaches in alpha, to make sure you’re designing to deliver the most value as early as possible. Otherwise you’re compounding the problems you’ll face in later phases and you’ll create a waterfall specification.
Here are some things to consider that might prevent you from designing in a vacuum in alpha.
Make your prototypes practical
Alphas should allow a team to be open with their approach to meeting user needs. It’s good to test a range of ways to solve a problem. However, openness sometimes leads teams to feel they can design without considering the technical practicalities.
In alpha your prototypes do not need to work technically. For example, it might be fine to fake notifications, because you know it will be easy use a service like GOV.UK Notify to integrate with easily, as it has a technically proven track record.
However, problems that aren’t solved in alpha need solving in beta. If a problem is missed because it was hidden in the prototype, solving it later can be much harder. In beta you’re generally working to a much tighter timeframe and have less scope to make changes to how the service will work.
Prototype as a team
The Service Manual says the alpha stage is the time to:
- build prototypes of your service
- test your prototypes with users
- demonstrate that the service you want to build is technically possible
This does not mean the design and technical work are separate.
Teams can sometimes treat them as separate things because:
- the technology aspects of the service are being developed by a supplier who is not integrated well with the team
- designers do not seek for technical input into prototypes
- developers do not know how to input into a design
It’s important for designers to make sure they’re working as closely as possible with technical members of the team (or with external suppliers).
It’s good in the early stages of an alpha to prototype using quick and simple methods. But the way you’ll meet some needs cannot always be understood in a sketch or in simple HTML. More realistic prototypes, especially if they contain real data, force you to think about problems in detail and give more authentic results.
Design simple to deliver early
Alphas are difficult because lots of what you learn is only indicative of the user’s experience. Because of this you should design the simplest solution to meet the user’s needs. Adding complexity means it’ll take longer to have impact and delay the learning you gain from a beta or live service.
Use prototyping to find the simplest set of features that work for your users.
If you’re committed to a tight deadline and find a solution that requires more complex development, this generally means that one or a mix of the following is likely to happen:
- research and design on other problems get sacrificed to find a solution that does not incur more development work
- other features are cut to build the more complex solution
- a version of that solution gets built that may require additional rework in the future
This is why it’s so important to think about the feasibility of the thing you’re designing early on.
Find the constraints
In alpha you need to have a good understanding of the constraints around your service and know how they can be removed or handled. Not all constraints are technical and they will vary from service to service. They could be legal, organisational, something specific to your users, or any number of things. Alphas are the best time to discover and examine them.
Designers are responsible for making sure our work has impact and delivers value sooner. They can do this by finding the simplest solution and proving it works. To minimise potential implementation issues, try to understand the constraints you’re designing with and work closely with your team. A team that communicates well will produce the best work.
Follow Ralph on Twitter and remember to sign up for email alerts.
