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.
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.
I 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?
Hey 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.
This 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.
Adkisson’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?
I always say, “Users can’t read.”
Excellent 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/
“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:
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
I 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 abuses of web apps 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.
After 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…
This post reminnded me of something that a Joel wrote some time ago.
When you design user interfaces, it’s a good idea to keep two principles in mind:
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.
Jeff, I presume you use plenty of software yourself. Would you lie if you were asked how you use it?
You 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.
“Seeing that you were one step ahead of me made me actually burst out in laughter.”
Don’t lie, now. You hardly even chuckled.
@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”.