The Subjectivity of User Satisfaction

A friend (call her Alice) shows up at our local pub everyday at 6pm and has a glass of Albariño. It’s like clockwork, to the point where the bartender (Bob) pours a glass out around 5:58, so that it’s ready for Alice when she shows up. The fun part here is that every now and then, Bob pours out something different — say, a Vermentino, or a Pigato, or some such — and Alice is quite OK with this. The reasoning being
  • • The “fuzziness” around a routine: Alice likes a little variety. Not too much, but every now and then, mixing up the wines gives her a little jolt of satisfaction. Doing the same thing over and over may be efficient, but it can also remove some of the color from life. Deviation from the mundane can make life just a little bit more happy.
  • • The lack of self-knowledge that we all have: Alice used to think that she only liked Sauvignon Blanc, till she accidentally had an Albariño, and now she’s hooked. Sometimes you need to be thrown a curve-ball to waken you to the possibilities out there.
  • • The subjectivity around “satisfaction”: It’s not that Alice doesn’t like other wines, she’s quite ok with them. It’s just that she knows she likes Albariño.. The occasional change-up gives her the opportunity to sample other wines, and increase her confidence in her choice.
We’re all trying to be Bob, trying to keep our users happy and satisfied, right? After all, if our users are happy, they’re going to continue using our product, recommend it to others, and so forth. In short, we get to stay in business, and that’s a Good Thing .
The tricky part here though is in how one defines “User Satisfaction”. If you think about it, most internal metrics — and terminology! — around this tend to revolve around “User Experience”!
These tips, on improving user satisfaction, for example
• Provide immediate enjoyable feedback to an action
• Keep animations brief and tasteful
• Break long sections into short satisfying chunks

and so forth. They’re good, but, ultimately, leave us just about as much in the dark as before. After all, the words “enjoyable”, “tasteful”, and “satisfying” are carrying a lot of water here — if we remove them, you end up with guidelines that while providing excellent design principles, don’t really say much about whether the user will be satisfied, y’know?
This subjectivity is actually well known, with any amount of research showing that satisfaction differs in meaning and significance from person to person. What makes Alice happy isn’t necessarily going to keep David satisfied. (And yes, file this under “D-uh”, but sometimes it helps to have research back up the obvious!). What’s worse is that this subjectivity tends to apply across definitions and measures, i.e., Alice and David above might not even agree on how they define satisfaction, let alone how they measure it!
/via https://blog.equinix.com/blog/2018/04/23/the-role-of-your-it-team-in-user-satisfaction/
Mind you, that doesn’t mean people haven’t tried to come up with concrete measures. The results, however, have been all across the board, and contradictory at that. For example, they’ve found that
• Irregular users tend to be more satisfied than regular users.
• Regular users are more satisfied than irregular ones.
• Users base their satisfaction on their past usage and experience.
• Motivation and satisfaction stem from (potential) future usage.
and so forth.
You get the point — trying to make this concrete is basically a sucker’s bet.
The bottom line here is that predicting and understanding the things that satisfy us, our wants, and our needs is a really, really big unknown — philosophers have been working at this for millennia, and agreement is, well, still pretty lacking.
And so we soldier on, using the tooling we have — design and UX skills — to work around the subjectivity that is User Satisfaction. It’s the best we have today, but hopefully we’ll have better tomorrow .

Comments

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

Visualizing Prime Numbers

Its time to call Bullshit on "Technical Debt"