*
programming and human factors
by Jeff Atwood
*
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.
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.
In all fairness, sometimes people do, in fact, want complexity. The newly redesigned Google Korea homepage is intentionally complex. Google's Marissa Mayer noted "It was important where our classic minimalism wasn't working that we adapt."
This echoes an earlier blog post by Donald Norman describing the way South Koreans seek out complexity in luxury goods:
I recently toured a department store in South Korea. Visiting department stores and the local markets is one of my favorite pastimes whenever I visit a country new to me, the better to get to know the local culture. Foods differ, clothes differ, and in the past, appliances differed: appliances, kitchen utensils, gardening tools, and shop tools.I found the traditional "white goods" most interesting: Refrigerators and washing machines. The store obviously had the Korean companies LG and Samsung, but also GE, Braun, and Philips. The Korean products seemed more complex than the non-Korean ones, even though the specifications and prices were essentially identical. "Why?" I asked my two guides, both of whom were usability professionals. "Because Koreans like things to look complex," they responded. It is a symbol: it shows their status.
What's particularly telling in the study Surowiecki cites 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. Instead of asking consumers what features they wanted in a digital camera, the study should have presented them with a few digital camera prototypes and then observed how they were used. Consumers' success or failure interacting with the prototypes tells us more than a thousand surveys, questionnaires, or focus groups ever could. Unfortunately, creating physical prototypes of digital cameras is prohibitively expensive, so it doesn't happen.
Prototyping software, which is built out of pure thought-stuff, is a much easier proposition. Dare Obasanjo recently pointed out a great paper, Practical Guide to Controlled Experiments on the Web (pdf), which makes a strong case for frequent observational A/B usability tests:
Greg Linden at Amazon created a prototype to show personalized recommendations based on items in a shopping cart. You add an item, recommendations show up; add another item, different recommendations show up. Linden notes that while the prototype looked promising, a marketing senior vice-president was dead set against it, claiming it would distract people from checking out. Greg was forbidden to work on this any further. Nonetheless, Greg ran a controlled experiment, and the feature won by such a wide margin that not having it live was costing Amazon a noticeable chunk of change. With new urgency, shopping cart recommendations launched. Since then, multiple sites have copied cart recommendations.The culture of experimentation at Amazon, where data trumps intuition, and a system that made running experiments easy, allowed Amazon to innovate quickly and effectively.
Why ask users if they'd like recommendations in their shopping carts when you can simply deploy the feature to half your users, then observe what happens? Web sites are particularly amenable to this kind of observational testing, because it's easy to collect the user action data on the server as a series of HTTP requests. You don't even have to be physically present to "observe" users this way. However, you can perform the same kind of data analysis, with a little care, even if you're deploying a traditional desktop application. Jensen Harris describes how Microsoft collects user action data in Office 2003:
Suppose you wanted to know what [Office 2000] features people use the most. Well, you start by asking a "guru" who has worked in the product for a long time. "Everyone uses AutoText a lot," the guru says. The louder the "experts" are, the more their opinions count. Then you move on to the anecdotal evidence: "I was home over Christmas, and I saw my mom using Normal View... that's probably what most beginners use." And mix in advice from the helpful expert: "most people run multi-monitor, I heard that from the guy at Best Buy."SQM, which stands for "Service Quality Monitoring" is our internal name for what became known externally as the Customer Experience Improvement Program. It works like this: Office 2003 users have the opportunity to opt-in to the program. From these people, we collect anonymous, non-traceable data points detailing how the software is used and and on what kind of hardware. (Of course, no personally identifiable data is collected whatsoever.)
As designers, we define data points we're interested in learning about and the software is instrumented to collect that data. All of the incoming data is then aggregated together on a huge server where people like me use it to help drive decisions.
What kind of data do we collect? We know everything from the frequency of which commands are used to the number of Outlook mail folders you have. We know which keyboard shortcuts you use. We know how much time you spend in the Calendar, and we know if you customize your toolbars. In short, we collect anything we think might be interesting and useful as long as it doesn't compromise a user's privacy.
This may sound eerily like Big Brother, but the SQM merely extends the same level of reporting enjoyed in every single web application ever created to desktop applications.
The true power of this data is that you can remotely, silently, automatically "observe" what users actually do in your software. Now you can answer questions like what are the top 5 most used commands in Microsoft Word 2003? The answer may surprise you. Do you know what the top 5 most frequently used functions in your application are?
Don't get me wrong. I love users. Some of my best friends are users. But like all of us humans, they're unreliable at best. In order to move beyond usability guesswork, there's no substitute for observing customers using your product. Wouldn't it be liberating to be able to make design decisions based on the way your customers actually use your software, rather than the way they tell you they use it? Or the way you think they use it? Whether you're observing users in low-fi usability tests, or collecting user action data so you can observe users virtually, the goal is the same: don't ask -- observe.
Malcolm Gladwell authur of Blink does a great talk about this very subject at TED
http://www.ted.com/index.php/talks/view/id/20
Well worth watching, in it he also highlights that there is no perfect product but a range of variations, ties in nicly with the Long Tail concept.
Jan Bannister on June 6, 2007 3:20 AMWith regards to the korean google, which came first, the desire to have something complex, to look 'cool' or the complex products?
abhorsen666 on June 6, 2007 3:30 AMThat's useful up to a point.
But the main point from the article is that if you make a usable product with few features, and your competitor makes an unusable product with lots of features; most people will choose your competitor's product.
The best answer might be to add a huge number of features, but bury them away under obscure menus and key-combinations. So, you can sell on that basis, without harming the usability of your product too much.
R Mutt on June 6, 2007 4:38 AMWhat's interesting is that the Korean google page is exactly what they want i.e. looks complicated but is actually simple ..and not what they said they want which is complex.
I suspect (it would be nice to see the user analysis) that most users type what they want to search for and press the Google button the same as for the rest of the world?
On the Word analysis if the main commands used are Paste,Save,Copy,Undo, Bold then the "Ribbon Bar" is just to make it look more complicated ?
Jaster on June 6, 2007 5:00 AMI think a great example of the disconect between what people want, and what they *say* they want, is the Atari Lynx. When Atari launched a competitor to Nintendo's GameBoy, they did extensive Focus Group sessions. They had created a portable console that was better in pretty much every way than the GameBoy, and it cost more. So the people they questioned told them that the Lynx was too small for the price. They wanted to see what they paid for, get more for their money. So Atari made the Lynx bigger (in fact, the first version contains huge amounts of empty space). And of course, nobody bought one, because you want to take a portable console with you, and if it is too big, you can't.
That never occured to the focus group, because they did not actually use the Lynx in the environment it was supposed to be used.
http://en.wikipedia.org/wiki/Atari_Lynx
http://www.1up.com/do/feature?cId=3133762
I find that during usabilitiy tests, it's often good to let people tell you what they're doing (can be hard to figure out), but if they note that something specific should be changed in a specific way, it's most often a useless request, because the usability issue they were having was due to a larger problem with how the system was built.
LKM on June 6, 2007 5:02 AMCollecting usage statistics for existing software - or prototypes has to be useful.
It seems like a tool that can also bite you. The obvious example being "word count" - presumably used rarely, but seems to be used by a very vocal group of users (reviewers).
It makes for an interesting balance between the amount a feature is used and the perceived importance to the user.
ian jones on June 6, 2007 5:09 AMhttp://video.google.com/videoplay?docid=6127548813950043200&q=choice
Researching psychologist Barry Schwartz gives an entertaining lecture about the paradox of choice.
What's important is that 60% bought the most complex device... so that device made the most money, was the most 'successful', etc. This, to me, means we have little choice but to cram features in order to sell them. The key is presenting that complexity in a simple and easy to use way -- in this I think Google, Apple and Panasonic (thinking of cameras with that last) excel.
Pete on June 6, 2007 5:27 AMSort of a tangent here, but looking at that Korean Google page brought up memories of other web sites: Why is it that Asian web sites (at least the few I've visited) seem to be just plain ugly? Along with the "complexity," there doesn't seem to be any proper flow to the structure to pull the eye somewhere. They just seem to be horrible, busy, mish-mashes of noise. I realize I have no idea even HOW to read the text. But still, I don't even know how to look at the page graphically. Does Western layout sensibility not apply to other cultures? Does that difference extend to the display of quantitative information (i.e., Tufte)?
David A. Lessnau on June 6, 2007 6:02 AMOvercoming what I like to call "fantasy/reality impedance" (IT'S TOTALLY TRADEMARKED SO DON'T PINCH IT!!!!!) is the hardest thing that we do, whether it comes to functionality, interface or implementation.
People have an inner vision of what they want, but what they're able to verbalize is often different from what they're thinking. All of the above may share no critical intersection with what they actually need (and your users may revolt/fire you for giving them what you think they need instead of what they say they want).
I am still surprised by the friction I run into when operating several different products. It's almost as if the company did NO usability testing at all.
Example 1: I use a Sony Ericson (almost 2 years old) cell phone. When I receive a phone call and do not answer, my phone will display (next time I open it) a fullscreen message saying that I have missed X calls and ask if I want to view them. I would MUCH rather see a half-screen message saying I have missed X calls and have the other half of the screen SHOW ME which calls I have missed.
Example 2: Given the situation in Example 1, suppose that the caller also leaves a voicemail. Then, the next time I open my phone, I see a message saying that I have a voicemail and it asks if I want to listen to it. I would MUCH rather have it show me the message (even full-screen) about the calls that I missed FIRST. But, it shows Voicemail (yes/no), then Missed Calls (view/close). If I was able to see who called, then I could decide if I needed to check the voicemail now or if I could do it later.
Example 3: This model of my phone has a button on the side that sticks out of the frame a little bit. It is used for PTT (Push To Talk). But, since it sticks out of the frame, I accidentally hit it all the time! When you hit this button, it puts up a full-screen message asking if I want to activate PTT. It tells me that a charge will be added to my bill. This is very annoying. The button should not stick out at all. I should be able to disable it completely as well.
I think that there is some merit in asking users as well. Just by asking me, you will have been able to clean up 3 issues that I think are very important. But, who knows what the average user would say.
Sean on June 6, 2007 7:09 AMOnly looking at what users use in your web page tells you very little... and I would argue in some instances, absolutely nothing.
Why do they keep using that feature? Is it because they like that feature or because it's the best option they have and they really would rather have something completely different?
The more complex a particular feature is, the less likely you are to be able to deduce whether the users are using it because it is a good feature, or simply because there isn't another way to accomplish their goal.
-this blog is good
-
-but this post is one of the best ones
I couldn't agree more
I wonder if the Customer Experience Improvement Program suffers from selection bias...
http://en.wikipedia.org/wiki/Selection_bias
Regardless, its employment of observe vs ask is clearly effective.
No kidding... as I started writing this post I got a call from my brother commenting on a song I blogged. I explained to him that that's what the comments on the blog are for... he replied, "yeah I tried that and I was prompted for a log in." Wow, usability, it's everywhere.
mattflo on June 6, 2007 7:22 AMI wonder where open and close are on the command list for Word
Billkamm on June 6, 2007 7:29 AMDavid:
The westernized layout doesn't apply to most Asian layout ideas. My wife is Korean and I deal with her Dad quite often and we are always opposite on how things should be on a page.
R Mutt writes:
> But the main point from the article is that if you make a usable
> product with few features, and your competitor makes an unusable
> product with lots of features; most people will choose your
> competitor's product.
Exactly. More features leads to more sales, regardless of whether that is really what the customer wants.
> The best answer might be to add a huge number of features, but bury
> them away under obscure menus and key-combinations. So, you can
> sell on that basis, without harming the usability of your product
> too much.
But in the time you spent making your large feature set usable, your competitors were busy adding even more features, so you're losing ground by doing this.
David Mercer on June 6, 2007 7:36 AMWhat I don't see discussed about the Customer Experience Improvement Program (or any related data collection tool) is the fact that it only gives you usage information about the subset of users who actually choose to use it. So you are making assumptions/inferences about all your other users when you use that data. Do you actually have a realistic idea of what percentage of your applications users are represented in that data set? Is there some commonality between the choice to submit usage data and the style of usage of the application? Very difficult questions to answer...
Just as an example, the company I work for (a large defense contractor) does not allow employees to submit this kind of data (its considered a security risk). Its turned off by default on the installs, and its blocked by the firewalls and proxy servers. So the everyday workday usage data for a very sizable group of users is not available.
Gather what data you can, but be very careful if you assume that data is actually representative of the mythical "average" user.
Tom on June 6, 2007 7:38 AMCellular phone manufacturers could do wonders to learn from this article.
dnm on June 6, 2007 7:56 AM[ Warning: Blatant self-promotion. :) ]
In a large application we've developed at the company where I work, we included an internal "Big Brother" mechanism that records every data modification that a user makes. (It's actually nothing more than an internal audit trail table.) As a convenient side effect of that, it's easy to discern what features they're using and *when*.
We were really surprised when we discovered what features were actually being used as opposed to the ones that we *thought* were going to be used. Constant mining of that data reveals really surprising things about whether or not certain improvements to the system and new features are actually worth the investment. It also tells us which critical system features are being neglected, and we can then ask the users why they don't use them (don't work? too hard to use? too inaccessible? don't know about them? back doors elsewhere in the system that need to be closed?) and address them.
Our users are *notorious* for not alerting us to error messages when they appear in the system. (It's a Web application, written in ASP.NET, and when an unhandled exception occurs, we display a custom error page that *begs* them to report it to us, but they never do.) So, instead, we log all the unhandled exceptions to a separate database table, and combine that information with the audit trail to get meaningful data to pinpoint what happened.
So Jeff's right. When you can't ask them, observe them. Do it silently if you have to. A well-written silent observer won't lie to you, and it will tell you a heck of a lot more and often in graphic detail, than you ever thought possible. It's worth the time to code it.
Mike Hofer on June 6, 2007 8:14 AMIf you are going to put statistics collection into your application, you might as well put in exception collection and automatic logging to your bugtracker.
Just don't cripple the app by putting in logging at every step. We manage the tradeoff on web apps by putting events into an Application object as they happen, and at checkpoints we bulk write that to an event database. It is as much for auditing errors and actions as collecting usage statistics, but it works for that.
Chubber on June 6, 2007 9:21 AMThe only problem with this blog post is that it doesn't address the issue of user's competency changing over time. Novice users become advanced users and only then will use the advanced features. So even if someone is not using a feature from the start, it doesn't mean that they won't need/want that feature in the future. And people tend to buy based on what they "could eventually need" not just what they need now. We don't want to experience buyer's remorse. This is very true with software as well. How many of us buy the "Ultimate" or "Professional" version just because we don't want to find out that we don't have what we need in the future?
Some usability studies don't take this phenomenon into consideration. It is simply too hard to track user's progress over a long enough time for them to get comforatble with a product. Especially if you are going to put them "under the gun" to learn something as quickly as possible. The Microsoft way of logging information over time can track this and give key indicators about how users progress with the software.
I'm not disagreeing with the crux of the post. I'm just pointing out that usability testing is not as easy as just watching someone use your software/website for the first time. Actually observing (hopefully remotely) is really the only way to monitor how a user's experience evolves over time.
Matt on June 6, 2007 9:47 AMMatt -- most users tend to be "Perpetual Intermediates":
http://www.codinghorror.com/blog/archives/000098.html
Jeff Atwood on June 6, 2007 10:14 AM"Some of my best friends are users." Heh. :)
Matthew on June 6, 2007 10:26 AMNice article!
Regarding that example of mobile phone, I think, it is little bit a different scenario in software side. In software development, you can make a working prototype and send it to your users and get the feedback but in the case of phones you cannot do it. You have to rely on a small group of people to design the feature. I think this is the reason we see those useless or out of order screen options/messages. Most of the things get lost in translations including user's requirements!
This is happening these days where companies are just launching half-cooked products i.e. betas and let users decide if it is ok or not. Are they making observations in these never ending beta cycles? GMail is still beta, I am wondering if Google is observing something and is not able to make any sense even after such a long period of time! :-)
The big issue I have with the Customer Yada Yada Program is selection bias. Sure, presumably they get enough corporate desktops and well-meaning Aunt Tillies that it washes out in the noise, but there's a significant (though hardly majority) share of users that will automatically opt out of all such programs.
They don't like the implication that, say, VS2005 setup sucks so bad that Microsoft needs help to find out all the ways it crashes, and they don't trust the privacy policy on Office. It's not just Microsoft in most cases, but they're the most visible offender for many of these users.
CV on June 6, 2007 12:24 PMThe UI designer's job is to make sure that features fit together. You get good marks for making something functional, attractive, and useable. You get extra bonus points for making something so fun and easy to use that it sells itself.
I think many consumers are warming up to well designed products with less than bloated feature sets, while products and software in the enterprise market are still addicted to feature-itis. Google search, the Wii, iPod, and presumably the iPhone were all hits with consumers because they had the RIGHT features in easy to use packages.
In the enterprise world you have Outlook, Blackberries, and god knows how many terrible and expensive software packages. This is because the people doing the buying are usually not the ones doing the using.
Nathan Bowers on June 6, 2007 12:25 PMI can't believe that there isn't a similar sensibility Asia regarding layout (well, Japan and Korea anyway.) Magazines, pamphlets, appliance and video game interfaces all are very well designed, it's only the web pages that look like crap. And they really do look like crap. I wonder if there is a web tool gap or something that could explain this, or that web design is just not considered important or prestigious.
Erik on June 6, 2007 2:10 PMLiked the blog very much!
Carlos on June 6, 2007 5:24 PMI agree. The other interesting angle is for the developer to make it how he likes it, rather than what a user says they like. Then at least one person, the developer likes it, and at some people will probably agree with him.
This is how I believe Apple works. While they probably do thorough, objective usability testing, I suspect that in the end it's done 'Steve's way'. It's a good way, and many people like it.
Tim Hollingsworth on June 6, 2007 8:19 PMIt's like cars and people:
Guy goes into Chevy dealer. Guy looks at Vette.
Guy wants Vette.
Guy test drives Vette.
Wife comes back to dealer with Guy.
Guy shows wife Vette.
Wife not interested.
Wife wants Suburban.
Guy and Wife drive off with new Suburban.
Vette lures another guy into dealership.
People always want the sizzle as they say in sales, but when they are really hungry it's still the meat and potatoes that they go for.
Did you understand all of the above? I'm glad because I sure don't...
Really, now what does this have to do with complexity?
I'll tell you, people want, sizzle.
They want excitement, to be 'with it', ahead of the crowd, in the groove, ahead of the curve, etc. so forth and so on.
In our technological wonder age we have convinced ourselves and everyone else that to be with it means that you must be technologically savvy. That means a blatant display of technological mastery. Which leads to complexity. Not that the complexity is necessary or even really wanted. It's the perception, the sizzle...
By the way Jeff, can we please have a spell checker? I'm getting tired of having to switch to Word to check my spelling and grammar and it would be so nice if you could just put one in for use, please? Can we please have a spell checker, you know your site will really be with it if you have one and you'll probably set off a stampede so that every site will have to have a spell checker, please Jeff, a spell checker....
And maybe one of those I'm anticipating you’re typing for you thingies, you know like in Excel where it types the number for you after the first couple of letters, please
If you ever start your own software development company, or are involved in a small company that works for other small companies (Read: No 500 page Use Cases) you will quickly find that the only design spec that you ever really get is "We don't know what we want, but we will know it when we see it. I CAN tell you all of the things that we DON'T want, will that help?"
Chubber on June 7, 2007 7:50 AMI think technically that counts as spyware. I have no objection to products that gather's data strictly for the good of the product, but I would prefer full disclosure. I wonder how many people realize that MS Office collects data of any kind on their work habits.
I don't use MS Office '03 (though I did grow up on '97) because it's more $ than I care to spend on an office sweet so I can't know for sure, but I wonder if it is possible to turn this function off, or at least monitor an control what it sends back. Is their any way for the end user to know, for certain and precisely what MS is monitoring? And how about other vendors that do this? Is it possible that functions like this present a security loophole? Hell, what about the bandwidth usage?
A lot of users set up proxies and firewalls to block this exact kind of activity on their home networks. Not all of this kind of activity is malicious but there is no way for a firewall to know which is which except by explicit permissions. So unless your app is able to break these firewalls and proxies, (isn't that illegal?) they're not likely to be as affective as you might hope.
astine on June 7, 2007 8:44 AMSo, I double checked and their is full disclosure & it is fully voluntary. This is good; MS know's where it's priorities lay. I'm just wondering how many people are willing to submit to it though? With a webapp you have no choice: cookie, but here it could be a problem.
I imagine that the willingness of the user to submit this kind of info might be contingent on the kind of work he does. Which tools and features he uses most will also be contingent on this also. So, the data gathered can still be significantly flawed, allow the company to tailor their product to only a segment of their market-share and perhaps ignore the rest. I suspect the best way to gather data would be to simply use the product oneself, maybe beta-testing as well.
astine on June 7, 2007 8:58 AMHi Jeff,
Love the blog and loved this article in particular. I was writing a similar article but you scooped me. I've publiushed mine at the following link and have given you props just to be on the safe side
http://softarc.blogspot.com/2007/06/capability-vs-usability-what-your-user.html
Keep up the great work,
-Frank
Frank Kelly on June 7, 2007 10:30 AMgood one!
Rishik on June 8, 2007 1:33 AM"We know how much time you spend in the Calendar" - I hardly use the calendar, but not because it not useful, but because it isn't comfortable to use...
Nic on June 8, 2007 6:51 AMno offense meant, but I am suprised at how simplistic this article is. Of course you can't use "wish lists" to design new products. But observing users is extremely narrow at best. Users won't say what say want, that's granted, but there is so much more to it.
"what users say they will do, and what they actually do, are often two very different things" ... doh. What about what they genuinely THINK they would do (and how wrong that also is)? What about what they would BUY even fully aware of how they would underuse it (or overuse in some cases)? What about what they would WANT to do if they knew it was possible? In turn, what portion of that would correspond to a genuine use when implemented? How many sales did you loose by NOT having a useless feature? Or even a useful one for that matter! How many sales did you loose or gain by choosing to observe customers instead of listening to your engineers? How is the decision to buy related to usability (or ease of use, feature set...)?
What about the multiple other sides of design?
Do you really think that MS-DOS (a really perfect example of wholy encompassing interface to a major device - and despite that crucial position, not quite an example of usability) was designed with usability in mind, or by a vision of the whole industry and what it would become?
Don't ask. Don't listen. Don't observe.
Be smart. Reap the money.
Rinse and repeat.
"As designers, we define data points we're interested in learning about and the software is instrumented to collect that data. All of the incoming data is then aggregated together on a huge server where people like me use it to help drive decisions."
As software designers I have often thought we don't mine our own application internals and data to learn more about how our system is used. Most applications are simply information graveyards. Users input lots of great info we could use to improve the product and we simply throw it in the bit bucket.
I am a Java developer and created an open source product called JAMon that I use to track aggregate application about performance, usage, errors, and because a developer can supply any String to JAMon indicating what the concept is that he wishes to track that means JAMon can really track anything.
It is time software developers started making our own shoes...
http://www.officepolitics.co.uk/cobblers_children.html
steve souza on June 9, 2007 10:50 AM"As designers, we define data points we're interested in learning about and the software is instrumented to collect that data. All of the incoming data is then aggregated together on a huge server where people like me use it to help drive decisions."
If aggregation is done to the data on the fly and the details are not saved it allows us to track many more things in our application than we typically do as this approach is faster and consumes less space. In general to track many things in an application it is important to keep the aggregation summary stats, but throw out the details or at least the boring details. It may be worth it to save the more interesting non-standard details.
steve souza on June 10, 2007 9:10 AMhttp://blog.hanfordlemoore.com/2007/04/16/dont-do-what-your-users-say
--
During the party I got a lot of great feedback. Just watching someone play my game and see them learn from their mistakes was an incredible experience. But mainly I was watching closely to see if and why anyone was going to request an undo feature. What I saw was surprising. Almost everyone playing the game was oversteering the character. I mean really oversteering. Overshooting their targets, pushing objects too far, smashing into walls, and falling into water.
After making the changes, I did a few more user tests and the results were astounding. No one was asking for Undo anymore. It was a big difference from before. The important thing though is that I never implemented the number one feature request, which was undo. I didn’t ignore their requests, but I didn’t go ahead and implement them without understanding the root cause of their requests. When you listen to what your users are telling you instead of what they’re saying, you have the opportunity to incorporate improvements that still fit into your vision of your product.
--
Would you recommend "The Wisdom of Crowds"? :) Have you read it?
Gustav Mörtberg on June 12, 2007 6:48 AMAbsolutely besides the point, but not having "undo" is dangerous because it teaches the users to be afraid of doing anything wrong, which means they won't learn new features in your application. I know implementing correct undo stacks is hard, but this is still not something you should avoid.
LKM on June 20, 2007 12:03 AMhiiiiiiiiiiiiiiiiii
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email