Concerning Fidelity in Design

In late 2009, Tyler teamed up with Nutshell to design a new customer relationship management application. Based on his experience, Tyler describes how to use sketches, wireframes, and prototypes to move us down and out the design funnel.

People swear by their design processes. Rachel Glaves insists on sketching by hand; Dan Brown urges extensive wireframing; while Ryan Singer goes straight to HTML. Heated debates arise at conferences as advocates staunchly defend their favorite techniques.

With all of these different methods to choose from, should you be sketching, wireframing, mocking-up, or prototyping? The answer, simply put, is yes you should.

Design methods are not mutually exclusive. Rather, each method exists on a continuum of fidelity, ranging from low fidelity sketches to high fidelity HTML prototypes. Each method is well-suited for a particular phase of the design process, with one level of fidelity often leading into the next.

The design funnel

In his book Sketching User Experiences, Bill Buxton portrays the design process as a cycle of elaboration and reduction. The goal of the elaboration phase is to generate as many different ideas as possible, while the reduction phase is meant to select one of those ideas and carefully refine it.

Elaboration and reduction as overlapping funnels

Laseau’s overlapping funnels (as portrayed in Sketching User Experiences) indicate the dual nature of design as elaboration followed by reduction.

Rinse and repeat

While it does typify the design process as a whole, in practice the elaboration and reduction process must be continuously repeated time and again throughout the course of design. From information architecture, to visual design, to the functional prototype, each stage must be explored in full, then lovingly honed down to a precise solution.

The design funnel, from low to high fidelity

The design funnel illustrates the repetition of the elaboration/reduction cycle from low fidelity to high fidelity, converging into the final concept (inspired by Stuart Pugh’s funnel).

Getting it right

Using a method too high in fidelity wastes resources (both time and material) and risks a mediocre path being selected because better options were never given a chance. Working at too low a fidelity, on the other hand, means that the details never get filled in, yielding a half-baked result.

Time increases along with fidelity

A real world example

Thus far I’ve outlined an orderly model with distinct categories. Reality, however, is much more complicated: various components are often designed in parallel and at different phases; lines blur between information architecture and visual design; and refinement can sporadically revert back into ideation. What does the design funnel look like in the real world?

In a nutshell

In late 2009, I teamed up with Nutshell to design a new customer relationship management application. Over the past 9 months we have sketched (a lot), wire-framed (a bit), mocked-up (a whole lot), and coded (continuously) as part of the design process. The first month and a half was made up entirely of discussions in front of the whiteboard and around paper sketches. The month after consisted of turning the selected sketches into wireframes, while sketching continued for other parts of the application.

Actual time spent designing with each medium

Our media-of-choice over the past 9 months of designing a CRM.

At three-and-a-half months in, we had a pretty good picture of the information architecture for 80% of the screens. From then until now, most of my effort has gone into full-fidelity mockups, while I revert to sketches when we encounter less well-defined screens or workflows. As soon as the first mockup was complete, my colleagues began coding an HTML5/CSS3 prototype, which we used (and are still using) to see how our ideas hold up under actual use. We chose to build this Safari-only prototype first so that we could iteratively refine with as little overhead as possible.

When the tables turn

What we discovered is that there comes a point in time where working at a higher fidelity actually requires less time than working at a lower fidelity. For instance, once our visual style had been developed in the mockups, it was no longer beneficial to build wireframes; going straight from sketch to mockup worked just fine. Similarly, when we discovered something in the prototype that didn’t feel quite right, it was often easier to tweak the prototype directly than to go back to Photoshop.

A simplistic view of the design funnel, from sketch to wireframe to mockup

Be lazy (in a good way)

There is no single correct form of design. Rather, each method is appropriate in a certain context. At the end of the day, it simply comes down to selecting the level of fidelity that gets the job done in the least amount of time. As it’s been said, “Laziness is the mother of efficiency.”

About the Author

Tyler Tate

