You have wasted countless hours making wireframes that no one ever needed to see.
I have even seen entire design projects put on hold because clients or stakeholders were confused about the wireframes and lost confidence in the design team.
Delivering wireframes before the mockup or prototype seems like a logical way to reduce risk. You’re trying to give the client or other involved parties a preview of what the final design will look like.
However, wireframes tend to bring more confusion than clarity. They invite feedback about certain aspects of a design too early and expose stakeholders to unfinished ideas that should never see the light of day.
In practice, wireframes are usually a complete waste of time, but in a few rare cases, they are indispensable.
You can avoid the fallout that wireframes cause by using them with clear purpose in only very specific circumstances, and ditching them the rest of the time.
Always sketch first. Sketches are the fastest way to explore and evaluate rough design concepts. (I’ve written about how sketches should fit into the design process previously.)
Wireframes, on the other hand, are always slower. They must be made in graphics software or something like Balsamiq, which is more involved than simply scribbling on a piece of paper.
Committing a design concept to a digital format makes it less disposable. And, early in the design process, it’s critical that we designers don’t get too attached to rough ideas before we’ve exhausted our brainstorming potential. So, often, wireframes can cause us to commit to bad concepts too soon.
Wireframes should never be part of brainstorming or exploring ideas, except in a few cases where you need to collaborate with peers during early stages. (See below.)
Sketches are better for exploration, and, when no one else needs to see the concepts, beat wireframes every single time because they are faster and more disposable.
Never use wireframes to show work in progress to a client or stakeholder. Ever.
Clients and stakeholders rarely understand the difference between a wireframe and a polished design mockup. Often, even after you explain that the final design won’t have the same colors, fonts, spacing, and aesthetics of the wireframe, people will still get hung up on those issues.
They mean well. They really do. But, non-designers rarely understand how to approve a layout or interface concept without looking at details like fonts and colors. They will struggle to evaluate only certain aspects of the design, which the wireframe is supposed to demonstrate, and will instead judge every aspect.
Thus, showing wireframes will force you to take a pause in your project in order to explain and train more, when you wouldn’t have to if you’d just skipped the wireframe stage completely.
Further, when you allow a stakeholder see an early design concept in the form of a wireframe or rough mockup, you are inviting feedback into the design process too early.
My rule is to never present incomplete ideas or variations of a design. Anything I present to a client is my final decision. Even when I do use wireframes—I do, and I will get to that—they represent my best solution to the problem and not a rough concept.
Don’t let wireframes be a cop out. Don’t defer your job—deciding on the best version—to a client or someone else. Pick the best concept and present that.
I’m a huge advocate of setting expectations and making sure the client understands how you make design. I invite clients to share ideas early in my process, and I work hard to set clear expectations, which helps me to avoid lengthy design revision cycles.
However, you can set clear expectations and allow the client to get involved without showing unfinished work. Control what stakeholders see, and make sure that when you present something, that you need them to see it because you need approval.
If a concept isn’t ready for approval, never present it. Not even as a wireframe.
Note: I’ve been fortunate to find some clients who don’t get caught up on the visual aspects of wireframes. If you are able to work with clients over the long term, which I highly recommend, you can build rapport by delivering great work regularly. Clients will come to trust that you deliver great results so that you can use wireframes in clever ways, such as to avoid doing visual designs for every page or feature, or even alongside a living style guide to avoid mockups completely, and reap the time savings. But this is a risk if you haven’t built up trust with a client/stakeholder previously.
Okay, so I’ve taken a strong stance on wireframes here, but I do actually use them! There are cases when wireframes are completely indispensable and worth the extra time they take to create.
Even as a designer who writes heaps of code, on complex software projects, I will still run into cases where I don’t understand how a feature might be built on the back end.
In those cases, I create a wireframe to share with a developer to discuss my concept, so that they can vet it from a technical point of view.
I admire and respect developers, and the last thing I want to do is cause them to end up stuck with a design that’s ridiculously difficult to build.
So, in cases where I don’t understand how development will work, or if I’m concerned there might be broader technical repercussions, like speed, availability of data, or causing a developer to spend 2 months writing a new API, I formalize the concept into a wireframe and go discuss it.
In these cases, wireframes not only provide designers and developers with a way to collaborate, but they can also prevent those classic designer vs. developer battles. Wireframes can save your relationships at work and reduce conflict. They are well-worth creating in those situations.
Many designers are hesitant to involve developers so early in the creative process. However, if you are invested into designing something that can function well and is realistic to build—which all designers should be—sometimes you need to show your early concepts to developers.
Every single time I have used wireframes in this way, developers have been gracious—even those who have reputations of being pernicious—wink!— and appreciate the chance to help define how the feature will work.
The surprising part is that when I have approached developers with what I thought would be a complex technical problem, nearly every time they surprise me. I have seen wireframes leading to developers embracing the concept and putting in extra work to find a technical means of supporting it. But, even better, great developers often surprise me with a way to make the interface even more elegant by supplying a cool new technique I hadn’t heard of.
Inviting developers to vet complex design concepts pays off every time, and wireframes make it possible.
When you’re working as part of a design team, wireframes become a useful tool for offering up your best concepts for discussion and critique.
While I prefer sketching, I also believe that sketches should be ugly and condemning anyone else to deciphering them is cruel and unusual.
So, when I’m working on early stages of a design with other design pros, I spare them the grief of looking at my scribbles by sharing a wireframe instead. What can I say, I’m nice like that.
Seriously though, while I wrote that committing a design concept to a digital format formalizes it, that can be valuable when discussing with other designers. You can’t critique a sketch, after all. A wireframe feels more formal and worthy of serious consideration for a team.
And, of course, other designers are capable of discussing only certain aspects of a design, like layout and usability, and won’t get hung up on the aesthetics of a wireframe like a client or other stakeholder might.
Too often, wireframes are the maladjusted offspring of sketches and mockups. Their purpose is unclear. The role of a wireframe is often confusing because we present them without a clear question mind.
However, if you set clear expectations about how you are using wireframes for each project and what response you are looking for, they can be useful.
Use wireframes with clear purpose but never as a placeholder for complete thoughts.
Design's Iron Fist is a collection of essays with advice for both design learners and professional designers. It's been featured as one of the best free design books by the Creative Bloq and the AIGA.
Enter your email address and I'll send it to you along with my newsletter. You'll get 1 email per week on average. More details here.