Wireframes vs Mockups and Why you should Sketch with Words first — Design 101

In a Design 101 session of a 7 week design curriculum that I lead, a question came up asking what the difference was between wireframes and mockups. While the question itself can be answered quickly addressing only the ‘what’, if you get into the ‘why’ to use one over another — this is where it gets complicated and insightful, especially in the government context.
The “What” of wireframes and mockups
While wireframes and mockups are different, many non-designers and professionals alike can sometimes use these words interchangeably to mean a prototype. If we want to be accurate, however, there are some key differences.
Wireframes
Wireframes are just that — containers for actual content. They are generally low-fidelity, meaning they do not have too much detail or convey a specific look-and-feel.
They could be very simple.

They could include multiple options.

Or they could represent many moving parts and pieces.

Mockups
Mockups are a lot more realistic. They might include branding elements, templates and actual content. You might not be able to distinguish a mockup from a real, live thing it is meant to represent.

The “Why” of wireframes and mockups
In over 5 years of working in the design arena in the Government, I’ve seen wireframes and mockups play many different roles. I’ve seen projects miserably fail because a mockup method was chosen to get a quick commitment to a direction and I’ve seen some flourish when the same method was used. So there is not one quick rule, but there are definitely a few insights that I’ve observed in the process.
Why use a wireframe?
Wireframes are fast to produce and don’t require a lot of expert skills. You could draw a sketch on a napkin, you could use a fancy tool like paid Balsamiq etc. or free version of Mockingbird or something basic you have at hand like PowerPoint. Quick to produce means you can pivot and respond effectively to any changing priorities or new insights.
If done right, trimming design back to the very basics of frames, allows the team to focus on what truly matters — the actual content, discussions around user needs, structure, messaging.
Presenting ideas and framing solutions in a wireframe format could also prevent stakeholders from getting too attached to a ‘specific look-and-feel of a solution’ — the Achilles heel of any design challenge. Moreover, if long term partnership and sustainability of the design are important in your project (as they should be, most of the time), sharing wireframes rather than shiny mockups with your partners communicates to them that this is still a ‘work in progress’ and that they are welcome to contribute to it, without needing to be a ‘design expert’. Jared Spool has aptly summarized this point in his recent article To Show the Value of UX, We Must Show the Work of UX, where he states:
UX design leaders include their peers and stakeholders in the design process. They don’t just wait until the end of their design process to show them their final work product. They use a variety of techniques to open up their process to others on the teams.
There are certainly some downsides to using wireframes. The main challenge is when a designer thinks that the simplicity of the medium = simplicity of reflection and effort. In other words, if the thought process that goes into creating a wireframe has not been rigorous, the wireframe can be a barrier in the design process and miss important information. This can happen for example when there is an overreliance on lorem ipsum (filler text) rather than real content, missing true problems to solve. To avoid this, you need to practice content-first design; an amazing place to start is with this comprehensive article Content First, Design Second: Prototyping with Words and Adobe XD:
In order to create the most usable interfaces, content can’t be an afterthought — words alone can define the experience of an app or website.
Another challenge is that it might be more difficult to get buy-in from your stakeholders with something that is not as polished and visually impressive. A colleague from the Nova Scotia government, Beth Fox contributed the following reflection on the topic
It was difficult to get people used to the idea of presenting wireframes to share concepts or seek approval (especially with senior decision makers)… There was a fear of showing something “unfinished and rough”. What we’ve found though, is that in the early rounds, it actually helps reinforce the idea that we might not be correct. And our investment is low on purpose, because it’s easier to change.
I personally have found wireframing in iterative loops to be a really valuable tool to get some of the assumptions out of the heads of various stakeholders.Now it’s become normalized and we rarely get complaints about the “sketch” nature of wireframes.

Why use a mockup?
Mockups are often there to impress. They will get everyone talking and excited about the output. They are polished, “shiny objects” that make it easier to get buy-in from reluctant stakeholders.
But this quick buy-in comes with a number of disadvantages. The mockup takes longer to produce, making everyone, including the designer, more attached to what is in it. The stakeholders may find the mockup so appealing (as it may represent their point of view , ensure they are the first area in the organization to have a new ‘look’ or cross-off some other checkbox exercise) that it would make changing the design as a result of new insights very difficult.
Not only can a mockup jeopardize the usability of the whole project, but it can also reinforce the general cultural misconception that design is about ‘looking good’ rather than whether it is functional and helpful.
It could also turn your partners against you, as you would be perceived as showing them what looks like a finished solution without likely involving them in the process.
Finally, high-fidelity prototyping used at an early stage of a design process could create a misconception about the design work being completed and undermine resourcing and support that you may need to actually realize the design (or to do the research necessary to test the assumptions). A learner in the course summed it up well by saying, it can give “the wrong impression that something is built or it is closer to done than it really is”.

So what should you choose? — Start with words!
I think my bias towards wireframes is showing!
Don’t get me wrong, I’ve seen the biggest step towards a more user-centred transformation of internal government services on an intranet with 200,000 pages of content happen thanks to a mockup and the persuasive storytelling of my talented colleague Chad. But most people are not Chads.
Also, personally, my most successful experiences have been forging partnerships through the most unpretentious of wireframes, using tables in Microsoft Word, and I am pretty proud of that (apparently, I am not alone, as others in the industry have been promoting sketching with words and storyframing).

What worked for one person and one situation is unlikely going to work for you; there are just too many human nuances that could tip the scale.
So when deciding which method to use — wireframes or mockups or both, be strategic and consider:
- Your objectives
- Your stakeholders
- Your partners
- The nature of the content you are working with
- Where you are in the design process and which one would be most effective and, potentially, less risky
If the above does not help, then think of design as a conversation:
- What prototyping method will ignite and encourage conversation?
- Which one might put an end to it?
At the end of the day, prototypes are stories, so sketch with words. Content-first design sets you up for success early on and let the content determine the shape of the design (it will do all the decision-making for you!).

Try out sketching with words and storyframing first and see where it leads you!
