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:
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)
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.
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!