Every User Lies

So 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.

@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.

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 .

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.

1 Like

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.)

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.

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.

You 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

Would 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.

Before 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.

Yes 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?

Another 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

Another 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.

Hi 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).

Regarding my earlier post:

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.

This 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.

“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!

House 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.