Tips & Advice

The Right (and Wrong) Way to Wireframe

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:

wireframe-life-insurance-site-666px

And this is not a wireframe:

wireframe-actual-UI-NOT-666px

A wireframe is not a UI design; it’s 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:

  1. Things the user needs to know, and
  2. 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):

  1. Are these patterns what the user needs or expects?
  2. 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:

wireframe-functionality-emphasis-666px

Notice the emphasis on the interactive controls and text titles — 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:

  1. 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?
  2. Once she acts, does the subsequent screen give her what she needs to progress and continue toward her goal?
  3. How much of what’s onscreen is relevant to her current task — what matters? What needs to be present but “hidden,” so to speak?
  4. 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:

wireframe-tree-shown-666px

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:

wireframe-tree-hidden-666

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.


Get My Secrets to UX Success: My New Book, Think First
 

  • http://www.protofuse.com/team/eric-sharp.com Eric Sharp

    Joe,

    Great information here. Well done.

    Question though. Why shouldn’t a wireframe include any branding? Specifically, a logo? The downside to placing a logo in the top left of a wireframe doesn’t feel like it’ll derail the purpose and process of wireframing. I understand withholding other branding elements (type, images, etc.) but the logo seems so low risk. Just curious as I’ve never heard that perspective before.

    Thanks for your wisdom!

    • http://givegoodux.com/ Joe Natoli

      Hi Eric — great question. You are correct in that a logo at top left certainly doesn’t derail the process. However, I’ve experienced many instances where including it has invited distraction on the part of a stakeholder or client: “that’s not the right color for our logo,” “why does the logo look so pixelated?” “why isn’t our tagline included up there as well; where will that go?” “That positioning isn’t in line with our branding guidelines…”

      Just the appearance of something that looks ‘real’ is enough for people to make the leap in logic that they are looking at UI design. As such, they fixate on what everything looks like instead of how it’s organized or how it works.

      Once this starts, it’s nearly impossible to stop. So for my money, I’d rather not have it there at all. A big box, or text that says LOGO completely eliminates these situations. Nothing to pick at or fixate upon.

      Also, when I say branding, I’m really referring to all the “look and feel”elements that a corporate marketing team will invariably ask to see — colors, font styles, taglines, etc. And to that end, if a logo is included, it should be greyscale or black & white. Even the smallest hint of something real can cause people to fixate, as in the logo examples above.

      So again, I’d rather steer clear of anything close to reality to keep everyone’s focus where it belongs.

      Hope that helps clarify — and thanks for reading!

      • http://www.protofuse.com/team/eric-sharp.com Eric Sharp

        Totally get it.

        On the flip side, it’s LOW RISK to put the logo in a wireframe, but it’s also LOW REWARD (so why even do it, right?) I love the approach of keeping everyone focused on the right things. I think that’s one of the biggest challenges in the wireframing/prototyping phases when collaborating.

        Do you see any value in proposing different fidelities of wireframing? (e.g. Low Fidelity, High Fidelity) Written anything exploring the pros/cons?

        Thanks for the quick feedback Joe!

        • http://givegoodux.com/ Joe Natoli

          Good question….! I don’t know that there is value in anything other than low-fidelity prototyping, with the possible exception of a particular interaction or UI behavior that simply can’t be modeled appropriately in low-fi.

          But even in that instance, I’d advocate for keeping all visual UI elements nondescript — again, so everyone’s focus is on what’s being modeled and most in need of feedback/resolution.

          • http://www.protofuse.com/team/eric-sharp.com Eric Sharp

            Makes sense. Anytime I’ve ventured into more than low-fi, it’s typically with a client that already understands the process (therefore preventing aforementioned focus issues) with specific details.

            Whether that’s UI-specific behaviors (like you mentioned), or even content related, I think it helps to flush details out. I believe wireframing outputs better content. I explored that more here if interested:

            http://www.protofuse.com/blog/website-wireframing-helps-plan-better-content/

            Really appreciate the article Joe. Good stuff as always!

Blog Categories