Wireframes miss the plot on nearly every perceived benefit. Here’s how to stop wasting your time and produce better designs faster.
Wireframing definitely doesn’t double the amount of work for little perceived benefit and this caption certainly isn’t being sarcastic.
Wireframing has existed since the beginning of UX, and on the surface, designers assume it is a critical part of the process. Everyone in UX does it and insists it’s critical, so it must be…right?
But as time has passed, I’ve seen more and more justification piled on top of wireframes, to the point where UX folk insist it’s an abdication of your responsibility if you skip the step. If you don’t do wireframes, then you must be a bad designer, and you should feel bad! Or at least that’s what people on Linkedin tell me.
While specific benefits can come from wireframing, we must ask ourselves if the amount of effort invested is worth those benefits and if those benefits can be gained from other methods.
I used to be a huge proponent of wireframing. Still, as someone who converted to product design from UX and has never looked back, the justifications for wireframes are mostly smoke and mirrors, with nobody looking behind the curtain and asking why we’re doing something performative and wasteful.
I swear to heaven, if I ever have a PM or BA tell me to update wireframes to match a visual design again, I will throw them out a metaphorical window.
What wireframes originally were good for
The world where wireframes came about is critical in understanding why they exist. At the time, design disciplines were still nascent, and the tooling for our craft needed to be improved. Even when I started in the mid-2000s, you were lucky to get access to Visio — hell, I literally started in Microsoft Paint!
This meant that the only place to really design an interface was in tools *not* intended for the task — photo editing tools like Photoshop or publishing tools like InDesign, but change management was a total nightmare. Need to update a navigation across 100 views? Buckle up and get some coffee, it’s going to be a long night.
Because of this, an intermediate step where an interface could have the basics all figured out was needed. The layout would be approximate, typography abstract, and content FPO, and it needed to be cheaper and easier to make changes. We’d worry less about the specifics and focus more on the information architecture and interactions.
And thus wireframes willed themselves into existence.
What people claim Wireframes are good for
Over time, the UX discipline has added more and more justifications for why wireframes are an essential step in the process. This happened primarily because stakeholders and purse-holders didn’t understand why so much time needed to be invested in some shitty greyscale impression of an interface, and in their defense it’s perfectly understandable. Wireframes *were* important because we still didn’t have better tools to handle the things that we needed to solve iteratively:
Hierarchy of content and features.Information architecture, verbiage, and copy definition.Process and interaction flow/sequences.Rapidly test new ideas and validate them with users.Keeps stakeholders from focusing on ‘visuals’ at the expense of other UX considerations.Photo by Jason Goodman on UnsplashWe’ve made wireframes synonymous with low-fidelity, but all they are is a low-fidelity option.
But then more toxic reasons started to bubble up — that visual design was merely aesthetics, and making anything that looks like a “final” design would do nothing more than confuse stakeholders and users, and would take away from the vital work of defining interactions, content, and IA. A myth around back-end engineers being incapable of understanding a final design and can only comprehend wireframes emerged. I have even heard UX designers claim that users and stakeholders don’t understand visual design and should only see wireframes.
For what it’s worth, I have only seen users need clarification on wireframes, never by visual design. As for stakeholders, UXers could learn how to speak to them without saying, “Ignore the layout/colors and just focus on the content.”
“We don’t do pretty!” UX designers would proclaim! “I do the real interface work, not the foo-foo UI.”
Why wireframes don’t save time
Fast forward to the modern day — the times of using Photoshop for visual design have long since gone, and UX & product design has exploded in terms of growth. We have products and services up the wazoo and more interface design tools that I can count on. Figma, the behemoth nobody likes anymore, is worth a few billion bucks.
This means that the tools we use to wireframe are *the exact tools we visually design with.* It is no different in terms of speed to select Arial as the typeface as it is to select the branded one. Selecting a brand color for interactive patterns is no faster or slower as it is the default blue. You are just as fast at laying out a greyscale option as you are a detailed one.
And we have yet to mention design systems — the advantage that wireframes had of deferring visual design choices is obliterated if your company has already invested millions into a design system that has already thought of all that for you. There is zero difference in using a wireframe UI kit and just using your existing design system. None. Stop wasting time.
Serhii Khyzniak, “Wireframes vs Visual Design,” is a great example of how the two deliverables have crept closer and closer to one another.
Dirty Secret: “UX” is never final, even if you’ve moved into visual design
There’s this myth that wireframes will get signoff by stakeholders, and only then we’ll focus on visual design and aesthetic choices. But ask yourself this — when was the last time an interaction, content block, or feature set wasn’t changed or modified during the “visual design phase”? Every project that I have done UX on with a distinct visual design phase ALWAYS had modifications to the work I had already done. I swear to heaven, if I ever have a PM or BA tell me to update wireframes to match a visual design again, I will throw them out a metaphorical window.
Do you like low fidelity because it makes things easier for people to understand and give input on? Or is the truth that it makes things _harder_ for others to understand and that we _like_ that because it allows us to lord our expertise over others and avoid criticism? If a stakeholder isn’t interested in commenting on the IA and cares more about other things closer to their expertise, then why are you trying to fight that? — Sean Dexter, “Wireframes are becoming less relevant, and that’s a good thing”
So, we don’t save time by wireframing anymore. However, we still need to focus on lower-level decisions before worrying about the presentation layer of an application (i.e., visual design, what I call the “interactive design for your eyes”). We’ve made wireframes synonymous with low-fidelity, but all they are is a low-fidelity option.
Fidelity is a spectrum, not a deliverable
We need to get it out of our heads that there is this binary in fidelity, and instead, we should think about fidelity as something that increases until the design goes into the backlog. Fidelity isn’t a distinct step or an artifact you produce, but a constantly updated prioritization of what you need to work on next.
Don’t have an image for a masthead? Sure, greyblock it. But maybe you should instead go and find an image until you can find a better one. Designing with placeholder content is never a good idea, even if that content is going to be iterated on.
So why do wireframes still persist?
For many designers, it’s simply how to do design a UX interface. In the book, “Wireframing is For Everyone,” there’s something telling:
“Wireframing is a language for communicating user interface ideas which helps developers, designers, product managers, and stakeholders think about and understand the big picture structure of a website or app without being distracted by the details” — Angeles, Barnard, & Carlson, “Wireframing is For Everyone”
Why do wireframes endure? Partially in part because they retain the appearance of something technical and precise. They have the air of a blueprint or technical specification, ruthless in their disdain for anything but the most ‘critical’ of elements.
But given how much a design can change from a ‘wireframe’ to a final design ready for production, that precision is imaginary.
Photo by Jason Goodman on Unsplash
Wireframes are just shitty visual design because visual design is intrinsic, not optional.
Here’s the problem — wireframes, whether UX designers want to pretend otherwise or not, are still a visual design. You are still designing an interface with visual language, and you’re just punting on decisions still critical to the experience.
You are still choosing typographical styling, just a “wireframe” one.You are still designing the layout, just not with realistic consideration.You are still blocking out elements in a concrete fashion, despite insisting a wireframe can change.You are still choosing colors, even if 80% of them are grey and 20% of them are the “wireframe blue.”
Many UX designers still light up like a Christmas tree if a visual designer moves an element. If wireframes were just about interactions and content, why are we getting in a tizzy if they move a text link?
Visual design is not avoidable or optional — it is as critical to usability, learnability, and cognitive load as any interaction or IA choice you make. And how do I know this?
Fidelity isn’t a distinct step or an artifact you produce, but a constantly updated prioritization of what you need to work on next.
Because wireframes are still a visual design, just a lazy one. And that means double the work.
(I have an article on why visual design should be distinguished from aesthetic design, but that’s coming.)
Do these Lofi activities instead of wireframing
By abstracting low fidelity away from wireframing, I have become 10x more productive as a designer. I have fed a backlog developed by 12+ engineers with months of roadmap by making low fidelity lower effort, but faster in defining my interface needs.
With these options, you are focusing *exclusively* on the things we find essential about wireframes without using visuals to represent them. The speed savings are significant, and the work quality is higher.
Here are some things to consider doing instead of wireframing:
UX State Outlines
This is one of the most rudimentary, and I still use it regularly when I need to move fast. What are the needs of the interface state I am designing, and what is their priority?
I then put all of that into a basic outline. I move things around. I delete things. I can also quickly use them to link a flow together without worrying about designing a dropdown or a button.
These are crazy fast to generate and iterate on, and I’m not worried about what interface particulars.
Grey Blocking
Sometimes, I need to get a WAG (wild-ass guess) on how much space I can / should allocate to patterns. But instead of wireframing, I grey block.
Grey blocking is nothing more than roughly out a layout with grey blocks. Think of everything you put into it as FPO — it’s just there to give you a feel for how much space might be needed.
I often use these with a state outline if I really need to figure out if I can single-state a feature or if it needs to be designed across multiple states.
Think of grey blocking as a designer’s WAG (Wild Ass Guess)
Design system
I mentioned this before, but why can’t you “wireframe” with a design system if your team is already using one?
Designs can be ‘final ‘once they’re ready for the backlog, and that doesn’t change if the primary interactive color is already defined or if layout standards are established.
If you’re worried about pixel perfection, don’t be concerned about pixel perfection! You can tighten a design and mature it as you work on it. Again, fidelity is a spectrum, not a step. The process is sped up significantly because you’re not wireframing and ONLY THEN transitioning it to your established system, which just doubles up the work.
If your team has an established design system, then grey-scale wireframing is even more of a time waster. The visual language is already established for you.
Whiteboarding / Napkin sketching
This is a practice that many of you already do, but the problem is that you’re doing it *before* wireframing rather than in lieu of it. Get your design to vomit onto a board or piece of paper quickly; don’t be precious about it, and then get to designing.
Note: Do *not* confuse these for the only other design practice I find more useless than wireframing — paper prototyping. Avoid that design theatre at all costs. It’s a seductive distraction that burns effort.
It’s hard finding images of whiteboarding that I’m legally allowed to share.
UX Grammar / Conceptual Grammars
The following two are effectively an evolution of page state outlines. While more formal than PSOs, they produce fantastic work in spaces where the problems or workflows are detailed or complex. Daniel Rosenberg speaks at length about UX grammar in his book “UX Magic (https://www.amazon.com/UX-Magic-Daniel-Rosenberg/dp/1708061614),” which I strongly recommend.
Javier Aragones also has a fantastic article on this new tool and why it’s so valuable:
https://uxdesign.cc/have-conceptual-grammars-finally-arrived-to-ux-design-26c088edc5d9
Object-Oriented UX — OOUX
I won’t lie, this is my new favorite, and I’ve strongly advocated it over the past few years. Sophia Prater is onto something extraordinary here, and I thoroughly recommend her training courses on the subject. OOUX is related to conceptual grammars, but far more codified and cross-beneficial.
OOX does a fantastic job of breaking down all the needs for individual patterns in an interface and, more importantly, the relationships between them. It’s a distinct visual that’s very easy to grasp for non-designers. If your stakeholders need help staying on task with wireframes or visual designs, OOUX is surprisingly effective as it strips out anything confusing about an interface. They can focus exclusively on priority, hierarchy, and relationships between objects..
ORCA mapping also helps you simplify the number of patterns you develop for the same information/content, making your project more scalable and sustainable for engineers (who, in my experience, love a good ORCA map).
Timothée Goguely has a great ORCA Map for figjam that’s a fantastic starter artifact: https://www.figma.com/community/file/1120705007006600427/ooux
In conclusion
Wireframing had its place and time, and I don’t mean to say that the process doesn’t have some value. But as designers living in a world where we’ve failed to justify our value to stakeholders, we MUST be mindful of how we spend our time and how we can be more effective and productive.
This isn’t 2004 where we needed final_final_really-final_designs.psd. We aren’t stuck using Omnigraffle or other tools that are not purpose-built. Question the orthodoxy around wireframes, and you might be a better designer. I certainly am.
Stop wireframing (but still start low-fidelity) was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
