Why and How You Should Create Wireframes With Others

I love to create wireframes with my clients and other stakeholders. However, I am aware I am probably in the minority. For many designers, wireframing with stakeholders is to be avoided because it feels like it will end with the client micromanaging the design. After all, what does the average stakeholder know about design?

Also, with such great prototyping tools out there these days, creating wireframes has somewhat fallen out of fashion, with designers instead leaning towards higher fidelity prototypes.

In this guide to wireframes, I want to show the value of creating wireframes and why you should get your stakeholders involved.

We begin by defining the difference between a wireframe and a prototype.

Wireframes vs Prototypes: What’s the Difference?

There is no universally agreed definition of the difference between wireframes and prototypes. However, it is generally accepted that wireframes are lower fidelity than prototypes. Also, wireframes are typically standalone pages, while a prototype consists of interconnected pages that can be navigated in some form.

What this means in practice is that wireframes tend to be faster to produce and require fewer design skills than prototypes.

They are often nothing more than sketches of content boxes that appear on a page. However, sometimes they are slightly higher fidelity and produced in a tool like Balsamiq.

All of this is to say that anyone can produce wireframes. That makes them an excellent tool for engaging clients and stakeholders in the creation process.

Of course, you might be wondering why you would want to include stakeholders in the first place.

Why Would I Want to Create Wireframes With Other?

More than likely you have had bad experiences in the past with clients interfering in the design process. Nothing is more frustrating than losing control of your design and then getting the blame when it doesn’t perform well.

You may have even been unfortunate enough to endure design by committee, where a group of stakeholders debate and discuss design direction, reducing you to a pixel pusher.

But the approach I am proposing will avoid either of those scenarios. It will also provide a whole host of benefits, not least of which is the fact that it will uncover design directions that might otherwise have been missed.

Wireframes Generate More Possible Approaches

When all you need is a pen, some paper and a few seconds to sketch something out, it becomes liberating. It lets you explore many more approaches than prototyping allows.

The exercises I carry out with my stakeholders and clients encourages the production of a wide variety of wireframes tackling the problem from many different angles. We produce wireframes aimed at different user groups, different levels of expertise, and with emphasis on different business objectives or brand values. The aim is to generate as many ideas as possible.

Once you have established a wide variety of approaches, you can refine, discard and combine them until you have two or three that could work.

It would be impossible to explore this number of different approaches in any other way, and it also encourages the whole team to work together.

Wireframes Encourage Team Working

Wireframing should not just be the responsibility of a designer or user experience expert; it is something everybody participates should in.

I regularly bring together designer, developer, project manager and whoever else is involved in the project to wireframe important functionality.

That is valuable because it improves team working and helping each member to understand the role of others. It is also an excellent way of breaking the waterfall model of running projects, where each team member mainly works in isolation handing off work to the next person.

These group wireframing sessions improve not only team working, but also communication.

Wireframes Improves Communication

Many organisations suffer from not involving stakeholders, such as developers early enough in the process. That leads to functionality being promised that is difficult or impossible to build. By including everybody in the wireframing process, this problem is eliminated. A developer will quickly spot issues in a wireframe that may be missed if buried in an email thread or functional specification.

That is the beauty of wireframes. Because they are visual, it is much easier to grasp what is being proposed. Specification documents and emails are okay, but they are harder to visualise, and perceptions can vary. Wireframes leave much less room for misunderstanding.

Of course, wireframes do not just improve communication with your developers. They also improve communication with all stakeholders.

Wireframes Engages Stakeholders

Engaging with stakeholders throughout a project is critical. That is especially true when it comes to design.

A stakeholder who has seen a wireframe and has been allowed to provide feedback is more likely to sign off the final design.

However, don’t stop at allowing stakeholders to provide feedback. Actively involve them in the creation of wireframes.

The more a stakeholder is involved in the creation of a design, the more a sense of ownership they have over it. The more they feel they own it, the more likely they are to approve it and even defend it to others.

