The Right Fidelity for the Job

Sketches, prototypes, and wireframes. Oh, my.

For many people who aren’t UI designers but have put on the hat, the entirety of UI and UX work is embodied in The Mock-Up Tool. And if you’re a regular reader of my articles, you already know that I have this thing about mock-up tools — or, at least, this thing about the perception that a mock-up tool is all you need to get the UI job done.

But there is an entire spectrum of tools out there that are essential for doing good UI work. That spectrum covers a range of fidelity. If you’re doing UI/UX work and you’re not working at the right fidelity for the task at hand, you’re wasting time and effort. So let’s talk about working at the right fidelity at the right time over the course of a project. We’ll talk about sketches (lowest fidelity), prototypes (any fidelity, but usually low to mid-level), wireframes (mid-to-high fidelity), and comps (highest fidelity).


The first stage of UI/UX design should never, ever be done in a mock-up or wireframing tool. It should be done with pen and paper.

Sketches are the lowest fidelity in the world of UI/UX, and every task should begin with sketches. And if you’re not doing any sketching because you think you can’t draw, you should take a quick detour and read my recent Medium article about this, and then come back.

Don’t worry, I’ll wait.

So, we’re clear on this whole I can’t draw thing being bunk, right? Good, let’s proceed.

The thing to remember about sketches is this:

They’re about getting all of the bad ideas out of the way first, so that the good ideas can follow.

Unless you’re constructing a UI flow that’s completely dead obvious (and you’d be surprised at how even the simplest UI flows have their hidden complexities) you need to begin with sketches in order to generate quick, easily discarded, top-level ideas. You’ll discard almost all of your initial sketches, and that’s exactly as it should be. As I say in the previously linked article (that you read, right?), sketches are about trying out initial, early, rough ideas.

Sketches are the warm up to your workout. They’re the prep work you do before you do your best work. By sketching out your initial ideas in small boxes that only contain the high level pieces of information, you’ll be working at the macroscopic level, which is what you need to sort out first before you begin polishing up the finer details with a mock-up tool.

Early sketches for an app. Nothing more fancy than a black marker and a grayscale marker, to add shading for buttons.

Now, it’s at this juncture that mock-up tool lovers will inevitably tell me, “but I work faster in Balsamiq.”

No, you don’t. Trust me on this. You really, really don’t.

Nothing can be faster than putting pen to paper and drawing boxes. Mock-up tools have given those that think they can’t sketch a false sense of security and freedom, while actually constraining their thinking to the default boxes and buttons that come with the tool, and even possibly making them work more slowly as they fiddle and mess around with getting boxes and buttons positioned just so. In the time it takes the average user to make a page mock-up in Balsamiq, you could easily generate and iterate on many thumbnails of many different ideas, some of which might not even be possible to mock-up in a tool with only so many boxes and buttons to use.

The takeaway: use the sketching phase to generate a bunch of ideas, both good and bad, and let the good ones float to the top. Those will be the foundation for the next fidelity of UI work: the prototype.


Static pages can tell you how the layout will look, but they can’t tell you how it’s going to feel to use. That’s where prototyping comes in, and it’s an essential stage of UI development for anything that isn’t a dead obvious screen or two.

A paper prototype of a complex screen for a video game matchmaking session.

Prototypes come in a few flavors, ranging from low-fi paper prototypes made from sketches, to mid-fi prototypes made with detailed wireframes in which users can use limited interactions, like taps or clicks, to hi-fi prototypes that are actually coded up to mimic as much of the full suite of interactions as possible.

For me, the best bang for the buck (with the buck being my time) is in the low- to mid-fidelity range of prototyping. In a very short period of time (ranging from minutes to half a day), a UI/UX designer can roughly sketch some screens, cut out some pieces of paper for elements on the screen that change, and put that in front of people to interact with as the designer plays the role of the computer. You get tons of usability data with zero engineering time spent. Who wouldn't want that kind of return on investment?

If you’ve iterated quite a bit on sketches and early paper prototypes, and you've gone into the more detailed wireframe stage (more on that in a moment), you can do mid-level prototyping by importing your wireframes into apps that allow you to string them together with hot spots and interactions. InVision happens to be my favorite for this task. And you can use these same apps on your basic sketches, too, if you want to present a cleaner, more share-able way to interact with your prototype.

There are a lot of resources online that will teach you the ins and outs of basic prototyping — a search on paper prototyping will get you off to a great start.

The takeaway: use the prototyping stage after your sketch work led to something that feels like the right flow and layout, and put it in front of people to test before you spend even one minute on engineering time to implement it.


Ahh, the wireframe. The tangible “deliverable” of UX work. There’s a growing consensus in the UI/UX field that, with the ubiquity of dynamic prototyping, the wireframe is dead — why do a static wireframe when the tools to make real UI screens and pages in your app or your game are frequently at your fingertips? We’ll cover the wireframe briefly anyway, because it still has a place, although you may find that some of your UI/UX tasks don’t require this phase.

A really early wireframe for Super Monday Night Combat.

The wireframe is often the more polished version of the sketch, something you can deliver to a client or your stakeholders, and it looks like you spent some time on it. (Ironically, several wireframing tools now offer a “sketchy” look that will make your wireframes look deliberately low-fi.) If wireframes are a part of your workflow, they usually will come after the sketching phase, when you’ve rejected all of the bad ideas and the one or two good ideas have floated to the top. Those ideas usually get fleshed out in a wireframe.

Unlike a sketch, a wireframe allows you to get pixel-perfect accuracy of your design. Unsure if you can actually fit those elements on the screen and still have your touch targets be big enough? A wireframe can answer that better than a sketch can, because you can accurately control the sizes of your elements. And, like paper sketches, you can import your wireframes into an app like InVision or PoP, add tap areas, and share an interactive prototype with people to get some quick usability feedback, or to show clients or stakeholders for a flow demonstration.

The takeaway: wireframes can be the bridge between the rough but workable ideas that came from your sketching phase, and a prototype that people can interact with that has accurate sizes for design elements. Use them as a reality check on your layout ideas.


Comps barely fit into the scope of this article. Short for “comprehensive layout”, comps really fall into the realm of the visual designer and not so much the UX designer. But they represent one of the more final dots on the fidelity spectrum, so let’s talk about what they are.

A very early UI comp created for the game Space Siege.

Despite being high-fidelity, comps can actually be done at various stages of the UI development process, and the point at which they’re done will determine what kind of information you get out of them.

When done early on, comps are usually just an exploration of art style. In game development, a UI artist might do some rough comps early in the project to help decide what art style the UI might have. These comps likely won’t be based on any actual UI, but might try to represent some generic UI cases.

When done near the end of a UI task, comps take all of the information that was gathered from the sketching, wireframe, and prototype phases, and then put it all together into a complete visual package. Comps are static, but they show you at least how the final product should actually look.

The takeaway: while not an actual UX item, comps can be an item on a UI task list. When done at the end of the task chain, they can provide a satisfying, comprehensive view of what your final project should look like.

Work with the Spectrum

If you’ve been focusing purely on the mock-up tool to create UI, spread your wings — pull in other parts of the fidelity spectrum to streamline your workflow and enhance your design skills:

  • Sit down and sketch your ideas first. You’ll go through more ideas, and get to the good ones more quickly.
  • For even moderately complex systems, use your sketches as the foundation of a paper prototype. You’ll quickly find out if your design ideas actually work in practice without having spent precious development time on them.
  • Begin working in a higher fidelity, like wireframes, or even directly in your development tool, to create actual working UI. You’ll be more confident at this stage if you’ve worked out the problems early on with sketching and prototyping.

Good luck!