I need to start with what I’m sure will appear to be a painfully obvious question:
What is a wireframe?
I ask it because on a weekly basis I see things that are called wireframes, but, in fact, are not wireframes. And as such, they’re not really helping their creators move things forward and answer questions of proposed features and functionality. Here are few things that tell you whether you’re looking at a wireframe (or not):
- If you’re using any color aside from blue to indicate hyperlinks, it’s not a wireframe.
- If you’re using real images, it’s not a wireframe.
- If there is branding of any kind anywhere, it’s not a wireframe.
- If you’re using any font other than Arial, Helvetica or Times Roman, it’s not a wireframe.
This, then, is a wireframe:
A wireframe is not a finished UI design; instead, it’s an extremely nondescript version of a website, app or system. Think of it as a “skeleton” for the digital product you’ve been tasked to design. It’s rough sketch you can click through.
Wireframes should lack font style, color and graphics, since the main focus is on organization, functionality and priority of content and interaction. The purpose is to allow you, your team and your stakeholders to focus on how people will browse through and interact with the site, system or app. You’re also firing a first shot across the bow to indicate how content will be organized across its pages – without the distraction of color, fonts, and other design elements.
The minute you introduce UI design elements that look “real,” everyone focuses on the visual appeal, filtered through their personal preferences. It’s human nature; we can’t help it. But if your ‘wireframe’ looks like the second example above, you’ll never get the feedback you need. Instead, you’ll spend the remainder of your time redirecting the conversation, trying very hard to get stakeholders to consider and respond to the appropriateness of the navigation, opportunities for interaction or structure and organization of data or content. And you’ll be hearing some variation of “I really don’t like that teal color” on endless repeat.
What are we trying to determine?
The wireframes show all of the screens you are proposing to include, and describe the content (text, images, etc.) and interactive controls (links, buttons, menus, forms, etc.) that will appear on each page. If draft text content isn’t available, “Lorem Ipsum” copy can be used to suggest content ‘chunking’ and length. The purpose of wireframing is to iterate quickly, in order to get answers to the following questions:
- What navigation categories and interaction mechanisms are most appropriate?
- Do the page structure, navigation and workflows here:
- present information users want and expect?
- present information in a way where they can easily find what they need?
- use labels users will readily understand?
- allow users to easily and accurately predict the outcomes of their actions?
- Is the proposed interactive behavior and related functionality appropriate?
- Is it feasible to build, given our current constraints (time, budget, personnel)?
- Does the visual hierarchy and organization of the content on each page make sense?
Wireframes separate information from action.
While layout is certainly addressed in wireframing, the bigger fish here is the clear separation of information and action. Your task is to be ruthless in coming up with ways to segregate and separate the two, because this separation is the foundation of sound interaction design. As such, it’s critical to keep two things distinct:
- Things the user needs to know, and
- things the user needs to be able to do.
The latter should be up-front and center; the former accessible but tucked out of the way and used only when needed — and in such a way that invoking it doesn’t obscure or compete with the action the user is trying to take.
What you’re trying to do here is build a model in place for that separation: design patterns, interaction patterns that make sense. Try, evaluate, revise. You work quickly, implement one way of doing it, and ask yourself (and/or your team):
- Are these patterns what the user needs or expects?
- Is each pattern appropriate for the volume and type of content they’re manipulating or viewing?
Actions always have visual priority.
The core purpose of just about any app is action, so that takes center stage. In other words, data inputs and controls should take more prominence on the screen than their content-based counterparts. You want the user to quickly be able to scan (not read) and act. Here’s an example:
Notice the emphasis on the interactive elements, text titles and controls at the bottom of the screen — there are no paragraphs or explanatory text here. We’re quickly answering the user’s first question, “what’s here?” and the next, which is “how do I act on it?“
We’re giving very little thought to visual design, because it’s not important yet. The most important task at hand is to figure out what’s needed, when and how the user needs it. Everything here is also used to figure out if and why the user wants it. In that light, your wireframe work should be seen as a starting point for discussion around those areas. In the example above, you see the most conventional, obvious solution for a hotel room reservation process: parameters on the left, results not he right. We start with the most obvious solution, get it down, and then share it to decide what it could or should be. In other words, your wireframes should be used to generate requirements.
In addition, at this stage, don’t fixate on the exact mechanisms we use to display this stuff or to allow the user to interact with it. It doesn’t matter yet whether the final build will be a dropdown list or a menu of links, or a button vs. a hyperlink. It’s far more important and valuable to figure out what’s needed and how people will expect or want to interact with it.
For example, you may use a traditional data table in the wireframe, but that may not be the most efficient or appropriate way to expose this information. But you start with that table anyway, because it’s a question that needs to be asked: what’s the best way to present this? You start with your first best guess, and you change it as necessary across your iterations.
Wireframes are meant to pose questions.
You don’t wireframe because you already know the answer; you wireframe so that you can surface every problem that needs to be solved — in a format that allows you to test for validity. Team members, stakeholders and (of course) end users can all interact with what you’ve built while you observe use and see what works.
So while you’ve certainly given some thought to form and function, you’re not trying to get either one right yet in terms of interface and interaction specifics. What’s more important right now is that the volume of content and the appropriate content are surfaced in a meaningful, contextual way.
Surface all the right information and possible/desirable actions first. Use the wireframe as a vehicle for asking questions like:
- At each step, what does the user need to see — and how much of it — in order to make a decision, in order to act or take the next step?
- Once she acts, does the subsequent screen give her what she needs to progress and continue toward her goal?
- How much of what’s onscreen is relevant to her current task — what matters? What needs to be present but “hidden,” so to speak?
- What’s here that’s completely unrelated or extraneous, and should probably be removed or relocated?
Start big, finish small.
Essentially the approach you should take to these types of screens (any enterprise-type system) is one of designing for multiple views at the same time. In other words, start with the idea of “what if everyone had to see all of this at once” and then plan to gracefully redact things that aren’t applicable to certain users. You’re thinking out loud, essentially: how does it fit, where does it fit, and where does it go when it’s not needed?
Here’s a simple example. In order to figure out whether it makes sense to incorporate show/hide functionality in a tree-style navigation pane, we start by including it in the layout:
Simply seeing it like this is enough to suggest that there is far too much information on the screen at one time. At this volume of content, everything competes with everything else for the user’s attention. This will make it hard for users to focus on the data they need to review and the related actions they need to take.
So we quickly decide the show/hide feature makes sense; we add an icon to control the interaction, and create an alternate view to test our theory. This takes a few minutes at best:
Working backwards in this way allows you to quickly validate a proposed feature and gives you re-usable patterns, schemes and templates. Working this way can be difficult — especially with large enterprise systems — but it pays off once you get to actual implementation. The majority of the heavy lifting is done; the complex issues or feature/functionality questions that usually extend sprints far past expectation have been ironed out. And because the wireframe format is so simple — HTML/CSS — iterations and changes are quick and inexpensive. Changing functionality using wireframing software like UXPin or Axure Pro takes a fraction of the time necessary to make the same change to a prototype using working code.
Wireframes should be used to generate requirements.
One of my rules for slow-moving enterprise organizations is that if you spend more than two full workdays strategizing or discussing requirements, you’re taking too long. Get to a wireframe prototype as soon as humanly possible and use that artifact to guide everything from that point. “Gathering” requirements upfront is a colossal waste of everyone’s time and only ensures mediocrity. Build a simple prototype early and iterate on it to generate requirements. Quick cycles of revise & review.
Teams and stakeholders are always tempted to skip wireframing and dive into code. And it’s painfully common that they’ll often do requirements work before wireframing, considering that work to be finished and etched in stone. Please, please don’t do this. Wireframes can, do and should generate requirements. Not leveraging that power only ensures that when something unexpected comes up (and it will) later, everyone involved in the project winds up painted in a corner.
Skipping wireframe prototyping is like skipping ahead to the ending of a book, because they both result in the same thing:
An ending you absolutely did not expect.
. . . . . . . . . . . . . . . .
If you’d like to get more advice from me every month on topics like this — in the form of training videos, full-length courses, e-books, downloadable templates and more — check out my NEW online school, the UX 365 Academy. Every month I publish new content, and you also have access to every course, book and training video I’ve ever created — some of which have never been published online before now.
