Lean Wireframing

Will Evans, who does UX design at The Ladders with agile-UX champion Jeff Gothelf, recently wrote a tweet that caught my eye:

The hi-fidelity vs. lo-fidelity wireframe debate is silly. You use the weapons you need based on the war you face. (link)

A wireframe is meant to communicate and test. You want to do the least amount of work required to fulfill those functions. Anything more is a waste of time and resources.

A simple product change might only require a whiteboard or paper sketch before implementation. A more radical or dev-intensive change might justify more concept, design and usability vetting.

When paper testing, let the type of customer dictate your level of fidelity. You can show a techie-early-adopter a fairly crude wireframe and they will get it. However, if your target is a fashionista, you need to have more polish, otherwise the lack of visuals will get in the way of an honest reaction about the core value proposition you are trying to test.

The more you require the customer to use their imagination, the less you can trust their response, but you still want to look for shortcuts to actionable conclusions. The only thing I am dogmatic about is my hatred of lorem ipsum text. I always use real copy, even if it’s not yet optimized. In general, try to learn what you need to learn with the least work and time invested. Invest more if something is getting in the way of learning.

I always like concrete examples, so for those interested, here are three recent projects of mine that had different processes based on situational needs:

Example 1: Fanfeedr

Context: FanFeedr is a sports news aggregator that wanted to re-evaluate their consumer offering. After initial customer interviews, we came up with a hypothesis around a new way to package sports information. We needed to know if anyone would give a damn. Over the course of roughly one week we went from sketch to wireframe to live, functioning prototype.

First, I needed internal buy-in for this new concept. I sketched out some alternative interfaces on paper, but because I had not worked with the team for very long, decided that the next level of fidelity, Balsamiq wireframes, would be appropriate for internal discussions.

Often, my next move would be to paper test a mockup with end users, but because FanFeedr had a great API, we knew we could create a functional prototype in just a few days. It felt worth the investment in order to get a more honest response. Andy, the dev I partnered up with, started putting code pieces together based on the chosen wireframe, leaving the CSS for me.

Next in the process, I created a photoshop mockup. This was purely for my own purposes, because I’m really fast in photoshop, and faster in CSS when I know what I’m aiming for. Someone else with different skill-speeds might skip the Photoshop process entirely.

We banged out the functioning prototype in 3 days, during which I also set up user feedback interviews. Then we ran around talking to as many people as we could, whether in person or remotely, and trying to get a read on what was working and what was failing.

I should point out that our goal was not to create a successful “product”. Our goal was to LEARN. Perfection, over-thinking, and over-designing had no place in our process. (btw, you can still see that prototype here)

Example 2: Birchbox

Context: Birchbox is a tremendously successful NYC startup that delivers monthly beauty/lifestyle product samples and for whom I did some UX/usability work this spring. With a mix of subscriptions, e-commerce and content, their product needs are surprisingly complex. My goal was to understand how their customers viewed the service and prioritize where the current website was working vs failing.

The process began with interviews across the organization to understand internal opinions and pain points. I used Balsamiq mockups to discuss new approaches to structuring the website, with occasionally live paper sketching. The wireframes focused the conversations and kept them actionable.

For external interviews, however, I believed that wireframes would not fly. Birchbox’s customer is a sophisticated, fashionable woman.

The goal was not to do a massive redesign, but to focus on structural, near-term-fixes. I needed something one notch above a wireframe. I quickly created simple, clean versions of the most important pages in Photoshop, sticking with much of the live site’s style guide to neutralize any distracting debates over design.

Then I hyperlinked the mockups together so that it felt semi-live during user interviews.

We set up interviews with Birchbox customers all over the country. Each conversation was structured so that we started focused entirely on the customer’s behavior and view of the service/brand (see my thoughts on cust dev interviews here). Then we switched gears to get feedback on the actual website and fake-live mockup site.

Addendum: none of the changes have been made yet on the live site, but their talented creative director Jess has a gorgeous re-design in the works and I cannot wait to see it live.

Example 3: Subjot

Context: Subjot is a social sharing startup founded by two close friends of mine, Becky and Chris Carella. I was having a lot of fun using their site (click here if you want to join the beta). When we shut down Aprizi in April, I volunteered a few weeks to implement a cleaner UI and some useful changes to UX (the most important was implementing a notifications bar).

Because a cleaner graphic design was a big part of the mission, I went straight from paper sketches to working in Photoshop, skipping Balsamiq entirely. The first version was entirely greyscale, because I wanted to keep things focused on structure and shape and sizing, without getting bogged down by color.

Once we had consensus on the greyscale design, my next step was to implement the CSS in a local dev environment. For things like color, texture and font-sizes, it was faster iterating in CSS.

Just to continue illustrating how process and tools varies to fit the situation, when it came time to revamping the Subjot FUE (first user experience), some parts were done in pencil, some in Balsamiq, and some in Photoshop — whichever felt fastest and best for communication (we were usually working remotely).

And for the latest change, we did a sketch over coffee (below) and are going straight to implementation.


In the end, it’s not about fidelity at all. The best mockup is one that serves its purpose with the least amount of work and time required.

Minimum viable wireframes, ftw!

7 Comments Lean Wireframing

  1. Mark Birch August 1, 2011 at 3:01 pm

    Nice write-up and valuable point; choose the right tool for the situation.

    1. giffc August 1, 2011 at 3:18 pm

      thanks Mark 🙂

  2. Derek Tumolo August 1, 2011 at 4:14 pm

    this is a great writeup, but I’d love bigger versions of the wireframes so I can see detail.

    1. giffc August 1, 2011 at 4:19 pm

      thanks Derek — actually for the first two examples FanFeedr and Birchbox, the details aren’t all that relevant because those mockups weren’t final products with final designs, but tools for learning. It’s the process that mattered more, which includes getting in front of the customer. Subjot was more of a product redesign, so more relevant — and if you want to play with the site (still beta), here’s an invite link:http://sjot.it/pq8Moc

  3. Pingback: Lean Wireframing – choosing the right tools for the right job /by @giffconstable – Saint Sal

  4. Mockup Tiger August 2, 2011 at 3:24 pm

    this is great perspective writing. Any way we could zoom the images?

  5. InVision August 3, 2011 at 12:30 am

    My primary difficulty with the way people approach wireframing is the lack of interactivity.u00a0 nnThe typical wireframe is great for expressing the composition of elements of a screen – but only tells a small part of the story.u00a0 nnThe web is about experience.u00a0 Experience is the point to point journey from intention to execution.u00a0 Your wireframe should be narrate that journey.u00a0 nnIf the wireframe isn’t interactive you’re telling the story of the “screen” – but not the “system”.u00a0 nnPutting the experience in the browser provides the context necessary for you (and your test subjects) to “suspend disbelief” that this is just a wireframe and start thinking about it like the finished product.u00a0 nnThere’s a reason users appear to be holding back their most valuable feedback until the end of a project (when it’s quite often too late).u00a0 They’re waiting (perhaps subconsciously) for the moment their internal model of what the system SHOULD be can be played out on the screen.u00a0 Give it to them early and you’ll be versions ahead before your first launch.u00a0 nnWireframes should be just pretty enough to prevent distraction, interactive enough to tell the story, and situated in a browser so it feels real enough to pay attention.nnThis is exactly why we created InVision. u00a0

Comments are closed.