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
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.
Seeing that you were one step ahead of me made me actually burst out in laughter.
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.
The “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.
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.
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.
Of 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.
This 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.
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.
I 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.
how '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…
“…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…”
We may hate to admit it, but programmers are like this too. I hate most books on programming languages. One good sample program and some experimentation tells me more, and gets me going faster, then some esoteric information (cough, MSDN, cough) about the class and its implementation.
There are programmers who are fascinated by all this. When I have time, I’m one of them. I rarely have time. If I ruled the documentation world, I would require that all language manuals have:
A brief explanation of what the class, assembly, function, etc. does.
The simplest possible code sample demonstrating the principle.
Looking behind the curtain is for Sunday morning. The above items are what I need to get my boss off my back in the next few minutes.
I 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.