Have you ever wondered why product teams don’t just design the real UI from the beginning? Why do we make wireframes at all? Is it only so less talented designers can work on UI too? Can we skip wireframes if we get more experience? Or do wireframes do something that UI designs can’t do? These are not silly questions.
Wireframes exist for a reason. Understanding that reason might help you understand what your process should look like. And in my opinion, your process is the difference between a website design taking 3 weeks or 3 months.
Have you ever heard the expression “measure twice, cut once?” Comparing UX and UI to making a dress or a suit is not a bad metaphor, actually.
Wireframes are the measuring part. They are not a quick sketch, they are the plan! Just like when the tailor makes chalk marks where he plans to cut. That’s where you should iterate and make changes. Draw and re-draw. Gather requirements. Get feedback. Ask developers. Change your plan. Try different approaches.
Pixel-perfect UI is the cutting part. You should spend time on doing it right the first time, because it’s painful to change it if you make a mistake. It’s easy to make new plans (wireframes), but once you cut that fabric, it’s wasteful to do it again.
The final interface design of your product—with all its pixel-perfect icons, and carefully considered branding, and exact positioning, and layouts, and styles, and delightful details—is time-consuming to make. It just is.
Wireframes, not so much.
****
Think slow, draw fast.
Wireframes include a lot of thinking and ideas. Not everybody realizes that. They are not trying to look like the final UI, they are trying to illustrate solutions to problems. However, sometimes a solved problem is an invisible problem… so wireframes don’t get the glory they probably deserve.
The slowest part of your process should be the thinking/researching/planning part at the beginning. That’s where UX really adds value, and that’s what wireframes are made of.
Wireframes themselves are fast to draw and fast to update, compared to a full UI design. Your wireframes could use any colors, and any fonts, and they don’t have to be nice-looking or pixel-perfect at all (as long as you stick to the proportions of the device, more or less.)
In some ways, an uglier wireframe can even be a better wireframe! You won’t get stuck in as many conversations about how they look.
Before we go further, I should mention this: Just because it is easy to update wireframes, doesn’t mean those changes are easy or smart to build. Quick changes in a wireframe can be a catastrophe for the product or just plain stupid… so think first, defend your choices if you need to, and only re-draw when your thinking makes sense!
Updating a full UI design based on feedback can take weeks. Updating a wireframe sometimes only takes minutes. I edit wireframes while we’re discussing them sometimes (if the changes are minor).
You can make significant adjustments to a set of wireframes in a day or two. But if you add new pages and menus to a full UI design, it can take a long time to design something different.
But think about that for a second. If the advantage of wireframes is speed and flexibility, and they don’t share any of the technical requirements of final UI designs, that means that wireframes aren’t intended as a step in creating the final UI. They have a purpose of their own: technical iteration.
In other words, the whole point of wireframes is to work with developers. It’s not just a quick-and-dirty version of the interface you hope to do “properly” later. UX wireframes are a technical document!
Do you treat wireframes as a technical document, or do you treat them like the quick way to sketch your UI design? Or do you treat them as the cheapest way to visualize your ideas for the client?
If you don’t treat wireframes as a technical document, you might be making your own life more difficult, because you aren’t taking wireframes seriously. (!)
****
Information architecture doesn’t have to be pretty.
The reason we do wireframes in UX — and why they don’t have to be pretty — is to sort out the functionality and the information architecture. And since that process should involve feedback and several rounds of changes from developers, business stakeholders, and user testing: wireframes need to be technically accurate but suitable for rapid changes.
A good set of wireframes—including annotations about the function of every detail—tell the developers exactly how the product should work, from a user-oriented perspective. It allows them to plan the functionality in a technically-oriented perspective, and wireframes inform the UI designers about how the content should be structured. How the pages should be organized, how the different views and content will be loaded, and what data is required when.
Super important.
****
How it works is more important than how it looks.
In a technical sense, those are the “big chunks” of the front end code. If you only did those parts, the product would still look pretty rough, but it could still work perfectly. Things like styles, animations, images, parallax effects, transitions, responsive elegance are all “surface details” in a way (not exactly, but as a concept). Sure, they can improve the UX (or hurt it), but they don’t change the way the product works.
Changing surface details also doesn’t change the way the interface is built up in a technical way (usually), and you can add or change lots of little details to make the look & feel perfect without making anything different for the overall technical architecture.
Look and feel creates appeal, not loyalty. If you want users to stay, spend time on the functions. Then add the polish, the details, the character, and you magical designer’s touch.
****
Wireframes define features.
UI design doesn’t define anything,
but it communicates everything.
Features can be styled or interpreted or branded in many different ways, and the details added through UI design can make a big difference in the feel of those features, but UI doesn’t change the features themselves.
However, it is the final UI that will communicate functional things like affordance,it will direct the user’s attention via motion, it will improve clarity and usability with typography and layout, and UI design will make your app recognizable as your app. That’s critical shit! Not to mention all the clever non-functional details that make users feel like you care about them, and they should give your app a chance.
“It’s huge. Everybody agrees.”
— Donnie Trump, Expert in Everything.
I have shit on UI a little bit in this article, but I say it all with love, of course. We’re all in this together. The important take-away is: UX work enables UI work to add value, not the other way around. Annotated wireframes (and rough prototypes) are how we define the UX work. The faster we can iterate and improve that UX work, the better it is for everyone. And that’s why wireframes exist.
It’s also why you should stop making your wireframes so fucking pretty. Diva.
J.