Another old saying: “Don’t understand me so fast.” When someone responds too quickly to a question about a complex situation, we suspect that the answerer has not grasped the whole situation or is making major assumptions. If the answer occurs after a pause, we expect/hope that the answerer has really considered the situation in its full complexity, especially if the response is careful, guarded and acknowledges some of the major issues.

This also happens with machines. We expect machines to take some time to do a complex task. If it responds too quickly, we are suspicious. For example, if we are downloading a document that is moderate to large in size, we expect a pause (and usually a thermometer) while the download happens. If the system quickly responds with download complete, we are (rightfully) suspicious, and we check to see if the download really did complete properly. There are a lot of examples of this type.

it seems extreme to call adding a delay to the UI for customer satisfaction “dishonest.” The “dishonesty” of adding the delay – if any – is the fact that we are not doing anything during this interval. We (not necessarily the user) would feel better about this if we could think up something useful to do during this delay that relates to the UI activity.

What we found, however, was a significant increase in our acceptance rate when adding a hotels.com style interstitial page. If the process was too short, the users would start clicking around, clicking back, etc., messing up our transaction.

That info about coinstar gives me a chuckle when I think about it :)

Between waiting and instant is a grey area and grey areas are more difficult to understand. Darkening/lightening the grey area, albeit artificially, creates clarity. Perceived experience is always more important than measured performance.

It’s like the way consumer brands price their products to give an impression of increased quality, because people inherently mistrust “too cheap” products.

The two examples given in the article seem to have been thoroughly A/B tested, which in my opinion is the only basis for adding a “reassuring” delay.

Neil, nobody is disputing that UIs are for users, not designers. What we’re discussing here is whether you should allow them to keep fallacious mental models, or whether you should educate them to have accurate mental models.

Both options consider user needs – one involves teaching them the truth, (more effort for you and them, but better in the long run) the other doesn’t bother.

If I was Coinstar, I’d take pride in the speed of my machines. I’d make it into a selling point, before one of my competitors does.

In pragmatic terms clearly the delay is helping people use the product so that is good. why make a product that the user doesn’t like and can’t relate to?

A guy I know works in a major bank in London. He creates excel macros to help financial analysts model complex problems.

He told me on the average day he has 3-4 tasks and could do all this work in 30 mins, some of these tasks he could do in less than a minute.

But he always says “give me a few hours”. When delivers the goods in an hour or so, they think he’s a genius.

Every now and again he’ll ‘make’ it take all afternoon so they don’t get used to his efficiency.

This is all very calculated, with a rationale was that he was maintaining the value of his work from his colleagues perspective, but in essence, he’s giving his ‘users’ the “creating your excel macro’ experience. Seems to work for him.

The not wasting time has been covered as you are going as quick as possible, and now the user will feel like something big has been done as there is a bit of a fuss made about it being done.

Thoughts?

In the Coinstar example consumers are coming in with the idea that for them to count a bucket of change by hand is going to take hours but now with this coin counting machine hours turns into minutes. For them this is a win. If a consumer isn’t willing to believe the machine can do it instantly and they doubt the results then this lack of trust is going to create friction which hurts the experience and the business.

The sound effects and delay make it easier for the consumer to understand what is happening, or more appropriately what they believe is happening. They can visualize coins being being counted. If this makes the experience easier to understand for the consumer what’s wrong with that?

One of the problems I’ve seen in testing instant results is that users can be confused as to whether the system was ‘really listening’. You can be very engaged in providing input (say typing a search term) that when you look up for a response, there’s no feedback that the system has heard and understood. Did it maybe search mid-way through typing and these are old results?

I think the analogy of someone interrupting a question with an answer is a really good one, and agree with the point that timing can aid understanding.

In the blogger example, she may enjoy a few seconds to savour and anticipate how she’s going to use her new blog.

As Scott McCloud puts it in ‘Understanding Comics’ the best stuff often happens in the gutter, the space between the panels.

You might change the wording of a button, the colour of an element, the size of a piece of text to improve understanding. Why treat speed of display as a sacred cow?

I can’t really defend the decision to introduce a time delay in the Blogger.com example, however. Blog creation is a one-shot process, and uncertainties could probably addressed with some signposting, or the speed become a feature of Blogger. WordPress makes great fanfare about the speed and simplicity of their installation process.

Harry, I do take issue with your statement about “pandering to consumers’ incorrect mental models”. Why are users’ mental models incorrect in the first place? And if re-education is possible, or appropriate, it needn’t start with a slap. Psychology helps us to understand why people form mental models, and sometimes – only sometimes! – such “pandering” is more appropriate than re-education.

This also reminds me of the idea of Placebo Buttons:
http://en.wikipedia.org/wiki/Placebo_button