Prototypes are for learning. Wireframes are for teaching

As a service designer, you spend half your working life engaged with people who have deep technical knowledge – developers, UX designers, solutions architects and so on – and the other half with people who know little or nothing about what it takes to design, build and maintain a successful digital service.

So it’s probably not surprising that language from one of those domains leaches into the other. Which is fine, but not without its issues.

One area where it does cause problems is the difference between a prototype and a wireframe. So this post is an attempt to clear that up.

What is a prototype?

A prototype is a low-cost throwaway thing we can put in front of users and learn something about a particular problem we’re looking to solve.

It can be as simple as a sketch, if we’re testing a very early-stage concept.

You can draw it on a whiteboard, or on paper with sharpies.

Hell, use crayons.

The rougher your idea, the lower the fidelity of your prototype should be. Detail like colours, fonts and so on merely distracts users at this stage. Focus on the problem. Get it in front of users.

If you’re using a whiteboard, encourage your users to change it. Or bin it and provide their own solution.

Congratulations. You are now co-creating.

Stepping up

Once you’re confident-ish your idea has legs, you can start thinking a bit more about detail.

How should we position components? We know proximity affects human perception, but how, exactly, in this case?

You can also start to think about thing like colours, fonts, typography …

You should also really, really start to think about language right now. Don’t fall into the “Oh, it’s just content, we can do that later” trap.

How you label things, what you call things, and your calls to action are going to be the most critical points in your UI. Start now to understand what those words should be. Because they might be *a word*.

Save. Submit. Send. Next. Exit. Approve. Cancel. Done.

Those words mean very different things to your users in different contexts. If you don’t understand that, your design will fail them.

So don’t use lorem ipsum. Develop proper UX copy. You don’t want cognitive dissonance getting in the way at this stage.

The good news is you can now start prototyping in higher fidelity.

That doesn’t mean you need to use digital tools. If you’re creative and handy enough, you can continue with interactive paper.

And if you’re not comfortable with that, go ahead and use digital tools.

Just use what works. We’re solving a problem, not refining a dogma.

In the past, I’ve used:

• Paper (not an app, just actual paper)
• Whiteboards
• Axure
• Sketch
• Miro
• PowerPoint
• Keynote
• XD
• Axure
• FIgma
• HTML, CSS and JavaScript

The point is: it really doesn’t matter. Just talk to people. Ask them to do tasks they regularly do. Observe them.

Use whatever tool you need to do the job.

If you need detailed feedback about how users will actually interact with a thing, use XD or Axure or html to make a thing they can actually interact with if you really need to understand that behaviour.

What is a wireframe

A wireframe is a different beast.

It’s a design specification handed to developers at a specific point to say: start building this.

It omits significant details. Like colour, images, fonts. These things are unimportant at the scale of a page layout.

So the wireframe focuses on what goes where, and the relationships between them.

It might look like this.

Its purpose is not to learn; it is to teach developers so they can build the right thing, and build the thing right.

A wireframe is an artefact used to stimulate conversations. In conjunction with a user story, it helps us to relay the intention of the design.

They don’t have to be interactive; they just need to relay specific information to the folks building the thing.

This component goes here. It has this width and height, an <h2>, an image, a paragraph and a CTA.

By all means, annotate your wireframes. Especially with accessibility concerns, like specifying label and placeholder text as separate design considerations.