How to be great at building UI wireframes

Fri, Apr 26, 2013

As I tweaked some last bits of code and added a few comments here and there, I realized I was getting excited. This project I had been working on for the last few days was almost done. I was happy about the code I had written and started prepping for a code review. My co-workers had been asking how it's going and wanted to give me feedback, so I pushed and deployed my changes to a staging server.

What immediately followed was a humbling experience. "What is this?", "Why did we decide to do it this way?", "Won't this interfere with the rest of the product?", "How about if we do X instead?", "Arnor, what the hell have you been building?"

I realized I hadn't really discussed some of the things in the project, which initially was supposed to be a bit smaller. Now all these questions came pouring in, and I started realizing that maybe all the code I had written might, just as well, be thrown in the trash can, along with my pride.

This is when I learned, the hard way, that the first step in any kind of interaction design is to build a wireframe.

What is a wireframe?

A wireframe is basically a skeleton of your site, your app, your banner, whatever it may be and includes a rough version of the text, buttons, images etc. It is not a high fidelity mockup like a photoshop document, but a rough drawing. Something like this:

Usually it will also include additional steps, and user flows, indicating what you can interact with, how you interact with it, mirroring what you'd come up with in a storyboard.

Who should use wireframes?

A lot of people are under the impression that building a wireframe is completely useless and redundant. Though sometimes it can be, it usually is a great way to get your idea into visual form so you can communicate what it is that you intend to build.

Being great at building wireframes gives you a huge edge when it comes to building successful products.

Sometimes people think that wireframes are only for designers and you don't really need to have this skill unless you are one. First of all, I'd like to say that everyone is a designer, second: Everybody should be good at building wireframes. This includes:

  • Designers
  • Developers
  • Project managers
  • Product managers
  • CEOs
  • Your mom

What is the main purpose of making a wireframe?

The main purpose of making a wireframe is surfacing any feedback, any possible issues, any extra thoughts, ideas etc as soon as possible in the design process. If there's a way to get feedback on something that doesn't require a wireframe, even better! then you expose it right away. It's a painful experience, like I experienced first hand, to be well into a project and somebody says "I thought this would be like ANYTHING BUT THIS".

If you think you'll get feedback just as fast by writing code, or doing a design in photoshop, fine. That's great. Then you should not build a wireframe.

But usually those processes are at least a tiny bit slower. Even if you are an amazing developer/designer/builder. But chances are, it'll take orders of magnitude more time. That's why wireframing is the perfect tool to get all the feedback as soon in the process.

So, to restate:

Benefits of building wireframes:

  • Gives you a better picture of what you are building, even for personal projects
  • Faster iterations for getting to a good user flow
  • Easier to iterate on text/language/copy
  • Getting the whole team on the same page
  • Prevents misunderstanding
  • Surfaces assumptions that you may have, that you don't know you have

Downsides of building wireframes:

  • Adds an extra step to the design flow
  • Boxes your thoughts in the confinements of the wireframe, so it's harder to break out of the mold when doing a higher fidelity mockup.

When should you specifically skip doing wireframes?

Most importantly, it doesn't make sense to use wireframes for doing purely visual design. As in logos, photo cropping and placement, styling buttons and widgets. I'd say you can make pen/paper mockups for those, and those are a different beast and a totally different process. (And outside the scope of this post.)

