Consider us your emerging tech update. We blog daily about breaking news, innovation, success stories and more.
The Push, Sponsored by Mutual Mobile
The Push, Sponsored by Mutual Mobile

We'll send the top stories to your inbox.

Wireframes vs. visual comps: how they differ

By Selina Silvas / April 16, 2013



As an interaction designer, I’ve often been asked, and have not given a satisfactory answer to, “what’s the difference between wireframes and visual comps?”

What wireframes are

To answer the question conclusively, let’s first do an internal review of the artifacts of each. Wireframes are usually pictorial representations of information, features and user scenarios (not an exhaustive list). Usually they appear sparse — black, white and gray — and have a lot of accompanying annotations. It’s the first step in explaining an “experience.”

What wireframes aren’t

You will, of course, see some design in them as they are visual and they are solutions, but they don’t capture everything and shouldn’t capture everything. Visual comps use wireframes as a supplement, as a sort of requirements doc. But the visuals take the experience and start to make it real. Through them the experience gets fleshed out, things are put in their proper place, considerations for surrounding elements are thought out and things change.

Why do they change? This is the question we very often get from the client. And here is where the fundamental problem lies. Things change even though they’d previously been approved. How does that make sense? It makes perfect sense if you set expectations correctly, but that’s a different story. Things change because they need to. Otherwise, you get what happens more often than not — wireframes are delivered, approved, colored in and moved into development.

From data to design

Let’s not focus on the deliverables for a moment, but on who’s creating them. Imagine a scale: on the left is the visually driven thought process (design) and on the right is the data driven process (UX). For wireframes, the scale shifts more towards the data driven process. We ask a lot of questions about requirements, users, personas and research in order to create a framework for the software we are building. We start thinking about a lot of things that you can’t actually see, but that are analyzed by how we use things. We start to build a conversation, sometimes a very boring one, between user and software.

Now we must shift from UX to design. And when the shift happens, things change because we’re now aware of more than just blank placeholders and gray boxes. There’s color, images, buttons and even more considerations specific to the device we are building to. A shift in thought and process has occurred, responsibility has shifted and changes will occur. But that’s ok, because if we’ve done well as a team we’ll be designing with a shared vision in mind.

Decisions and changes are made for a better experience and as time progresses, focus changes and new challenges come up. A designer or design team that doesn’t shift will not be able to create a full experience. If change isn’t allowed, the product remains at a stage that’s not fully developed, not fully explored and ultimately not fully realized. It’s the mindset during creation and iteration that leads us to the differences between wireframes and visuals, not the deliverables themselves.