Do the Wireframes

June 8, 2020
By Ryan Hatch

A while back, the blog post Why Wireframes Are Becoming Obsolete was published on The Startup. It’s hardly a novel take anymore, yet the topic still strikes a chord on Design Twitter and elsewhere. The article’s argument, in sum, hangs on a few points that deem wireframes cumbersome and unnecessary, wasted effort between research and final design phases. It’s a fun thought to play out, no doubt, and one irresistible to an industry tasked with eliminating inefficiencies. And as someone for whom wireframes help pay the bills, my curiosity too was piqued. I opened the article with hopes of gathering insights that would improve my day-to-day work and perhaps read what might serve as the definitive articulation, ending the debate, and my Sketch subscription, once and for all. Instead, I came away confused and left further convinced that wireframes remain an integral point in the process of building a good user experience.

One part of the post claimed clients no longer get hung up on button color, and therefore, it’s smarter to bypass wireframes and present full designs. That is just not true. Clients are people and people get distracted by things that don’t always matter. And that’s perfectly fine. Clients are supposed to ask questions about small details. Later, the article said to do away with wireframes because design systems can take their place. Well, yes. But, critically, wireframes are necessary to build these libraries in the first place. Finally, toward the end, included was a back-of-the-napkin-like sketch that was substituted for a wireframe. But it looked awfully like a wireframe to me, raising the question of what a wireframe and its process is supposed to be at all.

How wireframes are traditionally defined can be found at Usability.gov, which calls them color-less, “two-dimensional illustration of a page’s interface that specifically focuses on space allocation and prioritization of content, functionalities available, and intended behaviors.”

This type of definition works at a base level, yet its runway falls short, opening up the practice to criticism and strawman arguments, like those laid out in the above article, that distracts from what I believe is their broader purpose. Opening the aperture, wireframes are as much of a Thing You Produce as much as they are a State of Things. Roll your eyes, I deserve it, but the point is, wireframes are as much about level-setting a project and making significant business and architectural decisions as they are nesting symbols in Sketch.

Certainly, what works for one doesn’t work for all. If you or your team has figured out a way to eliminate paper and pencil and cancel design software subscriptions while maintaining UX thinking that translates to solid designs and development — that, you know, can simultaneously be shared and discussed with stakeholders and clients — well, awesome. But chances are you or your team (and stakeholders and clients) needs something of a retrievable, visual file to reference, share, and discuss, one that houses research, content strategy, and critical use case decisions. Indeed, the value from wireframes does not just come from the final product; it is the thinking behind them that provides utility, which is then cataloged. The state of things. And while it’s possible the practice of wireframes could stand a refresh or begin to take different forms altogether — like, say, replacing grey boxes and bracketed Lorem Ipsum with paragraphs of text throughout blank pages that describe modules and user actions — for now, I remain unconvinced. If even only for internal purposes, traditional wireframes are from my view still the best building blocks for good user experience and design: digital, utilitarian, black and white sketches that can, again and again, be edited and critiqued and shared around the world in seconds, especially now with remote work and teleconferences dominating our near future.

Because that’s the point. Wireframes’ main purpose is not meant to faithfully represent, to the pixel, what a final product is going to look like. Wireframes are the blueprints, not the lasting spirit. They’re meant to spark discussion and demonstrate thinking around information architecture, various user paths, CTAs, design library builds, etc., and get buy-in and approvals while leaving open the interpretation of how the product comes to life, setting the stage for streamlined and successful design magic. Without this, without research and without hours of well-reasoned trial-and-error thinking, design teams are left on their own to make structural decisions that will likely need to be re-thought and redone. Why not save the money, the time, and the headache?

It is chic of late to offer the contrarian argument here. But skipping the practice of wireframes tells me there’s a latent desire to actually avoid doing the work. Sure, jumping from stakeholder interviews to final designs might save a week upfront, but it will undoubtedly result in an inferior product. Much as we may want, there are no shortcuts.