You probably don't want to use wireframes when the feedback cycle is super, super slow. If it takes a week, few days, even a few hours to get feedback on your wireframes, sometimes it can actually hinder the process of what you are building. It's true that you might end up building the wrong thing, but sometimes (especially if you're doing client work) the constraints and mission give you enough guidance when it comes to the design and constraints, and then it might not make sense.

Sometimes your client and/or organization you work with might not be able to understand the abstraction of a wireframe. They might simply give you a bunch of unhelpful feedback, start brainstorming irrelevant ideas, and maybe start feeling like the process is too complicated and involved. Some people simply don't want to be involved.

There was an image here that has been removed.

Wireframing tools:

There are many, many tools out there to help you build wireframes, I've listed some popular options: I personally use Balsamiq. I think it's one of the more expensive ones out there, but I really like how ugly everything looks, and I feel like that is an important aspect of building a wireframe. If it's ugly, people won't focus in on mis-alignments, colors, borders etc.

Pen & paper:

A lot of people like to use pen & paper for building their wireframes. There are some benefits to doing so: More freedom, no learning required, not constrained by the widgets provided by the application you use. Some people like getting hands on and get to know things intimately. It's also super important when doing any kind of logo work, but that is way outside the scope of this post.

The downsides are that there's no copy-pasting things around (duplicating), you have to have good hard-writing, it's easy to get carried away in the details and it takes much more time to get your wireframe in the hands of others (since you have to take a photo, email, share link whatever).

Honest truth: It's a waste of time. Just get familiar with wireframing software, and adapt a fast workflow. If you are an artistic hipster, living in Williamsburg, who fancies themselves as a free thinker and can't be constrained by the boundaries in which the narrow minded software company has placed on its boxed-in software, I can understand that you want to pick up a pen and finally use your moleskin for something else than pictures of boobies.

However, if building wireframes is not your life long passion, but simply a means to an end, just get it done. (and iterate)

My workflow

There are many aspects to the design flow. Coming up with an idea, coming up with user stories sometimes helps, thinking about technical challenges of what you are building up front - at least so that who ever is the technical person has some form of a clear understanding how a feature can be built might work - that's why it's super important to start by writing a quick summary of what you intend to build a wireframe of for the people on your team

Rough workflow:

  1. Come up with an idea
  2. Summarize what you will be wireframing (a simple single line of email/chat is usually plentiful)
  3. Building the wireframe
  4. Get feedback
  5. If there's feedback, summarize it and go back to number 2.
Time boxing: Wireframes should be produced rather fast. Sometimes there are a lot of iterations, but the initial iteration shouldn't take more than 5-15 minutes depending on the size of the project. I think I've at most done an hour for a lot of complicated interactions that needed to come together.

Sometimes you are also thinking and basically using the wireframe as a means to brainstorm and contemplate ideas, that is of course fine, though the focus here is more on the git-er-done stage.

Once you've established the premise of the project and everybody's on the same page you can start getting your hands dirty.

The structure of a solid wireframe

The basic widgets you use are boxes, text labels, buttons, icons and annotations. For the most part, you can forget about everything else.

This probably seems obvious but start by making the frame in which you will be working with, be it a web document, your app, display slot, etc. Get the proportions roughly right, but don't worry about the exact proportions or the exact size. For a web site you should not frame the browser window, but frame the whole website. You can have one extra screen with the browser window for reference for what's in the fold, if that's important, but for the most part make the full web site document.

Now start laying down boxes, labels, buttons. etc.

Make a layout for each of the possible states that the app can be in. This is the most tedious part and sometimes seems way too obvious but as soon as you have it out you'll realize something and it will also give your team mates, if you have any, a clear idea for what was inside your brain.

Example wireframe

For an example, lets lay I've decided to build a small life-tracking app. I will be able to input my weight every day, how much I eat and how many calories I burn.

There was an image here that has been removed.

I also try to annotate to say what the purpose of the flow is. Sometimes it may seem obvious but it makes it so that it's easier for people just starting to look to see what's happening, rather than scanning the whole thing. I usually also will try to say where you clicked etc. Some people like to use arrows to point between the screens, that also works, but I like to have things down to specific flows.

There was an image here that has been removed.

Now it's time to export.

Exporting for others to view

What's really important is that you have a fast and efficient workflow for getting feedback on your wireframe. Ie. fast export. That means that whatever it looks like at one point, you should be able to get it out in an email or in chat, phone, 1-to-1, meeting whatever, within a minute. It is important for it to be that fast for it to be efficient.

The problem if you don't do that chances are you're going to dwell on your wireframe, get too attached to ideas, your mind will go off and work on other things etc. You need to get your wireframe out there right now and get feedback right now.

Luckily balsamiq makes it easy to export wireframes. It has stuff like export to PDFs, PNGs, clipboard etc. For the most efficient flow you either want to couple Balsamiq with some sort of easy sharing-to-url app. That way you could either screenshot your wireframe, or export it somehow to the web. That's where cloud app comes in really handy.

It's a tool that I use all the time. If you haven't started using it, you should start right now: https://getcloudapp.com/

It has this amazing small feature set, one if which is to allow you to grab a screenshot and have it uploaded to a public url right away without doing anything. The url then gets put in your clipboard, which means you can just paste anywhere, and there's your link right there. It's mainly for mac, but there's a PC client that works just as well.

Cloud app also makes it super easy to paste whatever is in your clip-board to a public URL. So what you do can do is you copy your balsamiq to your clipboard (command+shift+c, or file-> export image to clipboard) and then press ctrl+option+c (i guess control+alt+c on PC?) to upload your image to a URL. Now you can just paste your url to get to it.

The feedback (Playing ping pong)

Now that we've exported, you may have team members that you are working with, so go to your email client and say something like "Feedback requested: Wireframe of the user flow for adding food in the app:" and paste the url, press send.

Getting efficient feedback and getting through the iterations depends a lot on who you work with, what their workflow is etc, but try to make it important that you'd like feedback asap. But sometimes the structure of the organization etc makes it so that getting the feedback can take a lot of time, so don't sweat it. Quit your job and work somewhere where they don't waste your time. (just joking, but seriously)

Iterating

Now, people will give you all kinds of feedback. Sometimes it's best to just ignore all of it, but sometimes the feedback is really good and sometimes you completely forgot to think about an important aspect of the flow. When you've received your feedback and start iterating on the wireframes, what's important is to:

Include and address all the feedback you received on the wireframes.

When you export, export the whole thing again. That way nothing is out of context and nobody has to remember what the rest of it looks like and possibly people will think things different.

"But all the iterations are so meaningless, everybody goes in circles and people keep wanting to change something" -- Well yeah, it's always better in the wireframing process than it is when you've started actually programming / designing / building the thing. The feedback will come, it's simply your job to expose that feedback as early in the process as possible.

Final step

Final step in a great wireframing process is:

Save it and give it a good, descriptive name. (Or throw it away and if you ever work on it again, just build it again - usually it ends up being easier)

Summarize the project again, as simply and clearly, with as few words as possible, and send the wireframe out to your whole team. (Chances are, you'll start getting some more feedback)

Conclusion

After I adopted this workflow of doing wireframes of every perceivable user flow, I have saved so much time punching the keyboard. I do not waste countless hours constructing the perfect code, which then gets thrown into the trash can, anymore.

Not only that, but my skills as an interaction designer have improved greatly, and I contribute a great deal of that to spending a lot of time in balsamiq and really enjoying the process.

All of this is, of course, mostly thanks to the great people I'm fortunate enough to work with. They have taught me a lot. Not only when it comes to interaction design, but also when it comes to visual design, development, and communication.

I hope this post has been helpful. If you have any suggestions, corrections, or ideas they'd be welcome. Follow me on Twitter or post a comment  down at the bottom. Thanks.