Most importantly of all, they also understand the design. By getting stakeholders involved in its creation, you have a chance to educate them.

Finally, involving stakeholders flushes out issues early in the process when change is more straightforward.

Wireframes Avoids Costly Mistakes

The earlier you can identify and address issues in a digital project, the better. For a start, everybody is less attached to the direction and so is more willing to change. Also, the cost of changing things becomes progressively higher the further into a project you get.

Because wireframes are quick and easy to produce, it costs nothing to discard them and try another approach. This willingness to change makes you much more responsive to the results of user testing and feedback from stakeholders.

Also, because the developer was involved in wireframes, you can avoid costly functionality before everybody is committed to a particular path.

The same is also true when it comes to testing.

Wireframes Provide Something You Can Test

Although simple to create and basic in design, it is entirely possible to test wireframes with users to see if the fundamental approach works. Later I will cover exactly how you can do that.

However, for now, what is worth noting is that because wireframes are easy to create and produced at the very start of the design process, any test findings can be easily implemented without occurring additional costs or causing the project to slip.

Hopefully, by now, you can see the advantages of creating wireframes and doing so with your stakeholders. Now let’s look at how we can do that in practice.

How Should I Approach Creating Wireframes With Others?

First, you need to be realistic. Running a full-day workshop dedicated to wireframing will leave you and your participants exhausted. In my experience, three hours is more than enough in one sitting.

The advantage of keeping a session relatively short is you can keep the momentum going. The idea here isn’t to hammer down every detail but rather to create a direction that you can refine outside of the workshop.

You can maintain momentum by running several short exercises. Each exercise should build on the one before taking us closer to something tangible.

Remember, the workshop aims to:

• Establish any issues with the direction you intend to take.
• Make people feel included and engaged with the process.
• Educate the client and other stakeholders.
• Ensure everybody has the same vision.

It helps to go into the workshop with a list of the main pages you wish to wireframe. That frequently includes more complex or divisive pages such as the homepage, landing pages, etc.

Prioritise the list and then if you don’t get to all of the pages you have at least tackled the important ones.

With that list in hand, here are a few exercises I cycle through for each page that I need to address.

Think About Key Messaging With the Book Jacket Exercise

I usually start by working on the critical messaging that the website (or particular page) needs to communicate. It is surprising how often clients and stakeholders cannot articulate the most basic information they need to communicate. Information such as:

• What the organisation does.
• How that benefits the user.
• How it delivers on those benefits.

Instead, they want to put everything online and let the user work it out!

To address these fundamentals, I set aside the website itself for a moment and ask the stakeholders in attendance to design a book jacket.

The reason I choose a book jacket is that it has physical constraints that limit the amount of content and forces the group to prioritise.

They have to consider what goes on the front, back, spine and inside flap of the book jacket, with different regions having different prominence.

For example, the spine is about grabbing the users attention, while the cover is the main message that needs communicating and so on.

This exercise will force the group to articulate their value proposition in a prioritised, clear, manner.

The book jacket exercise is a solid starting point, but sooner or later, we need to turn our attention to the site itself.

Start by Opening the Floodgates!

I begin by getting people to suggest every element that could or should appear on a page. The idea is that you get everything out there, without worrying about how relevant or otherwise the idea is.

I do this because pretty much everybody in that room has an agenda. Stakeholders have something they want to see on that page or that they want to be promoted on the site as a whole.

If you prevent stakeholders from expressing their desires they will leave the room frustrated and so they will be less likely to support the final approach.

If it is a small group, then we do this all together with people shouting out ideas and me writing them on a whiteboard.

However, if it is a bigger session, I split them down into smaller groups and make it a competition. I encourage each group to come up with as many elements as possible that we might want to put on this particular page.

I suggest breaking down larger elements such as the header into its components (logo, navigation, search bar, etc.). The winning group gets a box of chocolates to share.