Tyler Tate leads user experience at Nutshell and TwigKit. He has been working on the web for a decade and is the creator of the 1KB CSS Grid. Tyler lives in London with his wife Ruth and son Galileo. You can keep up with him on Twitter.


  • Clervius Reply

    Great idea for an article. We all have our own established ways… I recently changed everything I was doing to include a heavier involvement in design both in the mock-up and CSS and it has been working wonders for how my sites look and feel now. I also added a CMS conversion stage, which I actually enjoy on the CMS I use (ModX).

    Nonetheless this was a great article

  • Ami Rotter Reply

    Great article. I was just thinking about this subject today. I have managed to speed up the process lately by using Axure RP for both creating wireframes and interactive prototypes. so I go from sketching to wireframes and the wireframes are easily turned into a full working prototype.

  • Travis Hines Reply

    Excellent article, Tyler. I’m going through the exact same process with an internal app, just on a much shorter timeline.

    I’ve found that design detailing of the UI can be the most time consuming.

    When you’re working with an app or site that has dozens of screens and plenty of use cases, I think creating UI guidelines immediately after you get sign-off on the design direction, can make the process a whole lot easier for yourself and your dev team.

  • Jae Xavier Reply

    lol, initech ^ ^

    Very insightful. Everyone has their own methods that originate from the type of environment they work in, types of clients, and philosophy.

    I’m a big believer in 37Signals methodology.

  • Fred Beecher Reply

    Like Ami, we go straight from sketching to prototyping (via Axure) at Evantage. Prototyping early in the process helps you take design risks by letting you get your crazy ideas out there and test them to see if they work. Waiting too long to prototype means you’re risking lots of design decisions getting made without enough input from users. Of course, there are a ton of different ways to prototype… some are more effective early in the process (e.g., sketched paper prototypes) and some are more effective later on (e.g., richly interactive Axure prototypes).

  • Danny Halarewich Reply

    What a terrific post. This helped articulate a process similar to what I follow for the projects I work on. While the timeframes and overlaps are always a bit different, the general process remains distinguishable.
    You’ve helped articulate what I’ve been doing. Thanks for that!

    One thing I found interesting was the comment that you’ll often work in high fidelity because it’s faster. I completely agree. The funny thing is, I often find myself feeling “bad” because I make a change in the HTML/CSS that isn’t in my PSD. I have some weird desire to keep them in sync.
    Which is sort of silly when you think about it.

    • Tyler Tate Reply

      Danny and Francois, I’m happy to hear that you also have found that working in higher fidelity is sometimes the more efficient option. Sketching and wireframes are perfect for early on and initial ideation, but once the visual language has matured, I’ve found small changes are often better made once in HTML than several times across multiple media.

      Thanks for your comments!

  • James Reply

    great article – especially design process as “cycle of elaboration and reduction”… Thanks!

  • Victor Conesa Reply

    The ideal would be that making an HTML prototype was as easy as sketching. It’s nearly impossible but some tools are near to that utopia, for instance Justinmind Prototyper (

    • ej Reply

      Victor, please be clear about your involvement in the product (Product Mgr for this product, right?) when posting to these discussions.
      I have not seen JustInMind product, but it is disingenuous to peddle it in this way.

  • Gieger Reply

    Really well written, constructed and illustrated. Great post!

  • dianecherie Reply

    This is pretty awesome. I’m encouraged as our organization will be piloting a similar model with a large emphasis on prototyping as part of the design phase.

  • Liz Hunt Reply

    Thanks for your thoughts, Tyler. This is truly enlightening!

    The phrase ‘to each his own’ has always made sense in the context of design. Your example of fidelity, however, underlines something we don’t often think about: the reality of our processes in real-world scenarios.

    We tend to overlook the overlapping tendencies of our steps and systems. Sometimes we fail to observe just how organic our processes are: not the neatly-packaged rulebooks we believe them to be.

    I look forward to more articles from you!

  • Mikehill33 Reply

    Outstanding way to kernelize the need to innovate with wireframes, and the lead into working prototypes.

    Having worked both in waterfall and now an agile environment, both models are extremely valuable.

    Well done!

  • Mike Reply

    Ridiculous. Just build the damn thing. You are trying to make designing a science rather than an art to justify your existence.

    • Tyler Tate Reply

      Unfortunately “just building the dam thing” often leads to either a very poor product or having to build it several times before getting it right. It’s better to expose bad ideas early and in low fidelity rather than late and in high fidelity.

    • ej Reply

      Yikes! Surprised someone with a comment like that even took the time to read the article, or any article on IxD for that matter.

  • noelj Reply

    This is what user centered design actually means…

  • Mike Gilger Reply

    Great article really like the graphs. Your time line on wire framing to design brought up a really good discussion today. I think we might make make some adjustments.

  • Hector Hurtado Reply

    Your approach to the design process goes hand in hand with the Agile workflow we use in-house.

    Great article, simply put in words as in form.

  • ej Reply

    Great article and topic – thanks.
    Personally, I very much value the time to work in a sketch/wireframe phase when nailing down any interaction project. It’s so quick to work with a tool like Visio to compose multiple iterations of ideas and use those iterations in a “clickable” prototype. I guess in the end, the ability to ideate/prototype early with wireframes and continue this process with higher fidelity is key.
    Of course, every project is different and we need to be good at adapting our process.

  • Mimojito (aka Efren) Reply

    Although you elude to it you never really come out and say it: requirements. What are the business and technical requirements? These in turn help shape the IA and UI and ultimately the UX of the app, site or overall project.

    A clearly defined, laboriously refined and oft re-defined (scope creep) requirement document(s) helps at times speed past many of the mentioned phases. That’s in a perfect world.

    Nonetheless, knowing early on how things are meant to function from a business, technical and client-side perspective will ultimately help you through that rinse and repeat cycle. Sometimes not. Sometimes it’s a waterfall approach and you have no choice but to go straight to high-def mode.

    Overall, great article in trying to express the importance of the “ideal” process.


  • Jeroen Reply

    I found a relating article, although dating from 1997, really interesting: “What do prototypes prototype?” by Stephanie Houde and Charles Hill. (

    In the article they stress the importance of the purpose of the prototype, and put the fidelity discussion second. Firstly, you need to establish what you want to achieve/test with your prototype (functionality, look&feel, technology), and know for which audience it is intended. Communicating that purpose to your audience is therefore also essential. Fidelity, and other aspects determining your prototype, depend on the above. Often, the high/low fidelity discussion gets the overhand while that is not the most important issue.

    They also warn against the idea that low fidelity prototypes are used in the beginning, and high fidelity ones at the end of the process. This isn’t necessarily so. They talk about a case in which they investigated the three different aspects (functionality, look&feel, and technology), with three different prototypes, in parallel at the very beginning of the project.

Leave a Comment on This Article