uxmag.com https://uxmag.com/articles/ditch­traditional­wireframes

Ditch Traditional Wireframes

Wireframes have played an increasingly leading role in the modern Web development process. They provide a simple way ofvalidating user interface and layout and are cheaper and faster to produce than a final visual comp. However, most of themethods and techniques used to create them are far from being efficient, contradicting the principles and values that madewireframing 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 improvingsome of the materials and deliverables that have become de facto standards in the UX field. To make this point clear, let´s doa 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 graphictablet in the computer. They are extraordinarily cheap and quick to produce, providing just enough detail to help imagine whatthe 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 ratherthan 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 usingstencils.

Mockups deliberately look like low­fidelity wireframes in order to keep the focus on the UI controls and overall layout. But theyalso provide exact specifications of the interface controls to be used. Functionality and content are also demonstrated moreprecisely and most UI copy (system messages, navigation items, form labels, instructions) should be present here in its finalform. For a seasoned front­end developer, it is perfectly possible to translate what´s pictured in a mockup into working HTMLcode, 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­sizeand incorporates the highest level of detail previous to the final visual comp. In other words, this is a final comp, minus the lookand feel, color palette, and fonts.

Sizes, whitespaces, margins, proportions, and line­heights are considered in this kind of wireframing, usually produced in aprecision tool such as Fireworks, Illustrator, or OmniGraffle. This document is ready to be dressed by the visual designer withtextures and branding. UI copy (such as status messages or button labels) is fully present in its final form. User­generatedcontent (such as comments) may be filled with lorem ipsum text, and user­uploaded pictures or videos can be representedwith placeholders.

Most web and mobile design processes progress through these three stages until getting to the visual comp, by which timeevery 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 havebeen properly validated with users: incremental steps done in fidelity. You are basically performing (and sweating) work that isvery 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 keepingthe client entertained while you design the final comp? What are you trying to validate or illustrate when you designwireframes?

All these questions lead to the same place: wireframing is about prototyping. The underlying value of doing wireframes firstinstead of getting to the construction of the real thing right away is building a prototype, which allows you to test, correctmistakes, and validate the key design decisions with users in the cheapest way possible. Nobody wants to spend thousands ofbucks 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 musttest one thing at a time to get clear results. The best way of achieving this is by isolating or giving prominence to what youwant 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:

1. Test the general idea and value proposition.

2. Test the overall content structure and ease of navigation.

3. Test the content/user interface and ease of completion of the core tasks.

4. Test look and feel, attractiveness, and branding.

Looking from this perspective, hi­fidelity wireframes don’t make for efficient prototypes, because their complexity makes testingdifficult, 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 userinterface and overall layout structure, but also visual proportions, whitespace, and even typography. They are made to beprecise—and this precision is the very reason why most users don´t know where to draw the line between what should beevaluated 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 finalWeb page. Again, this makes users (and your client) wonder, “is this really how the real thing is going to look like?” So youneed to explain them that typography it´s not part of what you are validating now, but the column width is. This blurrydistinction between a final product and your prototype causes users to waste time evaluating and giving feedback on thingsthat 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 isbeing represented instead of how close to reality it is. People tolerate imperfections in a lo­fi wireframe. They fill the gapsmentally and accept the game: "let’s play as if this were a real product."" The precision in a hi­fi wireframe tells people tocritique 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 producedas 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, forexample. To show how an image would look floating to the right within a paragraph of text, you have to do some tricks thatcertainly will exceed the amount of time required to put “float: right” in your CSS. Think of hover or pressed states. Think ofmargins and padding. Think of replicating (and scaling) native form controls. These are examples of things that are a lot easierto 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 aten­view project (something small, like a webpage), this means 20 or even 30 different wireframes. An HTML page, bycomparison, 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 reusablelibrary items and master pages, visual elements won’t realign themselves by magic. And this happens because graphicsoftware 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 wireframesas “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 isdone 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. Withmockups, you can show the user interface in a focused way, so you can direct your efforts toward producing a more cohesiveinteraction rather than deciding if the column margins should be 11 or 12 px. Mockups take you to the essentials of good userinteraction, and what’s better; they can even be done in parallel to the visual design and artwork production if the interfacedesigner 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 MVCframework (like Rails) or if there’s some kind of templating system involved (like WordPress), the content is isolated from thelayout 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­basedcolumn system in minutes. Take advantage of the flexibility of CSS, changing column widths on the fly while the text adaptsitself. 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 CSSfrom scratch, adding a little bit of basic responsiveness is fast and easy compared to the effort of producing separatewireframes 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 controlsbased on text length, flowing text around floating elements, keeping consistent padding—these are all things that any browserdoes 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 bedemonstrated live. You can test transitions and animations (impossible in a wireframe or visual comp). An HTML wireframe isthe 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 isupdated with one line of code. Using a browser inspector (such as Firebug), you can make live changes while you arepresenting.

You don’t need proprietary software or a powerhouse machine: A text­edit app is enough to make quick changes or doemergency 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 countstowards the final product. There’s little to no rework when you prototype in the browser (just try something like “div, table, tdoutline: 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/CSScode later, your design process will account for the limitations and possibilities of the Web (desktop and mobile). You will alsosave valuable time for the back­end developer. In addition, wireframing in the browser can be a nice and fun way of gettingyourself 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 onlook and feel. But even in that case, you might consider HTML wireframing as a nice option to build usable prototypes that aretestable on real devices.

The value of prototyping is getting early user feedback to deliver better products faster. Keep that in mind and your workperformance and standards will continue to improve. Consider this article as a springboard toward streamlining and optimizingthe Web/mobile development process—something which is certainly in the best interest of everyone involved: developers,clients, and users.

Power tower image courtesy Shutterstock