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:

  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 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


not responsive wireframes are old technology and newer and more modern architecture designs need to be implemented. http://www.synergyhomeremodel.com/

You can try http://codly.io/ to convert your photoshop design into native code in seconds, just From Photoshop PSD to Code .and to :

  • slice your PHOTOSHOP design  automatically.
  • generate assets for all application screens.
  • automatically generate the UI components of your application.
  • organize, Export the UI source code,converting your Photoshop design to interactive, working prototype.

I use Axure for this type of thing. Building libraries and widgets for me saves time mocking up a prototype and seems to be quicker than actually building out the html css.

The main problem with this piece is that it doesn't consider the drawbacks/cons of jumping into code for interaction prototyping. Here, I fixed it: http://ambroselittle.com/2013/01/10/yes-ditch-traditional-wireframes-but-not-for-code/ :)

My limited experience leaves the impression that the HTML/CSS files written by the designers do not actually reduce the workload of the developers. They are not often reusable to a great extent, and do not fit into the exact software architecture, though the looks are similar, the back-end developers still need to rework almost everything.

I agree with Lisa - I use Axure to do mobile prototyping and it does very well with simulating the mobile browser experience and is a lot less time-consuming than hand-coding throwaway HTML.

A tool like Axure renders this whole debate moot in my opinion. You can do low to hi fidelity, include interaction and even conditional logic then export to HTML/CSS and Javascript in a fraction of the time. To sit there and hand code something that you know will change when the code won't be re-used by dev seems like an incredible waste of the client's time when there are better options.

This approach has been debated over the past couple years and is a very interesting and potentially time-saving approach.

I agree in principle with what you're saying but I see a few problems,

1) Many CMS and eCommerce platforms aren't very flexible when it comes to passing along finished code. That renders HTML/CSS work useless

2) Front End coding is a skill unto itself. While I like working with HTML/CSS I would hardly call myself a front end developer. I see a LOT of issues passing code on to skilled front end developers,

3) If you need to "prototype" interaction that require multiple variables, the HTML/CSS approach isn't ideal. I know you're talking about wire frames, but tools like Axure can be both the wire frame AND interactive model. The code is useless but communicating functionality is much easier.

I definitely see the benefits of the "code it " approach. But, I think a very well defined and rigorous design and development process would have to be in place to support that system.

thanks for the interesting article. I am just wondering what do you exactly mean with your different fidelity styles. I made the experience that everyone has his individual definitions of wireframes/mockups and uses different styles. it would be interesting if you could add some illustrations to your article.

I just started my bachelor thesis with a topic that is related to your article:

Thanks for the nice write up Sergio. While I do think high fidelity wireframes and prototypes end up forcing too much to be tested, they also provide some other benefits, including feasibility (design matches up with reality on a given platform) and code conversion (design can be converted into usable code which saves a lot of time).

I've built two "prototyping"/interface building tools for HTML5 frameworks. One, Codiqa (http://codiqa.com/) for jQuery Mobile for HTML5 based mobile apps and websites, and Jetstrap (http://jetstrap.com/) for Twitter Bootstrap designs.

Our users *are* moving over from low fidelity wireframes because our tools give them what the would use on the programming end after the design anyways. The trade off is less design control but you reduce the overall time converting idea into reality.

