programming and human factors
by Jeff Atwood
Heidi Adkisson notes that features sell products, but the people buying those products often don't use the very features they bought the product for in the first place.
A few years ago I did an extensive in-home study observing use of a particular computer hardware peripheral. Most people had high-end models with many features. But in my observation of use, only one "power user" went beyond using anything but the core, basic features. These people had paid a premium for features they didn't use. However, when describing their purchase experience, it was clear they aspired to using these features and sincerely intended to. But, once the product was out of the box, the paradox of the active user took over. They never invested even the smallest amount of time to go beyond the basics (even though the extra features could have saved them time).In my experience it's people's aspiration for the experience that drives purchasing decisions. Ultimately, their aspirations may be different than the reality.
It's interesting that Heidi used the hedge phrase "may be different" when her own study data showed that users' aspirations and reality were almost always different. Maybe she aspires to live in a world where aspirations and reality aren't so wildly divergent. I don't blame her. It'd be nice.
That disparity is why it's so important to observe how users actually behave versus the way they tell you they behave. People who do this professionally are called "economists". Observation is a powerful skill, and so is learning to disregard what people tell you in favor of judging them by their actions. No actions are more carefully considered than those that result in money flowing out of your pocket. That's why you owe it to yourself to read books like Freakonomics, and maybe even The Economist magazine. It's also why the Freakonomics blog should be a part of your regular reading routine if it isn't already.
People lie not because they're all evil liars (although a few inevitably will be), but because they're usually lying to themselves in some way. Some lies are useful. Small social "white" lies grease the skids of social reality. Penetrating this veil of lies and intentions is one of the central themes of the excellent television show House, M.D. :
The show plays up subtle connections between the House character and Sherlock Holmes, which is appropriate, because it's very much a detective show at heart. The character Gregory House, as played by the brilliant Hugh Laurie, is fond of stating "Everybody lies." Parsing through all the irrational human behavior, and the inevitable lies-- white or otherwise-- makes for a gripping detective story indeed when lives are at stake.
Heidi referenced the Paradox of the Active User (pdf), which has been around as a concept since 1987. I highly recommend reading the original paper, but if you don't have time, Jakob Nielsen summarizes:
Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don't care about the system as such and don't want to spend time up front on getting established, set up, or going through learning packages.The "paradox of the active user" is a paradox because users would save time in the long term by learning more about the system. But that's not how people behave in the real world, so we cannot allow engineers to build products for an idealized rational user when real humans are irrational. We must design for the way users actually behave.
There are a bunch of ways to restate the paradox of the active user. Cooper calls it perpetual intermediacy. I think the easiest way to explain it is this: every user lies. Instead of asking users if they love your software-- of course they love your software, it'd be rude to tell the people responsible just how mind-numbingly awful it really is-- do what Gregory House does. Observe whether or not they use the software, and how they use it. Rely on that behavioral data to design your software, and not the lies of your users, however well intentioned they may be.
When I saw the title of your post in my RSS tracker, I instantly thought of House. I actually clicked your post intending to mention the show in my comment. Seeing that you were one step ahead of me made me actually burst out in laughter.
Two things to add to your article:
a) The only real way to observe user behavior is in the shady realm - ideally you need data of a user that thinks hes not being watched, because if he knew he was recorded, he would act differently. Hard to get that kind of data without joining the dark side.
b) I have found that as I grew older, I actually started to enjoy "reading the manual". Now, don't get me wrong - it's unlikely you'll find me reading a hardware manual. But if I play a new game, even if it's a genre I know very well, I will still play the tutorial. Maybe it's in the presentation. Maybe educating your users should not be a painful chore but something that's actually fun.
J. Stoever on February 1, 2008 5:19 AMI think active monitoring (you physically sit there and watch your users use the software) would be more beneficial, but unfortunately passive monitoring (having the software monitor how the users use it and "phone home") is much more practical.
I know a lot of companies have been planting user-action monitoring code in their apps for (hopefully) exactly the purpose you describe, but it seems to get lukewarm reactions from users because they don't like being "watched".
In situations where active monitoring isn't possible, how can we convince users that there is a benefit to letting us passively monitor the way they use our software? I suppose it all boils down to how much they trust us, doesn't it?
Bob Somers on February 1, 2008 5:20 AMHey Now Jeff,
Interesting post, I like the idea of the importance of how users are using the software. It brings up the importance of UAT (user acceptance testing).
Coding Horror Fan,
Catto
I used to read manuals when I was a kid. But, these manuals were interesting to me. Nowdays, even the manuals for videogames are very boring.
It's more than just RTFMing, it's a problem with the process of educating the users. The politically correct and emotionally void manuals aren't going to be read, for the same reason people didn't watch documentaries so many years ago: It's freaking boring.
Plus, every good designer knows that the software is supposed to be discoverable, so in theory, you don't *need* to read the manuals.
ZaidaZadkiel on February 1, 2008 6:31 AMThis post should have been titled "Almost all developers suck".
Flip your premise: Why would users invest any time upfront to learn about -- not just be sold -- software? Almost all software developed is largely unusable or unintuitive to most users. The bar for the user experience is so low that to do expend the time necessary to learn new software well would be the irrational behavior, not what you describe.
Jeff on February 1, 2008 7:23 AMAdkisson's data shows that users BUY according to their aspirations. As a developer who makes a living selling software, should I optimize for how users USE my software, or how they BUY my software?
Rajiv on February 1, 2008 7:33 AMI always say, "Users can't read."
malachi on February 1, 2008 7:46 AMExcellent point about economics. It's too bad they teach econ so poorly in school with all the math and macro-econ that's no good to anyone. The fun and useful stuff is in studying incentives and the difference between intentions and outcomes. Understanding economics also helps you find the gaps in your beliefs that are a result of wishful thinking and not observation.
If you're interested in a great blog and podcast on econ check out http://www.cafehayek.com/
Nathan Bowers on February 1, 2008 7:48 AM@Jeff
"Almost all developers suck."?
Why? Because they design systems with features? Because users want features that they want to use, but don't? How is this in any way the developer's fault?
It funny, really. What most people actually want is *someone else to do the work*, and think that a relatively cheap machine that *helps* them do it is the same thing. It isn't.
Admittedly, there are machines that do the work for you, but generally speaking those machines are NOT cheap.
Chris Moorhouse on February 1, 2008 8:08 AMChris Moorhouse:
You hit the nail on the head with "what most people actually want is *someone else to do the work*". This is true, and is what software should be. However, what most software ends up being is enabling the process the developer(s) (and / or PM(s) and /or team of usability people) feel is the way "the work" *should* be done.
Guess what, the tough reality is our view as developers is meaningless. How we view "the work" isn't reality for the vast majority of users. Read the book Made To Stick, and learn about the Curse of Knowledge. It's at play in pretty much any software endeavour. We're too close to the product to determine how "the work" should be done --and, yes, software should go absolutely as far as possible for doing it for the user -- and this is how we end up with so much (almost universal, in terms of usability) crappy software, regardless of platform.
--Jeff
Jeff on February 1, 2008 8:47 AMI consider it a bad habit when people (developers or otherwise) generate features that aren't usable unless you've read the manual. Even those who do read the manual aren't always good at looking through it or may forget whatever they've read by the time they actually need the feature.
The simple truth is that it is possible to build systems or applications so that they're roughly user-friendly, or at least follow existing conventions within similar and well-known systems. A lot of the biggest complaints I hear about occur when companies go out of their way to avoid doing so; Microsoft's most recent office suite and the Help icon, new users and the more recent GIMP releases where the rectangle select tool doesn't actually let you move a selection immediately.
The science of building user interfaces is not a mature field, in my opinion, but it can't be worse than the mind behind that of the FileMatrix or the [url=http://www.myinternetwebpage.com/article/how_not_to_design_your_web_application/]abuses of web apps[/url] that are so very common these days.
I should state that I'm an outlier on this matter. I read the instruction manuals, assume little more than that the mouse will do what it normally does when entering an application, and tend toward the side of the negative (I played an MMO, apparently it's contagious). That said, I have to support users that don't, and when you see a single user call five people over the period of three days to set up an Outlook e-mail account but insist on it rather than webmail, you know that the universe is just cooking up better idiots and we're not doing too well at making things any more fool-proof.
gattsuru on February 1, 2008 9:35 AMAfter getting frustrated with doing my personal budget in spreadsheets for a couple of years, I finally relented and joined the gazillion other users of Quicken. One thing that I noted immediately was that there was *no manual included.* Maybe Intuit has figured out that people don't read them...
Brian on February 1, 2008 9:46 AMThis post reminnded me of something that a href="http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html"Joel wrote/a some time ago.
When you design user interfaces, it's a good idea to keep two principles in mind:
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
I think some kind of "crowd" mentality plays role here.
Somebody who I trust buys something or has good opinion of something - I might buy it. Look at ads by Jeff at the end of each post OR on hanselman's website - they are what recommended by Jeff/Scott (I suppose). People trust what Jeff/Scott has to say (mostly) they would rely on it they will be satisfied (more so)
There are tons of features put in your cellphone/microsoft office suite. But not all of them are useful to everyone. Also, it is more of agile way of using software. Use basic software for daily purpose learn a thing - when required or by exploration.
User manuals are like big design upfront way of knowing about software. Well, in a way.
Kalpesh on February 1, 2008 10:23 AMThe trick is having non-in-house good alpha/beta testers. They must be real users, they will collect data about usability and request for features and changes, that should tell you enough about your software.
As mentioned they won't tell you the software is disgusting, they will ask for what they need, or how they want it. What else do you need?
Every complex software need some documentation. The documentation have to teach the user, not how to use the software, but how to use the software to solve problems they couldn't solve in their own. Without any needed documentation the user will be able to solve only the problems they already know how to solve, not providing any improvement on their skills or productivity. Does it make any sense?
If a software doesn't need any documentation at all it doesn't necessarily mean it's a good software with a good design. People find easy to do things when they already know what to do, that we can translate into "they already learned it using an other software".
Nooo, no need for documentation means no difference between your product and whatever else is already on the market.
In the end if dummy people wants to spent more of what they need is probably to compensate their poor nature, it's a human thing.
MaxL on February 1, 2008 10:40 AMJeff, I presume you use plenty of software yourself. Would you lie if you were asked how you use it?
jh on February 1, 2008 10:48 AMhttp://www.marginalrevolution.com is also pretty great.
Braden on February 1, 2008 11:05 AMYou can never know how users use your software. It's Heisenberg principle at work. When we monitor our user activity everything runs smoothly. The moment we turn logging off - bug reports start piling in.
Goran on February 1, 2008 11:36 AM"Seeing that you were one step ahead of me made me actually burst out in laughter."
Don't lie, now. You hardly even chuckled.
Ben on February 2, 2008 1:26 AM@ThatGuyInTheBack
Could not agree more. Many developers kid themselves in believing that if THEY were the users THEY would take time to fully comprehend the power of the system before even putting their toe in the water. Simply untrue. We're all busy people with better things to do than read manuals when a properly designed device or application shouldn't require it.
We're at a point where stand-out applications and devices have shown us that extensive training is not a necessity when proper IxD/UX/whatever design is done, so we tolerate it even less.
There's a subtle difference here as well... people aren't SAYING they're using everything; it's not a post-purchase statement. They're saying they INTENDED to use everything. Let's rein in our use of the word "lie".
When I started doing support over a dozen years ago, "every user lies" was one of the first things I was taught and it holds true on almost every support call I deal with to this day. When I read the title of this blog, I immediately thought it would be about support.
Typical support issue:
Q (me): Did you check X?
A (customer): (without hesitation) Yes!
Q (me): Did you check Y?
A (customer): (without hesitation) Yes!
Q (me): Did you check Z?
A (customer): (without hesitation) Yes!
... conversation continues
minutes, hours, or sometimes much much later:
Q: (customer): Hey, it turns out that X, Y or Z is the problem, why didn't you ask me to check X, Y and Z earlier?
A (me): WTF? (I wish I would say that!)
A comment about the (apparent) trend to blame developers for adding features that are not used - in all of my jobs, the developers are not the arbiters of features - that's the job of sales and marketing, and they will insist that the product have Feature X because a competitor has Feature X, and the executives who decide which to buy will not buy ours if it does not match up on features
As for workflow questions, well, that's an issue of scheduling - the management does not want to schedule the time to find out how the users really do the task, so we developers are left with someone's best guess, and we develop the GUIs to that guess.
Pete on February 2, 2008 2:03 AM""Seeing that you were one step ahead of me made me actually burst out in laughter."
Don't lie, now. You hardly even chuckled.
Ben on February 2, 2008 01:26 AM"
Let's not turn this into a flame fest. I don't appreciate being called a liar. Please don't presume you know better what happened in the confines of my own home than I do.
J. Stoever on February 2, 2008 3:18 AMThe "paradox of the active user" is actually a small particularization of a larger paradox. I would call it the "paradox of the hasty".
An example would be a software company (usually small and medium companies do this) that doesn't want to hire junior developers because they would need to invest time in their education and preparation. But in the long run they would win good and loyal employees. NOOO... they want profit NOW. As fast as possible. And this is just a simple example that pops in my mind.
Andrei Rinea on February 2, 2008 3:37 AMI adore "House"... though much of the medical drama is down right silly, the actual content of the show is refreshing and often bluntly truthful.
Leif902 on February 2, 2008 3:38 AMRegarding my earlier post:
Q: (customer): Hey, it turns out that X, Y or Z is the problem, why didn't you ask me to check X, Y and Z earlier?
A (me): WTF? (I wish I would say that!)
I meant to say "I wish I _could_ say that!"
Dennis on February 2, 2008 3:50 AM"...and maybe even The Economist magaazine..." -- typo
Roberto Bonvallet on February 1, 2008 06:33 PM -- Anal retentive
On a different note: the idea that economists have some special means to figure out exactly what people really do is strange. Or rather, that they are the only ones. In fact, you'll find that both anthropologists and sociologists do it as well, so stating that:
That disparity is why it's so important to observe how users actually
behave versus the way they tell you they behave. People who do this
professionally are called "economists"
is somewhat off the mark. This becomes ever so more problematic given your next point:
Observation is a powerful skill, and so is learning to disregard
what people tell you in favor of judging them by their actions. No
actions are more carefully considered than those that result in
money flowing out of your pocket.
Economists have a tendency (given their academical field) to focus on money. And as you state, actions that involve money are heavily focused on. Does this mean that actions that do not involve money are less important? No, but it does mean that you shouldn't listen to economists if you want the whole picture. What you should do is listen to economists and all other sources you can find - otherwise you end up thinking that people act only for the sake of money (or the derivative belief: that everything can be understood in money-terms and that therefore, every action can be seen as a monetary transaction), which is a blatant falsehood.
That said, Freakonomics is fun and interesting, a good read. Just be sure you question the things they put forward.
Regards
Fake
All users lie and all developers are unable to understand that users are who pay their wage.
Although, that cost burden is being nicely reduced as it moves to the east, heh, heh, heh.
@J. Stoever
Ben's comment about your chuckling, in a thread about surreptitiously monitoring users, made *me* laugh out loud...
--Dave J
Dave J on February 2, 2008 5:40 AMOf course user's lie. Keeley says, (paraphrasing) they can't tell you what they don't know. You cannot ask direct questions and expect to get anything useful from the answers. Researchers need to be a little more coy. Borrow from naturalistic inquiry and ethnography. Let them show you and let them tell you but in stories, not answers.
Let go of the surveys and focus groups!
mark on February 2, 2008 5:49 AMBy the by, "The Economist magazine" always makes a point of describing itself as a newspaper. I don't know why.
Dave on February 2, 2008 7:22 AMThis is one of the primary reasons that, when in a Business Analyst role, I insist on watching people work. They really try to explain their business processes, but there is always a gap.
Saying that people "lie" is a little harsh. In my experience it is a small percentage of the population that can accurately describe things at the "computer level" -- that is, where precision in detail is many times absolutely essential.
Seeing through what user's say and what they mean is one of the underlying secrets of good analysis. That's why, when I read some of the advice out there about doing exactly what the customer or stakeholder wants, I usually try to jump in and point out that it's the software developers who are the experts on building tools, not the users. Sure its easier just to defer it to them and take what they say as gospel, but your heavily increasing the odds that the project is going to fail.
The users always know what the problem is, but guessing at the solution is not what they are good at, or they'd be in software too. Only from experience do you start to really see the patterns that work to solve specific types of problems. Until you see the right tool, it is often hard to image what it should look like. It is clearly the most creative (and often most underrated) part of software development.
Paul.
a href="http://theprogrammersparadox.blogspot.com"http://theprogrammersparadox.blogspot.com/a
This reminds me of all the digital transformation filters available in Photoshop. They exist, not because artists are interested in transforming images in those ways, but because there's math that can process digital images in that way. These are engineer's features and software programs are stuffed with them.
I read a quote the other day that really speaks to the economics of feature development: "An unused feature of a software program is like the tree that falls in the forest. Was it ever written?"
The way to evaluate the quality of software is the ratio of features to features used. On this basis most software over-delivers and under-performs. It's why we can easily believe that MS Office is dead. It will be replaced by a cheaper, simpler cloud-based program that aligns more exactly with what users do.
Cliff Gerrish on February 2, 2008 10:16 AMI agree with the recommendation of "The Economist"... it has a bias, but the bias is pretty clear and the reporting is otherwise very good and covers a lot of basis, I find. If your main interest is world news, it could replace your daily newspaper and you'd probably understand more about the world from having read it.
But "Freakonomics"? "Freakonomics" was a perfect example of why economists are no good: they want everything to be measureable and to fit into a box. And if it's not measurable, they try to make the object of their measurement conform so that it fits their box. And that's why you rarely see economists successfully predicting a recession, regardless of the fact that that is one of their most prominent responsibilities.
mattbg on February 2, 2008 10:17 AMhow 'bout that issue with photoshop cs3? i heard (or read) that they were tracking user actions.. how's that for tracking user actions? xD
as always, nice article.. kinda hit me in a sore point, too.. rofl
from how i see it, users try to learn by "tapping in the darkness". They don't want to read the manual, so they just click something and see what happens..
Allan on February 2, 2008 11:05 AMI know this point has been here before ... but please read Norman's "The design of everyday things",if you never did.
Almost every possible user behavior is studied and dissected.
Happy reading!
Oscar on February 2, 2008 11:39 AMThe Economist classifies itself as a newspaper, not a magazine.
transcriber on February 2, 2008 12:04 PMI am a systems engineer. So I know the value of honest feedback, and when I am in the role of a user, I never lie about an application. Interestingly enough, very few developers appreciate when you tell them just how badly their application sucks, and why. Mind you, it's all constructive: this and that doesn't work because of whatever; and so on. Still, they hate your guts when you criticize their baby.
Users lie, and developers are conceited.
Nils on February 2, 2008 12:59 PMSo who tests the 'end user testers'? If a feature isn't used it's a waste of code... Perhaps?
OS X boy (Tiger) here and I switch features off where I can. I'm 40 and a bit of a stick in the mud. I like automation, but don't mind doing things myself... for the amount of times I have to do it, I don't mind doing it.
For example, I could automate my backups in any number of ways but I run them manually.
No data lost yet. I could in theory revert my T-Book to Jaguar if I had a need to. Thankfully I haven't such a need.
Nerg on February 3, 2008 1:17 AM@Andrei:
To expand upon your example: any given company wants a worker that a) has 30 years of experience, b) is only 30 years old, c) already has kids and a family and so won't need time off for weddings and child-births, d) is single, so there won't be any time off for child-sickness or births, e) is a workhorse who will do exactly was he/she is told and f) is hugely creative and will come up with loads of ideas on his/her own. Companies do not see these as ridiculous requirements - rather they see the fact that noone lives up to these requirements as shortcomings on the part of workers.
@Allan:
Users are not "tapping in the darkness". They are relying on all the prior experience they have with using software. On the windows platform, almost all programs will have a File menu with options like Open, Save, Close and so on - if the program can open, save and close (and if you don't know that, then you didn't buy the program).
Regards
Fake
Jeff, you ought to lose your fascination with economists. They don't actually do much observation at all. That's what scientists do (and in fact most programmers have more training at this than do economists.)
Economists take bulk data and try to find patterns, usually to support their pre-existing political views. Thus many important questions in economics are actually not settled one way or the other.
"Users never read manuals."
Actually, many women do. Men don't. Draw you conclusions.
CH fan on February 3, 2008 5:07 AM
We can never know how users use your soft. When we monitor user activity everything runs smoothly. It's Heisenberg principle at work. This is why user tests are about observing user behavior and not about listening to what users say because, not only do they lie, but they are often bad at explaining - what they think which leads to confusions and misinterpretations.
People find easy to do things when they already know what to do, that we can translate into "they already learned it using an other soft". If a software doesn't need any documentation at all it doesn't necessarily mean it's a good software with a
good design http://www.personallfiles.com/
No need for documentation means no difference between your product and whatever else is already on the imarket.
I have found one easy way of getting ahead of others in your group (whether this be an I/T group or not)... read the manual/help. And for even more advantage... the release notes.
Since almost no-one else does... it gives you an almost unfair advantage...
The first and foremost issue in understanding requirements and work processes is a shared vocabulary -- making sure that term -x- means the same to the user, their manager, the i/t manager, and the developer. Of course if the information passes up one side of an organization and down the other, it is more likely that there will many gaps in the shared vocabulary. This most often happens when user input is gathered, and then summarized... and then when implementation happens, developers need to guess what the original detail was.
It's not that the user lie's -- its that understanding is not possible without shared vocabulary... and very often we don't know that we are not connecting.
What has always blown my mind is the endless adding of "features" without ever improving upon the original system.
Microsoft Word has a million features. But it's footnoting system is hopelessly poorly developed—they clearly never consulted with people who spend their time making footnotes. When they were making Clippy, they could have been improving the footnote system, making it really viable, and removing RIDICULOUS defaults like "all endnotes use roman numerals." When's the last time you saw a note referencing note xxxvii? It doesn't happen, at least not in most professions.
Is there really any excuse for not being able to copy-and-paste into the chart source fields in Excel? Must we always select things with the mouse or type out complicated fields by hand? I mean, this is a basic function.
It's not just Microsoft, of course. OO.org is even worse than Excel when it comes to its Chart options. Instead of being able to actually render circles on a line graph (you can render squares and diamonds), you can use little low-res bitmaps of colored circles. Is this meant to be a joke?
TextWrangler, one of my all-time favorite programs, has a lot of little features. That's not why I use it. I use it because it is reliable, easy, and straightforward. That's worth a lot more than features. They could remove all the features and I'd get by.
Little features come in handy once in a blue moon. Developing the core set, making it powerful, flexible, and easy to use, should ALWAYS be the top priority, even if it is hard, boring, and doesn't look as good on the front of a box. (Who buys software in a box anymore, anyway? I can't remember the last software I purchased in a box.)
Shmork on February 3, 2008 8:18 AMThis reminds me of all the digital transformation filters available in Photoshop. They exist, not because artists are interested in transforming images in those ways, but because there's math that can process digital images in that way. These are engineer's features and software programs are stuffed with them.
Perfect example. And this is of course the first sort of thing that most open-source image editors try to emulate, because they think "Photoshop" is synonymous with the filters menu. Never mind if the other tools don't work well, or if the entire GUI is confusing -- we've got filters! This is why, in my view, programmers and engineers should not be exclusively in charge of BIG projects that require their work to be used by someone else. Would you want a photographer to be in charge of designing your IDE? Then why do you think you would know how theirs should be designed! etc.
Shmork on February 3, 2008 8:22 AMDr. House, is the TV show inspired you to write this post?
jackhatedance on February 3, 2008 10:14 AMYou think this problem is restricted to software???
My wife baught a car with BlueTooth, Navigation, In-Dash 6 CD player, XM Radio... all sorts of gizmos
She's on 6 months with the car and doesn't know how to use any of them
CptBongue on February 4, 2008 1:39 AMWould you lie if you were asked how you use it?
Why ask me at all when you can look at the data capturing my behavior? If you want to understand someone, just watch how they spend their time. It speaks volumes more than any conversation with them.
read the manual/help. And for even more advantage... the release notes. Since almost no-one else does... it gives you an almost unfair advantage.
Good point, but if you're on the development team, you're invested in a way users will never be.
otherwise you end up thinking that people act only for the sake of money (or the derivative belief: that everything can be understood in money-terms and that therefore, every action can be seen as a monetary transaction), which is a blatant falsehood.
Is it? I'm not so sure. If you can be convinced that time is money-- or at the very least that we will all be dead an infinite amount of time compared to the brief moment we're alive-- then it seems reasonable enough to me to judge every action as a sort of monetary transaction.
Jeff Atwood on February 4, 2008 1:58 AMBefore blaming the users - let us observe their behaviour and based on the assumption they are rationale beings draw conclusions:
Observation: User manuals are not read, often not even attempted.
Conclusion: User manuals today are not worth the time. People who try to read them give up. Experienced users who have tried to read many have given up completely on the class of user manuals.
Observation: In anchient times user manuals were read - often cherished possessions.
Conclusion: As the behaviour of the users has changes over time we have now either a different set of new users or the user manuals have changed.
Observation: Even anchient expert users have changed their behavior - and they know that they don't know.
Conclusion: User manuals today are not fit for the job.
Possible explanation: Original there was an introduction and a manual to look things up. The introduction was sequential and the manual was geared towards random access. The rapid growth in software industry lead to manuals geared towards new users and those tended to be sequential. These new manuals were in general not very efficient in their job - people prefered getting their hands dirty - and over time learned to ignore them. The old manual style was negleted and later surplanted by Google. In organisations where software development and manual writing has not been separated the old style manuals tend to live within the online help text.
Gunther on February 4, 2008 3:28 AMYes users do not read manuals (even the ones who do read them only as a last resort..)
Yes users ask for features they will never use
Yes users buy software for features that they never use
But this is because they are sold software as New! Updated! with more features! and so this is the only criteria they have for buying software of judging it against similar software ...
"Freakanomics is interesting, but their chapter on abortion being the main driver in lowering the crime rate doesn't fit the UK at any rate - I have little direct experience of the USA" - I suspect it does not follow the experience of any other country. Ireland has a very low crime rate, and no legal abortions, the UK has legal abortion and a much higher crime rate ... but I suspect it does not match experience in the USA either? They assumed that crime rate was proportional to abortion rate then went on to show their assumption was correct?
Jaster on February 4, 2008 4:15 AMAnother fallacy, we in software cling to is that needs and people don't change, that the software we build today is all they ever need just as it is.
People learn, believe it or not. Some actually aspire to be good at the use of software and call support or actually read the manuals or ask some one. As a result, the same person changes how they use software over time.
Spreadsheets are a good example - not glamourous but a good example of use change as users learn about the product.
First, you use it as you about a regular accounting sheet - columns of figures and you learn to add them.
Then you learn more complex functions and maybe macros - how can you sum across a series of sheets.
Then wondering creeps in (and the mother of all invention, sloth). I wonder if I can get this to happen with as little effort as possible and you discover Visual Basic for Apps and you can get a lot of stuff to happen automatically.
Oh, and I don't want to type all this stuff in from the report that comes from the field office - can I get someone else to do it or can I scan it in and will it read the figures and how do I get the figures in the right place? OCR, hmmm...what is that?
If something is badly designed but it's the only tool their boss gives them - they will find a way (ranging from doing it by hand cobbling the information from bits they know and using tools they do know and will lie about how they did it.
For example, I've seen folks who know SQL who've had to use a bug tracking system with built in workflow, go around the interface and go directly into SQL to manipulate their bugs because they didn't like the interface. Unfortunately, they often break the workflow and THEN THEY LIE TO ME ABOUT SCREWING UP the bug tracking system.
The other impediment is economic. QA, Support and Documentation are overhead so in our new "money for nothing" economy, don't test, answer questions (support) or give examples of how to use the software. I get to a certain level and then don't know where to go and want to talk to someone who might have already learned this but so many companies now use the strategy to discourage costs of not having enough support people so you're on hold for 30-35 minutes.
I've watched the same person over an hour and a half in a usability lab learn the software and how to outwit security, bugs and design flaws to complete tasks that will fufil their objectives (that of winning tickets to the Red Sox). People evolve and learn and they aren't going to tell you when they screw up so yeah, people lie dependent on risk.
Linda
Linda on February 4, 2008 7:44 AMAnother thing is, people Ithink/i they want a feature, but when they try to use it, they decide they don't (and not simply because it's an implementation or design problem).
Restaurant owners Ithink/i they want inventory control. Then they realize what a pain it is to actually do inventory, and realize that what they Ireally wanted/i was to be told when they needed to re-order, and as long as they don't run out, everything's good.
Sigivald on February 4, 2008 12:45 PMHi everyone:
A lot of features doesn't need that the users must use all of this but allow a lot of possibilites.
***warning :a car analogy ahead***
You can buy a car that runs 0.5 warp but still unable to use on any road (with the exception of Germany but it's another story) where the common speed limits is a few two-digit miles/h (or km/h). Even yet, there are a possibilities that you will need to push the gas to the limit (for example if you are running of the cops after hitting a Bank).
Jorge on February 7, 2008 6:31 AMRegarding my earlier post:
Q: (customer): Hey, it turns out that X, Y or Z is the problem, why didn't you ask me to check X, Y and Z earlier?
A (me): WTF? (I wish I would say that!)
I meant to say "I wish I _could_ say that!"
The first time I read this I read the word as could. I had to go back and reread it. My mind filled in the right word that was supposed to be there.
blandspace on April 4, 2008 3:16 AMThis is why user tests are about observing user behavior and not about listening to what users say because, not only do they lie to themselves, but they are often very bad at explaining what they think which leads to confusions and misinterpretations.
Don Park on February 6, 2010 10:20 PM"almost always"? We are in the worse is better arena again!
Either the data showed all users' aspirations and reality were different or at least one user's aspirations and reality were the same. If the latter then Heidi Adkisson was justified in writing 'may be'.
"Observe whether or not they use the software, and how they use it. Rely on that data to design your software" Eh?
So you write some software, give it to some users, observe if they use it and if they do observe how they use it; then design it? And what if they don't use it? It is not worthwhile asking the users why they don't use it because they lie.
Some logic!
Simon Parmenter on February 6, 2010 10:20 PMHouse wouldn't demean himself to actually observe you, he'd get the Australian guy that used to be Billy the woodworker in Neighbours to break into your house and read your usage logs while you were at work.
@CH Fan I keep telling my female relatives to read the manual, but they just say 'pfft, manual? what manual.'
Most apps still present users with a blank page when they start up. They need to ask what the user actually wants to do.
Picasa, for one, thinks it is easy to use. And indeed it is compared to many other similar applications (especially the nonsense that camera manufacturers put on their driver disks), but it still isn't task-oriented enough, and some buttons are at the top and some are at the bottom. And the stupid, stupid scroll widget in the thumbnails pane really really really annoys me! I'm glad I have a Mac, iPhoto is nicer. Though I don't know why you can't choose to burn either gift CDs or backup CDs. 06 only lets me burn backup CDs.
John Ferguson on February 6, 2010 10:20 PMForgot to say: Freakanomics is interesting, but their chapter on abortion being the main driver in lowering the crime rate doesn't fit the UK at any rate - I have little direct experience of the USA. The chapter was interesting mostly because they wrote that the woman at the centre of Roe vs Wade later became an anti-abortion campaigner. That also reminds me of the episode of House where a pregnant woman was about to die and House wanted to abort, but when they opened the womb to do a biopsy on the baby's lung, the little fella grabbed House's hand. It was such a good scene I never even thought of the special effects needed until I was half way through typing this comment.
John Ferguson on February 6, 2010 10:20 PMMost of the software I develop is bespoke, so is heavily based around the client's specific requirements. Only most clients don't really know what they want when it comes to actual features. The big mistake is to offer clients a wide array of choices because they invariably always select what they perceive to be the most flexible, open solution - even if it is more difficult to develop and costs them more. And invariably they won't use it.
If you say to someone, "Do you want feature X, which we think will do what you require, or do you want feature Y which will not only do what you want but also integrate with Facebook, generate PDFs and export data in ten different formats" then they will nearly always choose 'Y' because it sounds better and they are scared of making the wrong choice. People naturally hedge their bets and think, "Well, I better have that... just in case".
The key I find is not to offer them choices but propose a solution and see whether it suits them. If it does, great, but if not then you are step further in finding out what they actually require.
Dan Booth on June 2, 2010 12:01 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |