Answers to Your Most Contentious Questions About Wireframes8 min. read
Four challenging questions and considered answers about wireframes and their role in the design process to understand their value and use in the real world.
This article was originally published on the UI Goodies Blog.
Introduction by Jess Eddy:
The debate around wireframes never seems to end. Some designers swear by them, and some say they are a waste of time. Disagreement and misunderstanding about the role of wireframes are partly responsible for this controversy. As is, what they should look like, how to use them, and for what outcome.
As designers, we spend a lot of time communicating and figuring out how to communicate our ideas to people on our team as well as broader audiences. Many of us work in fast-paced environments where time is a luxury, and we need to communicate quickly but also clearly.
Wireframes, when used correctly, can help us to this end. Wireframes help facilitate conversations and allow for quick iteration cycles. They help get us to a place where we can focus on problem-solving through high-fidelity, visual design.
To come up with the questions that Leon answers in this post; I polled my Twitter community for feedback. Almost 70 people responded, and some consistent patterns and themes emerged. We took those themes and boiled them down to the essential questions, highlighted in this post.
We hope you enjoy it!
Why should designers spend time making wireframes, what unique value do they have in the design process?
Wireframes are unique in that they help you get to a design solution quickly and make it easy to communicate the solution to different kinds of people. Unlike other design techniques, they support both divergent and convergent processes equally well.
Laseau’s Funnel illustrates how, during a design process, many ideas are generated at the beginning (divergent) to help identify opportunities, and viable options become reduced along the way (convergent).
Code and high-fidelity design tools are relatively brittle and inflexible.
Making small changes can have cascading effects that prevent them from looking right or working correctly. Artifacts created in these tools typically exist in one of two states: complete or incomplete. Anything in between is mostly unusable, or at least not presentable.
Wireframes thrive in in-between states. Their most comfortable state is “in process.” Wireframes don’t force you toward completion; They are liminal spaces.
One of my favorite examples is using them to evaluate technical considerations during the design process. As a designer, I have often used very early wireframes to show different UI concepts to a developer to get their input on the technical complexity of each. This process prevents me from going down a path that would be rejected later on for being infeasible.
The first reason designers should spend time making them is that they encourage exploration over refinement. The ability of wireframes to help communicate ideas brings me to the first reason that designers should spend time making them, which is that they encourage exploration instead of refinement in the ideation phase. Wireframes allow you to linger in uncertainty, which encourages creativity.
Wireframes facilitate conversation toward the right solution during convergent phases. Exploration is not an end in itself, however. The goal of design is to solve a well-framed problem, which is related to the second reason designers should spend time creating wireframes. Wireframes facilitate conversation toward the right solution during convergent phases.
If you’ve done your wireframes well, you shouldn’t get the perfunctory “looks good to me” reply that’s common with artifacts that look like they’re already on their way out the door. Prototypes, for example, are much more likely to be considered “final” and closed off from significant changes.
Wireframes invite conversation
At Balsamiq, we say that wireframes have a look that no one is afraid to criticize. For this reason, I like to think of wireframes as having more in common with sketches than prototypes. Everyone understands that sketches are suggestive and open to critique. It’s best to think of wireframing the same way.
This characteristic, coupled with the fact that making changes to wireframes is easy, leads to more iteration and refinement (in the convergent phase where refinement is called for). Stakeholders feel ok about suggesting improvements and then those changes can easily be integrated into the design.
I’ve been in meetings where wireframes were presented and instead of writing down a list of changes to make to them, the designer opened up the files and made the edits right then and there. That doesn’t happen with most design tools, let alone software tools in general.
What is the right level of detail for a wireframe, what “fidelity” should they be?
Low-fidelity wireframes are excellent for the exploration phase. It is natural and effective to start rough and slowly increase fidelity as ideas and solutions emerge. But I think this question is generally asked about wireframes presented to others. Low-fidelity wireframes that explore ideas are most often done alone. Or at least in a judgment-free space.
So I’ll address wireframes created for the convergent phase, where you are presenting, rather than forming, ideas. Is high-fidelity better than low-fidelity?
Let’s be a little bold here and avoid the expected reply to most questions framed this way: “it depends.” I happen to like the answer by Nick Babich:
“Mid-fidelity wireframes are very useful during discussions with the other designers and developers.” Specifically, I see mid-fidelity as going beyond just shapes and arrows, and including some amount of real text (perhaps at the navigation or headline level). But, more generally, I think what he’s saying is that the right fidelity is the level that feels “just right.” It’s the Goldilocks principle.
So, what is the “just right” amount of detail?
My own opinion is that is the point at which you start to encounter diminishing returns on the information the audience needs to know, given the effort it takes to convey it.
Here’s an example of what I consider the perfect wireframe.
Are you a little surprised?
This example isn’t a user interface wireframe. However, the fidelity is an excellent representation of what a wireframe should embody.
It provides just the right amount of information that the person making the item needs. No more, no less. The measurements aren’t exact (it’s not “pixel perfect”), yet it gives a clear idea of what you’re making. The illustration does not show the colors and textures, because, presumably, other sources define those traits (the raw materials, or code in the case of software).
All of those notes with arrows on the diagram (“annotations” in wireframe speak) could, in theory, be demonstrated visually using a detailed 3d model of the garment. Showing exploded views and zoomed-in seam patterns rendered at a perfect scale. But the effort to create a high fidelity visual representation at that level of detail would be exponentially higher than writing the notes, which are just as effective.
What’s so beautiful about this example is that at the exact moment that the visual detail stops being useful, the written detail steps in (more on this later).
Where do prototypes and sketches fit in?
Prototypes, sketches, whiteboarding, animation tools, and more all have a rightful place and purpose in software development. Pencil and paper, in particular, is an excellent starting point for any project. I frequently sketch before wireframing. It helps me overcome that initial friction of going from nothing to something.
When considering all of the techniques available, I think it’s helpful to look at the artifact landscape on an axis, as follows.
This graph doesn’t only show visual artifacts. Pictures aren’t the only way to convey information, and they’re not always the best way.
The software industry grew rapidly during the 80’s and 90’s while relying primarily on text-based Functional Specifications (also called “specs”, PRDs, or Requirements docs) to describe software functionality and behavior. Yes, usability improved dramatically with the introduction of visual software design tools, but they were quite adequate for feature development.
Back to the main point, each of these artifacts has a unique balance of presentation type and density.
Note that wireframes can, and should, contain text, and other information outside of the user interface itself. Annotations, notes, and flow charts can enhance the value of a wireframe. I often start my wireframes with text.
Now let’s add a third dimension, the amount of information conveyed, weighted by the amount of effort required (the inverse of return on investment).
Now a different picture emerges.
Prototypes contain more information, yet require a disproportionate amount of effort to create. Sketches are easier to create on an individual basis (less so when the cost of making changes to them are factored in), yet contain less detail.
Wireframes deliver “bang for the buck” because they provide a lot of useful information, yet require relatively little effort to create and change.
So, in short, prototypes should be used when a sufficiently high level of detail is needed to justify the time to create them. And sketches should be used when a low level of detail is all that is necessary to communicate your idea.
Should I ever show wireframes to non-designers, such as developers or product managers; I feel like it won't help them get the full picture?
The most common complaints about wireframes probably come down to one word: ambiguity.
As I mentioned earlier, wireframes embrace uncertainty and unknowns, and this sometimes comes across in their appearance. But just because all of the details aren’t shown doesn’t mean that they aren’t known.
So, how do you communicate these details without cluttering up the elegant simplicity of a wireframe? The first step is to accept that wireframes rarely provide the full picture on their own. They’re not supposed to.
Here are my favorite strategies for filling in the blanks:
- Use annotations and notes to write in extra relevant details. Don’t feel confined to visuals alone.
- Present your wireframes in front of an audience to bridge the gap. Show them while you tell a story about the problem and the proposed solution. This can provide any missing context.
- Show your wireframes to developers as you’re designing. Explain the problem you’re trying to solve and your ideas about it early on. In my experience, showing in-process designs and asking for input can turn developers into advocates because they feel invested.
- Include wireframes in your agile user stories so that the visuals can convey the concepts while the story detail provides the specifics.
- Combine wireframes with your design system. Let the wireframe communicate the user interface design while the design system covers the implementation.
Be aware that all of these approaches benefit from a culture of strong communication.
One way to reframe the challenges is to turn them around. Instead of asking, “how can I change my artifacts so that I feel comfortable showing them to stakeholders?” Ask, “how can I change my relationships with stakeholders so that I feel comfortable showing them my artifacts?” The closer you get to a culture of psychological safety, the more you will be inclined to show your wireframes to stakeholders.
Lack of trust, silo-ization, communication barriers, egos, and competition are detrimental to any design process. These issues are often more central to wireframes’ ineffectiveness than their inherent limitations. Seeing where wireframes “break” the process can help you see where you have communication gaps.
There is a reason that wireframing has persisted as a design technique, yet it is increasingly misunderstood and misused. I think this is largely due to the power and potential of the tools used to create them. There is a difference between the tools and the method of wireframing. We use tools to create wireframes, but the tools do not define the content, just as pens and pencils are tools for sketching, but have little bearing on what is created with them. A wireframe is, and should be, simply “a visual guide that represents the skeletal framework” of a software product. There is value in that alone.
The difficulty arises because once you have that, it is so tempting, and so easy, to go beyond that skeletal framework, to add interactivity, styling, code exports, and more. Until at some point it stops being a wireframe, and what is does, and what it can be used for, starts conversation about what it doesn't do, and what it can't be used for. But if you leave it as a wireframe, let it be what it wants to be, so to speak, the conversation will turn away from the artifact and toward the design so that meaningful work can begin.