How to get value from wireframes
Eleven years ago, I joined a small design agency. I was 20, and it was my first full-time design job. I spent the first few years at the agency focused on visual design. Can I make this texture more realistic? Would this website look better if the light-source was from a different angle? How could I get my buttons to be even glossier? It was common to hear a client pitch an idea, followed by myself asking a few questions, opening Photoshop and starting to design. Days later I would present the client with one or two visual directions, get feedback, make revisions, and start coding the site in xhtml. The best designers at the agency made the best looking websites.
As my career progressed, I learnt that showing the client a wireframe before I started on a visual design could save us both time. Wireframes, however, felt awkward. Their intent was to facilitate a space for ‘quick revisions’ before the client and I ‘decided on a direction’ and started the ‘design process.’ They were supposedly quicker to create than visual designs, and thus, quicker to change. However, wireframes sketched on paper were considered too unpolished to present to a client, so I would spend time creating digital wireframes. After presenting the wireframes, rarely did I find that they inspired any meaningful conversation. In fact, seeing the digital wireframes almost never led us to change direction.
Looking back, I didn’t find wireframes valuable because I used them to solve the wrong problem. They were used as a checkbox to move a project from ‘exploratory’ into ‘ready for design’—to prevent a client from changing their mind at a later date. What I didn’t realize then, is that at their best wireframes create a mechanism to break out of obvious design paradigms. They enable you to better defend the direction(s) you chose to pursue, and help you slow down to point in the right direction before you speed down the wrong road.
The Process of a Junior Designer:
The above illustration is from Julie Zhou’s article, Junior Designers vs. Senior Designers. It captures a trap that’s easy to fall into: Running with the first idea that comes to mind. If I could just make it look better maybe it’ll work.
It’s still common for junior designers to focus on visual design over functional design. Visual design is an obvious place to start as it’s easily shared and judged: Does this screen look like the current trend? Did it get many Dribbble likes? Is it flat enough? Do the gradients gradient enough? This is especially true for designers early in their career, or those hoping to get hired. Flashy visuals are quick to create, easy to put in our portfolios, point to, and say “I designed that.”
The Process of a Senior Designer
After a decade in the design world, I’ve learnt that how something works or why something is the way it is, is much more important than how something looks. Senior designers spend much less time on cosmetics, and much more time validating that they’re going the right direction. As shown above, senior designers come to solutions in a very different way.
Painting a broken car, no matter how great the paint job is, doesn’t make the car useful.
So, how do you avoid polishing the first idea you have? How do you come up with multiple approaches without investing a lot of time? How you decide if one approach is better than the last? Or, better than the next?
Wireframes that are useful
I want to share a simple technique I now use to force myself to explore and validate multiple directions before I dive into visual design. For the rest of this article, a “wireframe” is a sketch on paper. Paper wireframes are quick to make and reinforce that ideas are cheap and safe to throw away. Paper, also allows anyone on the team to take part in wireframing.
By using paper, we avoid confusing well-designed wireframes for good ideas.
The setup
Let’s get started. Grab a notebook (I like Borden & Riley’s Paris Paper for Pens) and draw a grid of at least 20 small rectangles. If you’re working on a mobile UI, make them roughly the aspect ratio of the device you’re designing for. For desktop UI, make them the aspect ratio of a computer monitor.
The process
Now, with your pen (I like PaperMate Flairs) fill each box with a different approach to the design problem you’re trying to solve. Sketch the most obvious ideas first. Get them out of your head, don’t stop until you’ve filled every box with an idea.
There’s little chance you’re going to be able to fill every box with a great solution, and that’s the point. You want to cover as much breadth as possible to move your mind from the comfortable into the unknown. If you’re struggling to come up with a new idea, push yourself to do something constrained: What if the menu is a radial? What if it’s only images? What if there are no images? What would Apple do? What would Google do? What if there are no lists or grids? What are different ways to place the most important elements closest to the user’s thumb? For me, more often than not, things start to get interesting after the first ~10 sketches.
If you’re trying to find the best way to layout a screen, it’s handy to create a key such as: T (title), V (video), RV (related videos), Sub (sub-navigation), etc, allowing you to focus on layout instead of UI elements:
Or perhaps a 💡 for links to documentation and a 📈 for analytics:
If you’re focusing on UI layout and elements you can sketch in higher fidelity:
At this point, your mind should be exhausted and all boxes filled. If the boxes aren’t filled, force yourself to continue. If you still have remaining brain juice, flip the page over and sketch more ideas. Reach the end of the tunnel. Get strange. Get weird.
Now that all the boxes are filled, look at them and pick a few ideas that look promising. Talk them through with someone and get their thoughts. Forcing yourself to verbalize concepts often reveals new and interesting ideas.
Repeat the process
Rarely, if ever, is visual design the best next step. Again, it’s important to not commit to pixels at this point. Keeping your ideas on paper makes them lightweight and non-committal; anything can be changed.
Now, take the promising ideas and draw them in higher fidelity. Draw larger boxes on a new page—I find four-boxes on a A4-sized page works well. At this point we’re trying to see if the ideas hold up with more detail:
Once you’re finished, it’s beneficial to show the higher fidelity ideas and get feedback. In the past, I’ve walked a client through iPhone photos of the sketches. Because you haven’t committed much time to these sketches, you should be able to take feedback without fearing the additional time it may cause.
Next steps
In very little time, you’ve filled pages with various approaches to a problem. You’ve forced yourself to go broad with your thinking and come up with at least a few non-obvious ideas. You’ve gotten feedback multiple times, and ideally, a few of the ideas showed promise and you explored them in more detail. You haven’t got caught up in color, type, lighting, or any other aspect of polished visual design. The feedback you have received is high-level and conceptual rather than aesthetic and over-specific, and easily applied to more sketches.
What you do next is up to you. At this point, I’ve found it helpful to lean on the Google Ventures concept of ‘Searching for Conflicts’ to help find the differences between the ideas and decide the best way to proceed. More often than not, I’ll repeat the sketching process and think about how the promising screens fit into a flow. What comes before this screen? What comes after? After I’ve sketched different approaches to the flow, I’ll create digital prototypes to see how the flows feel on a real device.
Hopefully by following this technique you’ll be able to quickly generate multiple ideas, support the ones you chose by comparing them to other options, and avoid committing to your first idea early in the project.
Bonus: Applying this technique to things other than design
While I was working at Medium, Nick Fisher, who wrote many of the Medium tweets, told me that he’ll often write a tweet ten different ways before picking the one to publish. He forces himself to write it in different ways before he settles on the right one.
