Different prototyping methods and how i use them

There are lots of different ways of creating and using prototypes. Over the years i’ve used various different techniques and choosing the right one is often based on the two things; the audience who’s seeing it and the outcome i’m aiming for.

Drawings: focus on the right thing

  • Quick to make and build consensus amongst the team in a short period of time
  • Useful abstraction as no one gets attached to the presentation and helps aim for the bigger picture.  The low fidelity helps us focus on outcomes not outputs and influences how people are problem solving.
  • Takes us away from the screen – physically moving things/changing the order can help change mindset
  • They act as useful internal marketing material, so anyone can view / bump into them
My terrible handwriting and drawings

How this evolved during the recent pandemic

The pandemic saw everyone working from home so sketches had to evolve. During this time I relied much more on an online whiteboarding tool called Miro. Here you can create sketches in the browser, and share a publicly accessible URL with colleagues. This worked surprisingly well because:

  • Anyone can view the thing whenever they want to (this is when you find out that Adrian the developer works best at 3am)
  • What you’re doing gets a wider stakeholder audience (because the drawing isn’t hidden in a corner of the office)
  • Because the tool isn’t a graphics package, the emphasis is always low fidelity
Low fidelity sketches produced on Miro – an online whiteboarding tool.

Flow diagrams: starting deep conversations

  • They let us easily dig into the business logic behind certain requirements
  • If used correctly, they start deep conversations about the ambition and ethics of a system, ie. how does a user delete themselves and their data? What’s our obligation to hold that information if we need to provide evidence in a fraud case? Whilst this diagram never directly answers these questions, it brings these conversations into design phase – which, in my opinion, is where these conversations should belong.
  • They provide a really useful bridge between design and engineering teams
  • Helps set consistency for how design and engineering teams name parts of a system (from a user perspective but also for API documentation). For example, if the content design team have decided we’re going to call them “Users” and from a micro-copy perspective we use terms like “Add User” on buttons, the API calls in the service should match this. After all, developers are users too.
A series of flow diagrams plotting a user journey through a new Identity and Access Management (IDAM) service

Sketch / Figma: Testing content and basic UI flow

  • Very quick to produce high-fidelity visuals, helping us test things like content maps, hierarchy, spacing, font size etc.
  • Visual consistency kept by using shared assets / libraries connected to a design system
  • Simple to make rudimentary prototypes, where we need to test simple journeys and content or micro copy
  • Preview and run in browser, so good for remote user testing (just share the link with the participant)
  • Easy to update and work with distributed teams
A series of user interface screens, with basic clickable elements

Fully interactive prototypes: testing interaction

  • Great for task and scenario testing with the intended users of the product
  • Anyone can access it through the browser via a url, and can be tested on a variety of devices
  • Simulates real life interactions, such as;
    • Buttons / fields / checkboxes / radio buttons have active, focus and hover states
    • Data that’s input get carried across different stages
    • Can use conditional logic
  • Rudimentary error and success messaging
  • Leaves little room for interpretation
An interactive prototype that runs in the browser, built using the GOV.UK Prototyping Kit