As a gadget fan who spent lots of time in the mobile industry, I’ve been following the story of the Microsoft Kin with great interest.  The Kin was launched in mid-April—a social networking optimized phone aimed squarely and explicitly at teens and pre-teens.  More interestingly, Microsoft publicly touted the extensive user research that went into Kin’s development.  The mobile pundits weighed in, the design blogs fired up: would Microsoft be able to remake its image in the mobile space and eat into Apple’s iPhone dominance?  Everyone settled in to watch what happened.

By June, the Kin was dead.

While the causes of the Kin’s demise are complex and hotly debated, I want to zero in on the user research and design aspects here.  Microsoft is often vilified for perceived usability shortcomings, but not many other companies spend as much time and energy on user research as the Redmond crew.  According to Microsoft, developing the Kin concept included “everything from usage statistics, to target-customer profiles, to a Web-based ‘consumer collaboration’ group called Project Muse that involved some 2,000 volunteers.” So what went wrong? Surely this much user research could not have missed the mark?

I don’t believe that this signals some kind of end to user centered design, as some have claimed. But I do think that Microsoft’s design team, however well-intentioned and well-funded – may have fallen victim to two seductive but faulty user research practices: relying on statistics for generative concepts, and building exactly what their target users told them to build.

There are places for statistics in design to be sure—Google does a great job with it—but one huge weakness of statistical methods is that statistical data is not generative, that is, it does not encourage the generation of new concepts.  Rather, they lead the designer too often into incremental solutions to existing problems.

Let me illustrate by way of analogy.  My wife and I are in the midst of having our kitchen remodeled.  It’s a hellish experience (a topic for another post!) but let’s assume that my architect could instrument my home the way that Google can instrument their search page.  Maybe the architect would want to monitor every step my family took, and measure and time every button press on every appliance we have in our kitchen, or video what we do 24/7.  And so let’s imagine what my architect would see through this analysis.  She’d see we spend a lot of time around the oven, and the fridge, and the peninsula where we do prep, and the kitchen table.  She’d see a big jump in usage around mealtimes, and late at night when my son swears he’s not eating my last Twinkie.  She’d see we use the microwave way too much.  But it’s what she would not see that is more important for our design than what she would see.  Because even with video, she would not see me going to use the neighbor’s oven when we entertain, or taking a turkey or a roast into the basement to carve because we’re using the peninsula to serve.  And she wouldn’t see that whenever we have more than a few guests, they have to go somewhere else rather than where we’d like them – right with us in the kitchen—because the space where the table sits is too small.  So lots of big “requirements” for my kitchen—a double oven, a big table, more working surface, socializing space—are not revealed by the instrumented kitchen.

The big problem with the instrumented kitchen is that it doesn’t answer the question of “why.” Because the real user motivations are hidden in the statistics, the designer doesn’t know the reasons behind the behaviors.  It’s not that the statistics are useless, it’s that they’re incomplete. 

So Microsoft used reams and reams of data about what applications, services and even keypresses were used on smartphones to redesign a youthful, social networking experience.  To their credit, they didn’t stop there.  They also used Muse.

Project Muse was an attempt at tapping the wisdom of a large group of Microsoft’s target teen and twenty-something market through an online community.  A sort of design crowdsourcing, if you will.  Invited participants were engaged through forums, polls, live chats and other mechanisms through the Muse community site.  And so Microsoft designers ostensibly could get a deep understanding of young social networkers, uncover hidden needs and desires, and design an experience just for them.

Not having been privy to the designers’ thoughts in Redmond, it’s hard for me to criticize too harshly. But this approach sounds very similar to the one some of our clients take, and ultimately reject.  The appeal is seductive: if I can gather data from seven people, wouldn’t 70 be better?  And what about 700?  With online web collaboration, it’s easy to “listen” to lots of people.  Must be better data for design, right? 

The problems are twofold.  First, analyzing so much input is daunting. What to make of poll results, forums, blog posts, chats?  Bob wants X, Mary thinks Y would be cool, Colin disagrees with both.  It becomes a cacophony of voices that is hard to structure and hard to digest.  It’s like focus groups on steroids.

The other problem is the more serious.  Mostly the language of users is about features and feature requests.  And when users tell you en masse what kind of features they want, you’re not likely to get much that is structured, systemic—or groundbreaking.  What you get is a huge mass of feature ideas that must then be managed: prioritized, scoped, and tracked.

But users aren’t designers, designers are designers.  From users we can get a deep understanding of problems—if we’re in the field and actively observe, not ask.  But it is the designer’s job to respond to those challenges in a holistic, systemic and elegant way.  Great products are not just buckets of the most requested features.  The perils of asking your users what to build are well documented, and I think it applies well in this case.

I don’t have the definitive answer about why the Kin died—and I don’t work in Redmond, so it’s hard to be too critical.  But even with all the research, the Kin was an undifferentiated, obvious attempt aimed at a narrow demographic of users.  Maybe the designers knew the perils I laid out here.  But if they didn’t, I would wager that stats and Muse played at least accomplice roles in Kin’s death.