Lately, logic and experience have forced me to challenge the credibility of a literary classic. I have come to the inescapable conclusion that—most likely—it was the crowd that created the Frankenstein monster and the scientist who was trying to destroy him.
Yesterday, I spoke of 11-year-old Cayla and her experience with EnvisionConnect, and I attributed her success to our Requirements and Design Team's usability studies. This prompted questions from folks asking why. After literally hundreds of users attended the team's twice-weekly meetings and described specifically what they wish to see in their application—Why did the team feel there was a need to conduct usability tests?
James Surowiecki, author of The Wisdom of Crowds, writes about the paradox of complexity and consumer choice in a recent New Yorker column:
"A recent study by a trio of marketing academics found that when consumers were given a choice of three models, of varying complexity, of a digital device, more than sixty per cent chose the one with the most features. Then, when the subjects were given the chance to customize their product, choosing from twenty-five features, they behaved like kids in a candy store. (Twenty features was the average.) But, when they were asked to use the digital device, so-called 'feature fatigue' set in. They became frustrated with the plethora of options they had created, and ended up happier with a simpler product."
In the programming blog, Coding Horror, Jeff Atwood brought me to think of Mary Shelley's novel...
"It's impossible to see that you're creating a Frankenstein's monster of a product—until you attempt to use it. It's what I call the all-you-can-eat buffet problem. There's so much delicious food to choose from at the buffet, and you're so very hungry. Naturally you load up your plate with wild abandon. But after sitting down at the table, you belatedly realize there's no way you could possibly eat all that food."
It is the usability testing that separates the wheat from the chaff—the most efficient meal from the buffet.
Jeff made another point that supports Surowiecki's findings...
"What's particularly telling is the disconnect between what people say they want and what they actually want. You'll find this theme echoed over and over again in usability circles: what users say they will do, and what they actually do, are often two very different things. That's why asking users what they want is nearly useless from a usability perspective; you have to observe what users actually do. That's what usability testing is."
EnvisionConnect is developed in iterations—incrementally added layers of functionality. The first iteration of each workflow delivers only the basic tools needed to accomplish specific tasks—the must-haves. This provides users with solid, working software faster, while still providing a flexible architecture that will eventually support the nice-to-haves.
Through usability testing of base iterations, we often discover that some of those bells and whistles aren't so nice-to-have after all. Early feedback can drastically alter the requirements of subsequent iterations—and this is a good thing.
Think about it: if the complete product was delivered up-front, it would be tough—if not impossible—to correct architectural flaws later. In other words, we would have allowed the crowd to create a monster they couldn't easily live with.
"A common, but boring, way to design a demo is to start by stating the problem, and then explaining how your magical software solves that problem. Another boring way to design a demo is with PowerPoint slides and lots of bullet points. An incredibly boring way to design a demo is to talk about your company and how many employees you have and how many millions in revenue you make every year. Nobody cares."
EnvisionConnect is a “smart client” application built using Microsoft C# and Microsoft Visual Studio.
I'm a programmer
Cayla is 11 years old. 
Recent Comments