A while ago I read about a rationalization experiment conducted by Tim Wilson at the University of Virginia. Two groups were asked to pick a poster to take home as a gift. One group were asked to explain why they liked the poster before taking it home, the other could just pick one and go home.
After a while, they were asked for feedback. How did they like their posters now?
The group that were asked for an explanation, hated theirs while the others were still happy with their choice. This is a little surprising (it was to me at least). Why would explaining your choice affect it so profoundly?
I think this behaviour is important to keep in mind when we talk to our clients.
A potential client may be reviewing 4 different bids, and while they are pretty similar, the client decides that he likes #2. At some point the client may have to rationalize why he picked #2. If there are very obvious and compelling reasons to go with #2, it presents no problems. But what if all 4 are very similar, and the reason the client wants #2 is really because he quite simply, just likes it better. He can’t explain his choice by just jotting “I like #2 better”, so he will rationalize.
And so, unless there are very clear, objective, advantages of #2 over #4, we are entering that dangerous territory. The Poster Test (and other variations of the same thing), show that people simply make things up. It’s not that people consciously think “oh, let me just make up a story”. They genuinely feel that they are making a rational argument.
In the realm of software development, requirement specifications quite often deal exclusively with what one might call itemizable features. E.g. “open a file”, “delete a user”, “send an email”, and very little effort is put into discussing the “feel” of the application. When bad managers sit in a management meeting the focus is on Product X does Y, we need to do Y too, and then Z to be “better”, and the assumption is that the user doesn’t care one bit about how the app feels. Almost no feedback exists that complain about how an application “feels” (it does exists, there is just not a lot of it), and it is very rare that managers take that sort of thing to heart.
At Prescienta.com, the “feel” is important. I believe that if the product feels robust and thoughtful, that the customer will happily make up a story about why some small unique feature in our product is crucial. “Feel” is about timing, animations, and non-blocking activities, it’s about consistency and meaningful boundaries. Some companies seem to understand this, and consistently move towards improving the user experience, others give up, forget, or lose the people that have the ability to create pleasing user experiences, and instead let their product degrade into a jumble of disjointed UX ideas, inconsistent graphical language and bad modal activities (hmmm.. a bit of introspection here?)
A well designed application is designed with the technical limitations in mind – a good example is dropcam, where the audio delay is so large that the UI is designed to take this into consideration. The push to talk metaphor is a perfect way to handle the latency. If the UI was designed to work like a phone (that has almost no latency), there would be a massive gap between what the UI is suggesting and what the technology can deliver.
Another example, a bit closer to home, is the way you move cameras around in privilege groups. The goal here was to design the UI to ensure that the user did not get the idea that they could add the same camera to two different groups. If the UI suggests that you can do so, you may be puzzled as to why you can’t. I decided to prevent multi-group membership to avoid contradictory privileges (e.g. in one group you are allowed to use PTZ in another it is forbidden, so which is correct?).
Prescienta's Blog 