Everything You Know About Wireframes Is Wrong
Okay chill, not everything.
First, a designer’s confession: wireframe is a cool catch up phrase, fitting neatly into those polished design process charts but… I rarely use them. Sketches — yes, I sketch to get that first kick of a nailed interaction. But wireframes has always felt like a waste of time. Especially if you’re working with a design system that covers all the very easily accessible and flexible Lego blocks. It’s just a matter of breathing some component life into those sketches and — voilà, the prototype’s ready to ship!
Who this doesn’t resonate with haven’t lived, I swear.
Design process is a fascinating experience. It might go linear: research, sketch, design, fight with devs. But more often than not, it’s more like:
You sketch an interaction, it makes people generally happy, even users seem to get it during concept testing, you show the prototype — and boom— a monitor filled with sour faces closed in rectangular shapes shines on you on a Friday morning — which was supposed to be the beginning of a great adventure. All of the sudden your weekend showers feel like hard work. You re-live the 6 months of your life on the project in your dreams, escaping people with shark-heads breaking into your home. What went wrong? Do your designs suck so bad? Maybe you should consider another career change. Maybe open a café.
Who can relate, let me give you a hug.
Or at least this piece of advice I have learnt the hard way: if your key stakeholder group consists of more than 3 people, you gotta adapt your way of communicating.
Let’s re-start the process: you sketch an interaction, it makes people generally happy, even users seem to get it during concept testing, you show… — you show the flow encapsulated in a grey-scale set of rectangular shapes (ekhem… wireframes).
What does it do? Articles of the NNgroup teach that it helps come up with a solution faster, as this method strips the conversation from any (unnecessary at this point) comments on visual design; it’s easier to focus on the problem and find the right solution with minimum distraction. But what if there’s another reason for you to start implementing wireframes into your process?
In order to find the right solution, you need everyone on the team to understand the problem. And for a second here, I’m not talking about the kind of general problem, like: users want to create tasks and share them with their colleagues. It’s more about the kind of tiny problems that you only discover along the way, deep in the process. For example: tasks live in a sidepanel — but since there are different task types, assigned to different people, with different due dates, etc., how will that affect the navigation?
Showing the hi-fi prototypes at this point will only cause more headache, not to mention half of your stakeholders zoning out, overwhelmed with complexity and visual load you ask them to take on, on a Friday afternoon (or heck, even Wednesday). Show them something simple — a few shapes with brand coloured buttons nicely contrasting with the neutral layout. Better still if you follow the early state prototype rule: one screen-one click.
And just like that — you killed two birds with one stone: people get it and they’re inspired to collaborate. It’s like when you give a presentation: your PowerPoint slides can either be “an-imagine-per-slide” kind of thing or “a-wall-of-text” — when is it more likely your audience stays focused? Following the advantage list: sour faces replaces with sparkling eyes — because even if people don’t like your solution, they’re now at least motivated to give you some meaningful input!
This really has everything to do with perception and how it works in humans. After months and months of working with the roughly similar looking screens, a designer’s brain learns to channel the vision to the important bits. We end up focusing on the relevant details because we’ve trained our eyes to “ignore” the noise. On the other hand, the stakeholder who only sees the screen for the first time is literally bombarded with all the elements, with literally no filters! And yes, I can already hear you, mean beings, saying that no screen should ever feel that overwhelming, but medical software is truly its own kind of realm. Comparing data-heavy-medical interface to a 3-step-onboarding experience is like comparing an octopus to an ameba. Octopuses (or octopi) are very hard to understand.
And we often get defensive when we feel we lack the knowledge. When we don’t understand, it feels almost threatening and to cope — we naturally strike back (i.e. sour face). Of course it shouldn’t work like that, but we’re talking Friday afternoon and heavy load right before Christmas. Don’t push your stakeholders into that corner, it won’t help them, it won’t help you, and most of all, it won’t help the product you are building and the users you are trying to support. Do everyone a favour and provide the best way to easily understand the most complicated flows: wireframes.
The next time you embark on a project, think of wireframes not only as a way to quickly figure out solutions but also a way to communicate complex interactions.
Here’s to you 🥂 for untangling the process with the right tool:
