When I got into web design (way back in 2003!) wireframing wasn’t really a thing–at least I don’t remember it being a thing. Yea, maybe you did some quick sketches of layouts, but we were pretty much “taught” to jump straight into Photoshop and start making stuff.
I became savvy about being non-destructive in my editing of objects and agile at moving layouts around in an efficient manner. I could quickly work through my ideas and options and pick the “best” one for the project and present it to the client in an understandable way that made it easier for them to relate–more than any sketch I could show them, anyway. And this worked for me for a looooooong time, longer than it probably should have.
Fast forward to today and we’re working in a far more complicated environment where we can track user behaviors, intent, and we’ve got revenue requirements, developer questions, product manager roadmaps, and so much more to think about. Jumping straight into high fidelity mockups just isn’t going to cut it anymore when the projects we’re working on are exponentially more complex and dynamic than the six-page websites of yesteryear.
Focus on what the goal of the page is rather than the visual details.
This might seem like a no-brainer, but taking away any semblance of “visual design” has helped me focus on keeping the goals in mind. I’m not distracted by fonts, colors, or what photos to use (I do come from a visual design background after all), and I feel liberated by leaving that all behind to work on the task at-hand.
And this hasn’t just helped me–it’s helped my team as well. They don’t get distracted during meetings by “Why is that heading so big?” or “That color doesn’t exist in our toolkit!”. We all stay focused on the goal of the project in a deeper way than “Is that blue *too* blue for the main CTA?”. We focus on the content: how it plays together, what happens next for the user, or how we’re going to build that new component.
Not sure where to start? Try out this Ugly UI Kit from David Kovalev. It doesn’t have everything you need, but it’ll get you thinking in the right place.
Use as few icons as possible, write out the intended actions.
I read an article once (can’t find it now) that said it’s best to write out actions rather than try to place their icons in the mockup (ex. “Bookmark this Page”). Now I know why that is so important. Not all icons are universally understood, and working through your problem is not the time to be thinking about what icon (if-needed) best represents that action. It also helps you better understand that maybe you don’t need to use an icon for every action. In fact, it might be a better experience to NOT use an icon but to use a word rather or combination of icon and word.
“Use the 5-second rule: if it takes you more than 5 seconds to think of an appropriate icon for something, it is unlikely that an icon can effectively communicate that meaning.” Nielsen Norman Group
Beyond just whether or not the action calls for an icon, writing out the actions helps you to understand the complexity of the task you’re user is trying to accomplish. Are there too many actions in this flow? Do they all need to be here? Is there a better way to handle this?
Use Comic Sans to avoid confusion.
Maybe I’ll get flak for this, maybe I won’t, but typically I wireframe in Comic Sans. It signals to the people I’m presenting to and working with that this is work in progress and is by no means anything resembling final, if that even exists. Only once in my time have I presented a high-fidelity mockup with the intent to show an early idea only to find it going into production without my knowledge. I’ll never make that mistake again. ¯\_(ツ)_/¯ #liveandlearn
I’ve also presented a wireframe that used Comic Sans and my stakeholder was too distracted by it to give any constructive feedback. Just be prepared for those situations to come up and stay flexible to help the project move forward. Feel out your audience. 👐
Mark up your wireframes.
And no, I don’t mean code them; I mean write notes to explain why you did something or where you need more input or insights from another person. This technique has helped me tremendously when sharing wireframes through apps like Invision. Even if I’m not there explaining something, my work is explaining it for me.
“Thoroughly documented wireframes yield additional respect towards your UX expertise.” Jane Portman, UI/UX Consultant
I like to send wireframes to people before meetings to give them time to look it over, digest what they’re seeing, and put together their thoughts before jumping into whatever discussion comes next. Having my notes on there helps those conversations go more smoothly because they know how I arrived at my solutions, and we can go from there and get more meaningful input.
This is by no means a comprehensive guide on how to wireframe, and I’m always looking for ways to improve my workflow. BUT it’s a great place to start if you’re new to the design field or wireframes were just never part of your workflow. These points have helped me get into the right frame of mind about how to approach a new project and ensure that I’m being thorough in my design-thinking process and clear in presenting those thoughts. What are your wireframing tips? I’d love to hear them, drop them in the comments or Tweet them at me.
Looking for more reading on the how’s and why’s of wireframing? Check these articles out.