I watched a video of Chris Coyier speaking at a WordPress meetup in SF recently (https://www.youtube.com/watch?v=vsTrAfJFLXI), and he explained that he does everything in Photoshop first. He also admits that he's never done wireframing at all. He said that he likes to use Photoshop for his designs first because he feels more creative and thinks differently in Photoshop when compared to coding.


"It even gets dangerous when you try to move prototyping code into production code. Developers will hate you for trying to pass them code they didn't wrote."

That's why you treat prototyping code as production code. The high-fidelity prototype contains all front-end code at production quality and represents pretty much the entire front-end of the site.

Our developers love the prototype as they'd much rather focus on database optimisation, MVC and back-end code than fiddle around with HTML until it works on IE6 and an obscure Nokia.

I have read articles like this here and there.. and sure, I remember when 37signals posted about ditching the wireframes (or was it photoshop comps) and doing it all in html... but in my experience, it never works out...

If you try to draw mockups free hand, you end up spending more time scrapping them and re-drawing over and over until you feel you got it right. It has never saved time for me and you end up leaving too much out.

If you try to do low-fi wireframes, using balsamiq, they take just as much time, and sometimes longer, for those of us that have become pretty fast w/ omnigraffle. It is too much of an effort to try and dumb your wireframes down...

I need to get my hands around the whole site. Every page, every feature on the page, how they relate to each other - so for me, I want my wireframes clean and orderly and notated well. It's a given that I will have a ton of revision rounds and have to wireframe separately for tablet and mobile, but that is what we are getting paid for.

The clients need to see what they are getting. They want to be a part of the process. The wireframes give us the perfect opportunity to work through all of our content and functionality issues. Of course we tell them not to look too deep in to the actual layout of the wireframes, and that designers will take things to the next level. But at least all of the content and features are present and accounted for.

Our designers don't want to spend time figuring out how the site is going to work. It is not what they love. They love design.

Our front end developer(s) will of course take things to the next level, but they appreciate that a lot of the heavy lifting has not only been sorted out, but also approved by the client.

Sure, in an ideal world, we would have time and resources to AB test and make data driven decisions on everything, and maybe a start-up working on a single website is in a better position to do this. But if you are building a half doze websites at a time for big brand clients, the best we can hope for is their analytics up front, and lots of back-and-forth discussions and collaboration, and pushing the process forward one step at a time.

@ Sergio - You say a hi-fi wireframe is "a final comp, minus the look and feel, color palette, and fonts." It is precisely these things - look and feel, color palette and fonts - that occupy the majority focus of the majority of business stakeholders. "There's no way adding this product to a wishlist? Meh ... didn't notice. But I'm glad that we were able to resolve which color of blue to use after only six meetings!"

Hi @Aaron Bradley,

I don't really get your point. What would be the benefit of doing mockups after Hi-fi wireframes? Maybe we derive different meanings from the term. In addition, there´s no such thing as a "single" prototype. You get to prototype from the very beginning, with different (hopefully increasing) levels of fidelity/detail. That´s what I tried to convey in the article.

Hi @dane troup,

What I understand by a mockup is similar to what's illustrated in the axure.com homepage. I think the distinction between a "mockup" and a hi-fi wireframe is how much effort you are putting on things like whitespace, dimensions, margins, borders and boxes.

In that sense, the best approach, in my opinion, is to increase gradually in levels of fidelity -- you indeed start with just a sketch, and once the idea you tried to communicate is validated by stakeholders and some users, you get to evolve.

I don´t think Bootstrap or even HTML wireframing is the one-size-fits all technique for all hi-fi wireframing needs, but in Web sites and apps it may be the fastest way of having a working product... and then the true validation just begins.

Thanks for your thoughts!

Sergio -

This was a good read. We are doing a lot of interactive wires using Axure and I find clients can understand them much easier than annotated paper based wireframes. I have had some difficulty using frameworks like Bootstrap because it only supports basic page layout and in order to add additional features the amount of effort tends to be more than its worth. Over time it may get easier and the framework will probably become more robust so I think I will use it for smaller basic jobs and monitor how it evolves.

I wasn't clear as to what you meant when referencing "Mockups" how much fidelity goes into a mockup? Is it just a sketch to agree on direction and high level functionality?


"Mockups provide just enough detail to inform the front-end programmer and the visual designer."

Based on my experience, I'd rephrase this statement thusly: "Mockups provide just enough detail to blind business stakeholders to function and draw their focus to design."

High-fidelity mockups help keep the focus where I think it needs to be when nailing down page elements, linkages and user interaction. Mockups and prototypes are fabulous once functionality has been more-or-less mapped out - and, critically, signed off by business and technical stakeholders - but muddy the water if introduced early in the process.

Hi @Cristian,

I see you are thinking from the efficiency side, which I think is one of the key values of lean-agile design. I'd invite you to view HTML wireframing more as an invitation than as something mandatory.
Indeed, if learning to prototype in a certain platform is taking you longer than building the prototype itself, it´s no longer efficient. But that does go with the spirit of the article, in the sense of avoiding bottlenecks when prototyping.

And also, it depends greatly on what you are trying to validate in a specific moment. In some cases you need to build something that behaves realistically in a browser, in some others you need to build something that looks visually polished. Flexibility is key in UX.

Thanks for your thoughts!

Hi @Martin Crisp,

Excellent complement to what´s been expressed here. Your comment will probably be of very much value to anyone who wants to clear out doubts or concerns arisen in the article. I find your idea of an "integrated deliverable" particularly useful.



I too feel like you're talking about HTML/CSS prototyping like it's easy to do. When it's not. Even for those who already know how to code. Finding the frameworks, putting them together just to get started it's just too much quick prototyping.

You're absolutely right about the new challenges that requirements like mobile, responsive design, put on the table. And indeed, UX designers need to adapt. But coding might be just too much for them to learn.

I am a programmer, and learning UX design is hard for me (I have to). The same goes the other way. It even gets dangerous when you try to move prototyping code into production code. Developers will hate you for trying to pass them code they didn't wrote.

I built a prototyping tool, and believe me, as soon as you know your way around in such a tool (Balsamiq, FlairBuilder, WireframeSketcher and others on the market), it's much easier to position stuff on a blank canvas then to nest all those divs. float: left does not really make it any easier. :)

The bottom line, from my perspective, is that prototyping should be fast, really fast. So you get the time to explore and test as soon as possible. And a dedicated tool, albeit proprietary, is perhaps a better choice. HTML links is the most basic interactivity you will need. But there's more to UI interactions these days than that. Tabs, drop-down menus, popups, etc.

HI @Sergio Nouvel,

Great Article,

I very much agree with the basic principles you outline in your article such as focusing on low and mid fidelity wireframes, as it is very efficient to create them compared to prototyping.

I do think high fidelity prototypes are often done when they are not required, and in fact believe they can hurt usability and project budget because of the time they take to build, as outlined in a recent blog post I made.

here is the link...

In addition, when a ux designer creates low or mid fidelity mockups they don't get as emotionally attached to one idea, and in fact explore more concepts. If you do high fidelity prototypes, you will get less ideas generated in the same amount of time, which hurts usability, simply because it takes much more time to create a prototype with full interactivity, sample and interactive data, logic etc etc.

I have seen high fidelity prototypes put to good use when trying to differentiate your bid on an RFP for example, or to get stakeholders excited about the concept to approve the spend, but other than that or maybe exploring some new complex user interaction never seen before, they are a waste of time.

If you are going to build a prototype (and again, i don't think they are required in most situations) I have always believed that you should do so using the dev tools you are going to use for building the actual system instead of some prototyping tool like iRise for example. I would argue like you, that on most platforms there are dev tools that make building prototypes very fast indeed, and these prototypes can continue to evolve and be integrated into the actual working solution as you build it.

In addition to your points made and what I have already talked about, low fidelity wireframes and mockups have the advantage of being able to include additional "informational" text, notes etc to convey more requirements information than a prototype does.

Another downside about prototyping is that it requires the developer and testers to explore the prototype to hopefully uncover the requirements. for example, in the windows 8 design, the user is to move their mouse to the corner of the screen in order to invoke functionality that is not visible without putting the mouse in that location. If you designed this in a prototype, it is very likely that your developers and testers would not discover it. Sure you could just tell them, but how many other hidden functionality or alternate paths of user interaction would you need to "just tell them about".

In contrast if you leverage your wireframes within a "use case driven storyboard" then the reviewer is can follow the the use case steps (main flow steps and alternate flow steps), which ensures they discover the functionality unlike prototyping. In addition the use case steps can provide even rich in context requirements. I talk about the concept of "use case driven storyboards'" in an article I wrote for UX Magazine in the context of it also being a great way to ensure your use cases, ui mockups and storyboards don't get out of sync with each other and thus avoiding some confusion and rework by the dev/test teams.

here is the link
http://uxmag.com/articles/the-broken-telephone-game-of-defining-software-and-ui-requirements ,

Great article.

Martin Crisp
CEO PowerStory

Hi @Andrew Mottaz,

I'd want to stress that a UX designer *should* prototype. The point is to find the best methods and materials to do so. In addition, user experience encompasses many layers, of which traditional wireframes cover just a few, so you can't completely assess what is your users' experience until you build and test the final thing. Focusing on mid-fi prototypes and then building helps you getting there faster and validating some key points in the meantime.

That said, in some work environments, hi-fi wireframes are part of the corporate culture, and just throwing them out of the window seems impractical. But my intention in this article is to make designers and UX practitioners at least to think about it and defy what's being done currently in the field, in search for better techniques.

Thanks for your thoughts!

Hi Sergio,

Interesting article and approach. I've been thinking a lot about responsive and prototyping lateley, and I have to say I disagree with the idea of just building with a responsive framework. If you don't focus with intent on the experience you want your user to have, then you will be letting a generic responsive framework direct or even dictate what the experience is at different screen resolutions. Prototyping ( with mobile first ) lets you get the user experience right. You can then choose whatever implementation technology you want. Granted, I may be biased as I work for ProtoShare, a collaborative prototyping tool. I'm working on a article about this approach which I'll be posting on blog.protoshare.com.

I will concur with some of your statements about the amount of time it takes to model things like :hover behavior. The key to prototyping is to make it fast and easy to build the things that you commonly need to specify. Getting ideas produced and iterated on quickly is the main reason to use a specialized prototyping tool. An HTML/CSS based tool like ProtoShare gives you the benefits and flexibility of CSS without requiring you to be a hard-core coder. ( CSS transitions, hovers etc are created in a gui )

Finally, I have slowly become a convert to high-fidelity prototypes. The main reason is stakeholder engagement. Despite the risks you highlight that stakeholders focus on the wrong things, in my experience, high fidelity is the only way to get serious engagement and focus from the vast majority of high-level stakeholders.

Thanks for the article!