Wireframes have played an increasingly leading role in the modern Web development process. They provide a simple way of validating user interface and layout and are cheaper and faster to produce than a final visual comp. However, most of the methods and techniques used to create them are far from being efficient, contradicting the principles and values that made wireframing useful in first place.
While this article is not about getting rid of the wireframing process itself, now is a good time for questioning and improving some of the materials and deliverables that have become de facto standards in the UX field. To make this point clear, let´s do a quick review of the types of wireframes commonly used.
Low-Fidelity Wireframes
This is the most basic form of prototyping and includes hand-drawn sketches on paper or a whiteboard or using a graphic tablet in the computer. They are extraordinarily cheap and quick to produce, providing just enough detail to help imagine what the final product might look like without constraining the freedom of imagination that is essential in the early stages of design.
Low-fi wireframes don’t ask for much content. They are meant to communicate a visual idea and explore possibilities rather than document a design.
Mid-Fidelity Wireframes
Commonly known as mockups, these go a step forward in detail and can serve as valid documentations of a user interface. They are usually produced on a computer, with tools such as Balsamiq Mockups or Axure, or, sometimes, by hand using stencils.
Mockups deliberately look like low-fidelity wireframes in order to keep the focus on the UI controls and overall layout. But they also provide exact specifications of the interface controls to be used. Functionality and content are also demonstrated more precisely and most UI copy (system messages, navigation items, form labels, instructions) should be present here in its final form. For a seasoned front-end developer, it is perfectly possible to translate what´s pictured in a mockup into working HTML code, but we’ll get back to that later.
Hi-Fidelity Wireframes
This is what most people have in mind when they think of wireframes: a carefully crafted blueprint, which is usually true-to-size and incorporates the highest level of detail previous to the final visual comp. In other words, this is a final comp, minus the look and feel, color palette, and fonts.
Sizes, whitespaces, margins, proportions, and line-heights are considered in this kind of wireframing, usually produced in a precision tool such as Fireworks, Illustrator, or OmniGraffle. This document is ready to be dressed by the visual designer with textures and branding. UI copy (such as status messages or button labels) is fully present in its final form. User-generated content (such as comments) may be filled with lorem ipsum text, and user-uploaded pictures or videos can be represented with placeholders.
Most web and mobile design processes progress through these three stages until getting to the visual comp, by which time every screen of the product is represented exactly as it will look when published.
At this point, lots of design hours have been invested, and chances are that almost none of the underlying decisions have been properly validated with users: incremental steps done in fidelity. You are basically performing (and sweating) work that is very likely to be completely undone when user feedback arrives.
Wireframing is About Prototyping
Have you ever thought about why are you wireframing? Is it because everyone else out there does it? Or are you just keeping the client entertained while you design the final comp? What are you trying to validate or illustrate when you design wireframes?
All these questions lead to the same place: wireframing is about prototyping. The underlying value of doing wireframes first instead of getting to the construction of the real thing right away is building a prototype, which allows you to test, correct mistakes, and validate the key design decisions with users in the cheapest way possible. Nobody wants to spend thousands of bucks on a product only to realize that their assumptions were wrong. You can fail cheaper. That’s why you prototype.
But then again, what are you trying to validate through testing in a prototype? Think of it as a scientific experiment: you must test one thing at a time to get clear results. The best way of achieving this is by isolating or giving prominence to what you want to test, and then moving on the next variable.
Core design decisions need to be validated first, so the next, more specific decisions have some solid ground to stand on. It’s beyond the scope of this article to thoroughly detail the entire incremental process of validation, but here´s an outline:
- Test the general idea and value proposition.
- Test the overall content structure and ease of navigation.
- Test the content/user interface and ease of completion of the core tasks.
- Test look and feel, attractiveness, and branding.
Looking from this perspective, hi-fidelity wireframes don’t make for efficient prototypes, because their complexity makes testing difficult, defeating the very purpose of prototyping.
Disadvantages of Prototyping with Hi-Fidelity Wireframes
It’s difficult to isolate a variable to test: Due to its high fidelity, hi-fi wireframes not only inform the viewer about the user interface and overall layout structure, but also visual proportions, whitespace, and even typography. They are made to be precise—and this precision is the very reason why most users don´t know where to draw the line between what should be evaluated and what shouldn’t. “This line here, is it part of the actual design or should I ignore it?”
Looks like a final product, but it´s not: A typical wireframe is polished enough to look like the grayscale version of a final Web page. Again, this makes users (and your client) wonder, “is this really how the real thing is going to look like?” So you need to explain them that typography it´s not part of what you are validating now, but the column width is. This blurry distinction between a final product and your prototype causes users to waste time evaluating and giving feedback on things that you didn’t mean to test.
Puts users in “critic mode”: Nobody expects sketches to be beautiful. The lack of precision allows people to focus on what is being represented instead of how close to reality it is. People tolerate imperfections in a lo-fi wireframe. They fill the gaps mentally and accept the game: “let’s play as if this were a real product.”” The precision in a hi-fi wireframe tells people to critique how polished it looks, because what other reason might exist for such level of fidelity?
“But hey, I never meant to prototype with wireframes either.” I hear you. In fact, in many cases hi-fi wireframes are produced as design documents intended for teamwork purposes, not for user testing. Someone creates a pixel-perfect skeleton; someone else dresses it. But even in this case, wireframes usually are not the most efficient solution.
Why Hi-Fidelity Wireframes are not Time-Efficient
Too much time is spent trying to replicate the natural behavior of HTML/CSS: Think of images flowing with text, for example. To show how an image would look floating to the right within a paragraph of text, you have to do some tricks that certainly will exceed the amount of time required to put “float: right” in your CSS. Think of hover or pressed states. Think of margins and padding. Think of replicating (and scaling) native form controls. These are examples of things that are a lot easier to achieve in HTML, which, coincidentally, will be your final canvas.
Wireframes are not responsive: Chances are, if you are designing for responsiveness, you must generate, at the very least, two (and usually three) wireframes for each view: one for desktop, one for mobile, and sometimes one more for tablets. For a ten-view project (something small, like a webpage), this means 20 or even 30 different wireframes. An HTML page, by comparison, will adjust itself effortlessly to resizing, so there´s no need to duplicate your work.
Changes are painfully slow to apply: Wireframes always have to be revised and changes applied. Corrections to the layout, proportions, or sizes usually mean that you have to change everything manually. Even if you are properly set with reusable library items and master pages, visual elements won’t realign themselves by magic. And this happens because graphic software doesn´t behave like CSS does, where one line of code changed can make the difference for countless pages.
Is there anything that can be done about this? Of course, and the key words are just enough.
Focus on mockups
Mockups provide just enough detail to inform the front-end programmer and the visual designer. If you think of hi-fi wireframes as “mockups plus precision layout”, then you can move the “precision layout” part of the equation right to the visual comps, where they belong.
The visual designer can certainly start building something similar to a wireframe and then putting artwork on it, but that effort is done only once (instead of repeating it for every wireframe) and it´s not an obstacle to the testing process anymore.
Mockups are quick to produce, don’t require you to be a whitespace or visual rhythm guru, and look nice to users. With mockups, you can show the user interface in a focused way, so you can direct your efforts toward producing a more cohesive interaction rather than deciding if the column margins should be 11 or 12 px. Mockups take you to the essentials of good user interaction, and what’s better; they can even be done in parallel to the visual design and artwork production if the interface designer and the visual designer work together closely.
The front-end programmer can start working right away based on your mockups. Especially if the app is being done in an MVC framework (like Rails) or if there’s some kind of templating system involved (like WordPress), the content is isolated from the layout structure, which allows working in the fine details of the UI and the overall layout with independence. This means that you (or your teammates) don´t need to define the entire layout just to start coding.
Wireframe (or Design) in the Browser
Why not to produce wireframes directly in HTML/CSS? There are various reasons that make this option very appealing:
With CSS frameworks, basic layout is a breeze: Twitter‘s Bootstrap or Zurb’s Foundation allow you to mount a grid-based column system in minutes. Take advantage of the flexibility of CSS, changing column widths on the fly while the text adapts itself. Variations are produced quickly by changing just a couple of class names.
Your deliverable is responsive-ready: Both frameworks are responsive right out of the box, and even if you create the CSS from scratch, adding a little bit of basic responsiveness is fast and easy compared to the effort of producing separate wireframes for different viewports. In addition, true mobile testing starts right away.
You can take advantage of what the browser does by nature: Adding scrollbars when needed, resizing form controls based on text length, flowing text around floating elements, keeping consistent padding—these are all things that any browser does without you even asking. Don’t waste time trying to mimic browser features in a static image.
It’s truly interactive: Good-ol’ links are all you need to add interactivity to a prototype. Hover functionality can be demonstrated live. You can test transitions and animations (impossible in a wireframe or visual comp). An HTML wireframe is the easiest one to send to clients (just a URL), and a Web browser is all that´s needed to run the project.
The scalable nature of CSS enables easy, live changes: So the client doesn´t like the link color? The entire project is updated with one line of code. Using a browser inspector (such as Firebug), you can make live changes while you are presenting.
You don’t need proprietary software or a powerhouse machine: A text-edit app is enough to make quick changes or do emergency work when your computer crashes the day before deadline and your grandma’s old Pentium is all you have on-hand.
Everything you do saves you time later because you are building the real thing: Every line of code you write counts towards the final product. There’s little to no rework when you prototype in the browser (just try something like “div, table, td {outline: 1px solid #999}” to add visual aids when wireframing).
Bottom Line
By getting rid of traditional wireframes and directing those efforts toward producing quick mockups first and actual HTML/CSS code later, your design process will account for the limitations and possibilities of the Web (desktop and mobile). You will also save valuable time for the back-end developer. In addition, wireframing in the browser can be a nice and fun way of getting yourself writing HTML and CSS code, which is a must for a Web or mobile designer these days.
In certain cases, hi-fi wireframes might still need to be used—for example, when building native, visually complex mobile apps, developers usually need some by-the-pixel sizes in order to start building the app before visual designers get their hands on look and feel. But even in that case, you might consider HTML wireframing as a nice option to build usable prototypes that are testable on real devices.
The value of prototyping is getting early user feedback to deliver better products faster. Keep that in mind and your work performance and standards will continue to improve. Consider this article as a springboard toward streamlining and optimizing the Web/mobile development process—something which is certainly in the best interest of everyone involved: developers, clients, and users.
Power tower image courtesy Shutterstock
