Wireframes are dead
A few years ago I was lucky enough to be invited to speak at Misk in Riyadh, Saudi Arabia, as part of my work supporting 500 Startup portfolio companies in the MENA region.
Even though I’d spent the previous week getting to know startup founders from the region, and learning what the Saudi / MENA startup ecosystem looks like more generally, I honestly wasn’t sure what to expect. Other than being generally intimidated by the aura surrounding Misk, the Crown Prince MBS’ personal foundation, I really didn’t know how the content I was going to present would land with the audience.
Does anyone care about UX the way that I do? Would I come across as too US-centric? Would my, ahem, colorful language put people off?
As it turns out, the audience was great and super receptive, even being so kind as to laugh at my dad jokes. So imagine my surprise, about halfway through the allotted time, when I flash up what I figured to be a throwaway slide, only to hear audible ::gasps:: from the crowd.
Here’s the offending slide:
Not that controversial, right? Or so I thought.
Almost immediately various hands shot up across the audience, and I knew that I’d hit a nerve. The first comment confirmed my suspicions:
So wait — you mean to say that we shouldn’t be making wireframes?
Now, while I have strong opinions (loosely held) about many topics related to UX, I’m almost never prescriptive. I like to help people chart their own course and make up their own mind about things, but in that moment I had an epiphany: I really do believe wireframes are dead.
The group and I had a good debate about whether or not wireframes are a valuable artifact anymore, and while I’m not sure I managed to convince everyone of my position, I definitely made a strong case.
So here’s a recap of why I think wireframes are, in fact, dead:
Design Systems > Wireframes
First, a quick look of how we got here as an industry.
Just about 8 years ago, Material Design was released and changed everything. From my vantage point on the Adwords team at Google, I’m embarrassed to admit I wasn’t initially convinced it was that big of a game changer. It was mobile-first, didn’t handle any enterprise patterns, and was missing a ton of stuff to make it fit in with my UX workflow (i.e. it only worked in Adobe Illustrator). Besides, wasn’t Bootstrap enough?
Fast forward 2 years, and the story had shifted: Material was on its way to penetrating the UX market, had a ton more non-mobile components to work with, and Figma was quietly making waves in the tool space, making it even easier to leverage design systems like Material.
Bit by bit, I slowly found myself making fewer and fewer wireframes. I’d either copy an existing component I had made myself, or use one off the shelf from a design system like Material and customize it to my needs. I mean, why bother drawing a grey box, when a fully-formed popup, form, or button was a click away? One that I knew developers could build, and wouldn’t require me to spec out for them? It was a no-brainer.
Get Felix Desroches’s stories in your inbox
Join Medium for free to get updates from this writer.
Even more critically, I had always found the transition from wireframes to middle or high fidelity mocks painful — it meant needing to go screen by screen to update all the grey boxes to more realistic UIs, or if we go far back enough, handing the wires off to a visual designer (wasting precious time). By starting with high fidelity components from an approved library, there was effectively no transition anymore. What I designed could, in theory, be built tomorrow by my fellow engineers. Magical.
Wireframes test the wrong thing
Wireframes were originally designed to let designers do two things: to save time when building designs and prototypes, and to get user feedback unencumbered by real content in an “unbiased” way (more on this below). Heck, as late as 2012 I was conducting user feedback sessions at Dreamforce using paper prototypes mounted to foam core board! And remember back then Sketch was nascent, and many designers worked in Illustrator, or even Fireworks (RIP).
Back then the web was a weird place when it came to interaction design. Everyone was reinventing the wheel, tackling each design problem as if for the first time (because sometimes, it really was the first time the market had seen it).
User registration flows were a mess. Buttons were all over the place (remember the Material “FAB” button, anyone?). Parallax took over for a hot second.
And then ever so slowly, designs started converging on which patterns worked best. The various types of layouts that made sense for a given application, for example. Which interactions or micro interactions were going to stick around, and which ones were a fad. While one byproduct of this convergence was a web that started to feel very “same-y”, it did have the benefit of providing a consistent experience to users — and the UX designers working behind the scenes.
Effectively, many commonplace interactions and layout patterns simply weren’t up for debate anymore — and just like that, wireframes went the way of the Dodo.
Content matters, dummy
After working with wireframes for years, I started noticing that every discussion with a user converged on the same place:
So…what content would you expect to see in that little grey box?
Assuming the layout and interactions aren’t confusing, this is, of course, the right question to ask. It’s the important question. It’s what a UX designer needs to know to build an effective UI. But starting with wireframes was slowing things down, adding unnecessary steps to the design lifecycle. Why not test the team’s best candidate for what real content looks and feels like right now, rather than in some future research session?
The age old criticism of skipping wireframes was that it would result in “user bias”, muddying the signal around layout and interactions. But if, as I made the case for above, interaction debates were a thing of the past — why not get actionable feedback right away on what actually matters?
The shift to Product Designer
When I started in UX, roles were very differentiated. I was an Interaction Designer, which meant that I was supposed to focus on layouts and workflows. Visual Designers took what I came up with and added polish (or if coming from wireframes, redesigned things entirely). UX copywriters would take a pass at content and copy, while UX researchers and Usability Testers handled the validation aspect of things. Brand Designers would supply approved imagery from Marketing. UX Engineers would make sure everything looked good on the code front. So many different roles, all to make a single UI.
And then slowly, things started to shift. Interaction Designers became UX Designers, absorbing (some) visual design and research responsibilities. Fast forward to today, and Product Designers (nee UX Designers) kinda do it all: layout, pixel perfect UIs, copy writing, and user research. I think bundling these skill sets into a single role makes a ton of sense, but what it also does is put a burden on the Product Designer to be hyper efficient — so hello design system, buh-bye wireframes.
Postscript
I can feel the objections heading my way already —
“So what, designers aren’t gonna use sketchbooks anymore? Those are technically wireframes, right?”
Totally right. Just because I think wireframes are dead doesn’t mean that designers won’t continue drawing little boxes with pen to paper. But what I really do think is dead are wireframes made out of pixels. There’s just no need anymore.
What do you think?