It is not unusual for a group to come up with 40+ items for any particular page, and by making it a fun exercise you prepare them for the tough decisions, they will then have to make in my next exercise — the user attention point exercise.

Focus on Cognitive Load With the User Attention Exercise

The user attention exercise is a simple one. You explain to your audience that users have limited attention.

You, therefore, assign the page you are wireframing 24 points of user attention.

Each element the group adds to the page costs one point. If they want the user to pay more attention to a particular item, then they need to give it more user attention points.

The group’s natural inclination will be to cram as many items on the page as possible, spending one or two points on each piece of content. The result is a busy design. So, when they do this, I tend to ask them which website is more useful in their opinion; Yahoo! or Google. People always pick the latter.

I then show them the two sites side by side and point out that Google has spent the vast majority of its user attention points on the search box. That typically helps people to start focusing on where they spend their points.

By the end of the exercise, you will have a clear indication of where the priority of any page should lie. However, that doesn’t mean you shouldn’t explore other approaches. For this, we use the six up exercise.

Encourage Idea Generation With the Six Up Exercise

This exercise encourages experimentation. It is an exercise people do individually, although it also works in small groups.

You take a sheet of paper and fold it in half vertically and thirds horizontally so creating six boxes.

Each person (or group) now has to create six versions of the page in question. Each little sketch will be simple but will explore different ways you could design the page.

Participants will quite easily do one or two versions but will begin to struggle after that. Coming up with six proposals will be an effort, and they may need some advice (e.g. try producing versions of the page aimed at different audiences or with emphasis on various value propositions).

There are two reasons for this exercise. First, it does occasionally uncover some interesting approaches you will not have considered. However, more importantly, it will show the stakeholders that there is no one perfect approach and that what they have in their heads is not necessarily the best one.

Notice that all of the exercises I have outlined are more about prioritising and educating than they are producing a final wireframe. Yes, the exercises will provide you with valuable content to work with, but it won’t constrain you to a particular approach. It will still fall to you to produce the final design.

However, when you do, you will find it much easier to win over stakeholders because they will have felt involved and will also be better educated. That said, some testing will further reinforce your case.

How to Test my Wireframes?

Even though a wireframe is a static image with no interaction, you can still test it with end-users. Doing so is not only a great way to flag potential issues early, but it is also a great way of building up a case to present to stakeholders for your chosen design approach.

Best of all, testing wireframes is quick and inexpensive. There are two straightforward tests you can perform, starting with a first-click test.

First-Click Test

A first click test involves asking users to indicate what they would click on to complete whatever task you are monitoring. According to research carried out by Bob Bailey and Cari Wolfson, if the first click is correct, users have an 87% chance of completing the action correctly, as opposed to just 46% if the first click was wrong.

This kind of test is ideal for quickly discovering whether users understand the navigation of the particular wireframe you are testing.

A second test you can run is called a 5-second test.

5-Second Test

As the name implies, you show the user a page for five seconds and ask them what they recalled seeing. Try to pay attention to not only what elements they remember, but also the order in which they remember them. Elements that were prominent in the user’s mind will be mentioned first.

That can be a useful test to ascertain whether people have seen critical page elements and whether what they remember matches the priorities set in the user attention point exercise.

Both of these tests can be done in person. However, it is often easier to run them as a survey using a tool like Usability Hub. Not only does Usability Hub support both of these tests, but they will also recruit participants for you for as little as a dollar per person.

Creating Wireframes Avoids Iteration Hell

Hopefully, you can now see the value of creating wireframes and that you should do so with stakeholders. By adopting this approach, you will:

• End up with a better digital service.
• Avoid costly mistakes later.
• Have happier, better-educated stakeholders.
• Have a stronger case to support your design direction.

Yes, I know it can be tempting to jump straight into something like Figma and start working on the design. And yes I know it can feel like wireframing is slowing down the process.

However, in the vast majority of cases, it is time well spent, that will improve the final deliverable and avoid getting stuck in iteration hell down the line.