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
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
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 provides 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 (albeit, just not using the same presentation layer)
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
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