Digital Service Handbook
Prototyping is not about producing code you might use in your MVP. Instead creating a prototype is about creating just enough to test specific hypotheses.
Start with the lowest fidelity possible
Prototypes only need to be realistic enough to get meaningful feedback that you can incorporate into your next prototype.
In early design sprints, your prototypes can be
- Simple paper sketches
- Wireframes that use images to show the functional elements of your service
- Clickable mockups that mimic the functionality of your service (TODO - give an example)
Use the prototype to answer questions
Think of each prototype as a proof of concept and use it to answer these questions:
- Do you have the right solution that meets your users’ needs?
- Is your solution approach viable?
- Do the technologies exist to implement your solution?
- Do you understand how to use and/or integrate those technologies into our solution?
- Are there any parts of the solution that won’t be easy to build or change later? If so, are you comfortable moving forward despite these?
- Are there existing processes or policies that will need to change to support your service?
Mimic (rather than build exactly)
In later prototypes, you can start mimicking your service’s working logic. But this does not necessarily require back-end integration.
You’ll build the actual integrations in the beta phase. Use the alpha phase to figure out how you’ll do that from a technical perspective. And only build and test the parts of the integration critical to making decisions about how to build them.