https://gds.blog.gov.uk/2014/06/03/principles-for-prototyping/

Principles for prototyping

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.

Concept principles
Concept principles

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.

Show, don't tell
Show, don't tell

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.

Take the easy things as read. Tackle difficult problems for real.
Take the easy things as read. Tackle difficult problems for real.

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.

Then there are parts which people worry will be complicated or need hard work to make simple. Build those parts for real. Make sure you have time to put your prototype in front of users and iterate.

Copy, cheat, steal like an artist
Copy, cheat, steal like an artist

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.

build for the future
Build for the future (with thanks to Marshall McLuhan)

A concept is the perfect place to experiment and demonstrate the future.

You need to go where the hamsters are!
You need to go where the hamsters are!

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.