Tired of going with the design that will survive the organization's political gauntlet? What if we made decisions based on what actually worked for customers and produced results, not what snaggletoothed solution fit into every stakeholder's personal view of the world?
A quick story of how I got hooked
Five years ago I was working to redesign a major website when our team got stuck on just how to design landing pages for traffic coming through Google. Should we be satisfied with a Google searcher just viewing one page or should we put design effort into getting them to view more?
The developer on our team said “let's find out” and put an A/B test on the site that very night, adding a link to some pages that helped Google searchers go find more pages like that one. The next day, we had our answer. No guessing. Enough people clicked on the link to warrant design time. It wouldn't be a waste. And no one debated the results.
The way to design with integrity is to make sure it works for the people using it. The way to make sure it works, is to find whatever way you can to present the important ideas early and frequently to the intended user. This is true for digital products, but it's equally true for services and can help overcome what I've started calling the Service Anticipation Gap.
And the named real-world cases?
Yeah, that last story was purposefully obfuscated to protect the client. So how can you believe that teams can really work this way? I have four real-world examples. Here we go:
1. Nordstrom's Sunglass iPad App
This has made the rounds a couple times, but it's a stellar example. Nordstrom's Innovation Lab set up in a Nordstrom's store for their research, design, and development.
Need to observe shopping? Turn around. Need to test an idea? Ask a customer to step aside for a minute.
By co-locating real customers and the design process side-by-side, the time lag between think, make, and learn has been reduced from weeks to minutes. There's a massive acceleration in the speed of learning. So there's more learning. So there's extremely high confidence in the viability of the solution.
2. Intuit's SnapTax
Referenced in The Lean Startup, this is another example of a large organization engaging in more nimble behaviors to get to great solutions.
At last year's MX Conference Kaaren Hansen, the lead of Design Innovation at Intuit, detailed how a small team at Intuit identified a customer group, a need, and the best way to address it—tax payers with simple situations need an equally simple approach to filing their taxes on their smart phones.
Next, the team quickly prototyped their way to a simple but compelling new service that they rolled out to California and then to the whole U.S. tax market. Listen to Kaaren and you'll hear how going frequently into the field and seeing the solution in context—for example trying to take photos of an employer's W2 in in the low-light of a Starbucks—led to a significantly better solution without trying to pack every possible solution in the app.
Some would call this a minimal viable product. I'd call it a cupcake.
3. HomePlus Virtual Stores
This is one of my favorite new examples to share in presentations. Why? Because they framed their problem really well and found a solution that could fail—or at least fail forward into the solution that would work.
In short, HomePlus, a Korean grocery store, wanted to grown sales without investing in additional new stores. The solution is a virtual storefront which requires minimal new investment and could easily be prototyped, validated in the real world with customers, tweaked, and scaled.
4. San Francisco Recreation & Parks
I've blogged in detail about this powerful example of escaping political bureaucracy by trying out and validating what works in the real world. San Francisco Rec & Parks wanted to put a park in a controversial location. Many constituencies resisted.
So Rec & Parks took 72-hours to roll out a “reversible trial” park, using paint, temporary fixtures, and chairs off of Craigslist. Measurements showed that the worries of constituencies where unfounded—the park was well used, improved foot traffic at local businesses, and didn't drive up car traffic on nearby residential streets.
Since the initial rollout, the city has continued to invest steadily in the park, changing the surfacing, adding permanent fixtures, and hosting food vendors.
Is this 'lean'?
By now someone's reading this and saying, “he's just talking about 'Lean Startup' and 'Lean UX.' Yeah, you got me. Learning by shipping is one of the core ideas of the lean approach.
But I've found that when I talk to UX practitioners about LeanUX at conferences and events, the first thing I hear about is “zero documentation.” I think that concept is a red herring. Sure it'd be great to be rid of documentation, and zero documentation might be the hallmark of a good lean design process. But zero documentation isn't the goal; the goal is to figure out how quickly you can learn what works and what doesn't work so you don't waste your time designing, developing, politicking, and—yes—documenting screen #6 when the user never cared enough to get off screen #1.
My advice if you're thinking of practicing lean—don't focus on the dogma of zero documentation, focus on the results of that rapid learning about how customers really see, engage with, and adopt your ideas.