All our projects begin with discovery, a short phase in which we start researching the needs of users, understand the things we'll need to measure to improve the service, and explore technology and other constraints.
Discovery usually involves workshops, whiteboards, paper-prototypes and index cards. Sometimes, though, these simple tools aren't enough to build agreement within the team, or understand the shape of the alpha phase.
We recently spent six weeks working on a Land Registry concept to experiment with, and learn from users. With such a short amount of time available we needed to keep the team focussed, so we came up with some general principles for prototyping.
The first, and probably most important principle is to show the thing. How often does a group appear to reach a consensus when, in reality, each person has a different understanding of what they've agreed to?
A working prototype reduces risk of misunderstanding, and is a more powerful way of explaining how the real service will actually work than the most detailed of documents or beautiful slideshow.
With a short period of time available you should ruthlessly prioritise what you actually make. There will always be bits people assume to be easy, such as accounting or logging in. Take those as read.
Working with open source and the web means we don’t need to reinvent the wheel, design new wheels, or often make a wheel, and certainly during prototyping need to buy wheels. Open source software and web services are strange things in that they increase in value the more people who use them, so we can in good conscience steal each other’s wheels.
A concept is the perfect place to experiment and demonstrate the future.
But, we should never ignore the needs of our users. It’s definitely not OK to create a vision and declare “build it and they’ll come”.
You can assemble the most futuristic and inviting hamster cage in your bedroom but hamsters will never spontaneously appear. You need to go where the hamsters are.