Adding delays to increase perceived value: does it work?

December 16, 2010

A story on Hacker News yesterday kicked off a discussion about purposefully adding a delay to a service to increase perceived value. It started off with a link to Dan Ariely’s recent article on locksmiths: how they can open most doors in seconds, but how they typically go through a slow, theatrical act of “solving” the lock to increase customer satisfaction and get bigger tips.

The discussion moved onto UIs, here’s a couple of tidbits (I admit these are unverified, but they are interesting nonetheless):

“Coinstar is a great example of this. The machine is able to calculate the total change deposited almost instantly. Yet, during testing the company learned that consumers did not trust the machines. Customers though it was impossible for a machine to count change accurately at such a high rate. Faced with the issues of trust and preconceived expectations of necessary effort, the company began to rework the user experience. The solution was fairly simple. The machine still counted at the same pace but displayed the results at a significantly slower rate. In fact, the sound of change working the way through the machine is just a recording that is played through a speaker. Altering the user experience to match expectations created trust and met the customers expectation of the necessary effort to complete the task.”

“I attended a “Redesigning Blogger” workshop in 2004, when Jeff Veen at Adaptive Path and Douglas Bowman (of stopdesign.com, now with Twitter) talked about their experiences redesigning Blogger. One of the things they found in user testing was that when new users clicked “Create my Blog” on the last step of the setup process, they were confused at how quickly their blog was created. “That’s it? Is something wrong?” were the types of things people said. So they added an interstitial “Creating your blog…” type page that did nothing but spin a little animated gif and wait a few seconds before sending new users to the “Yay, your blog is created! page”. Users were far more satisfied with the new experience that took longer.”

To me, adding a delay to a UI just seems plain wrong. It involves pandering to consumers’ incorrect mental models rather than helping them understand the reality of the situation. Honesty should, in principle, trump dishonesty every time. Note, for example, that Blogger.com no longer adds a delay when creating a blog – it’s instantaneous.

What do you think? Are there times when it is useful to design an intentional delay into a UI to give the impression of “doing something valuable”? Are the rules different for people acting in the real world (like locksmiths) versus web UIs – where high value actions are often instantaneous? Finally, can anyone verify or refute the coinstar and blogger.com anecdotes?

25 comments

The only time a delay is reasonable is when the UI is waiting for a response, and even then it’s better to display something (countdown etc) to show the user that something is happening. Check out a few travel sites to see slow API response to the UI in all its glory…

Artificially placing a delay into a UI seems madness to me. Users will soon accept, and actually be quite happy, that a UI process is completed quickly.

In both instances a very short delay was designed into the process to convey to the user that something positive was happening. It was designed as a form of feedback to the user. It tested well because users we reassured that everything was working as they expected (it appeared for literally seconds though).

It reminds me of an interesting offline example when my mates dad bought a Morgan. I seem to remember the waiting list was around 7 years during which time you got to choose the seats, the finish, the colours etc..

It was pure theatre i’m sure but it seems to be commonly adopted when selling premium services.

This doesn’t translate well to online though. I think in that sort of self service environment speed will always be fundamental.

It’s got me thinking whether retailers deliberately make items seem unavailable online to increased perceived value and thus slow up the purchase process. This is one instance where this could happen online however I appreciate its not the same as a loading / processing delay.

Nice thought provoking blog, thanks.

Andrew Harder

December 16, 2010

James uses an important word here – theatre. When creating emotional impressions on people, timing is very, very important. For those of us with a heavy usability background (like me) we can often get into the mindset that good UX is all about removing dissatisfiers from the interface like bugs, confusing messages, unclear affordances, and yes delays. What kind of delay could possibly be good after all?

Yet what these examples talk about are delays that create the appearance of hard work *that align with strongly-held user expectations*. And particularly where not meeting this expectation of hard work diminishes the perceived value of the service.

So, while creating a blog from a template is no doubt very quick server-side, for me as a user with no web development experience I expect it to be really hard, so in acknowledging (pandering to if you like) the system meets my mental model and therefore satisfies me.

In fact all of this nicely aligns with Giles Colbourne’s presentation on Delight – if the user has some perceived anxiety about a service (counting all those coins, making magic happen on tinterweb) then the system *has* to address this anxiety even if it is just in the users’ flawed mental model rather than the real world.

So – if your users are anxious about something, think long and hard about how you can reassure them that you’re delivering a quality service to them. And an artful delay might be a lot more appreciated than an education campaign.

In my PhD thesis (sorry, can’t resist bringing it up, I’ll be brief) I wrote about the difference between “one-shot” and “on-going” usage scenarios.

An app or wizard you use once / rarely falls into the “one-shot” category. In this case, you don’t really have time to re-educate consumers about their mental models. You can’t rely on them reading anything in detail. Even so, the adding of artificial delays seems dishonest to me.

An app you use daily (ongoing usage) is a different beast. It would be absolutely crazy to add artificial delays into Office or Photoshop. Nobody would disagree with that.

Alan Cooper did a much better job of explaining this in his essay on Application Postures – I can’t seem to find the source right now but I think it also appears in his book “About Face”.

I think that artificial delays are useful, albeit counter-intuitive to designers. As humans, we are used to having to wait for a response from our human conversation partners while their brains process our input and formulate a response. A computer has a much smaller set of inputs and outputs and is thus able to process much faster.

Think about it in human terms – imagine talking to someone who answers your questions instantly as you finish asking them!

Alexander Baxevanis

December 16, 2010

I see this as a temporary workaround, to be used when people are suspicious of a new technology/way of doing things. That’s why the Blogger delay eventually got removed.

The Coinstar example is interesting in that it talks about the time delay being helpful in creating trust. Coinstar are looking for repeat business and trust is important to them; more important than a few seconds here or there.

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.

I think Google Instant is really interesting example – you use it in support, but my impression is that there are users who find it a weird experience – I certainly do.

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.

Sometimes when taking into account the entire experience I think it is valuable to add a delay.

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?

Don’t you think that a better completion message / page could resolve this. If it is something quick, you could end the process with a more elaborate message. Something like “You’re done, and in good time too” or something (albeit rubbish copywriting) like that, or just bigger.

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.

Hi Harry.
Here’s a real world example I am still yet to relate to on a level of personal work ethics and pride:

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.

Neil Murphy

December 17, 2010

I think you are wrong. UIs are for users not designers. If you don’t like what the user is telling you and insist on simply doing your won thing, then you are probaby in the wrong business.

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?

It’s obvious from the comments here and on hacker news that this isn’t clear cut. There are subtleties here that we haven’t yet clearly articulated – defining when theatrical artificial delays are good, and when they are bad.

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.

My instant reaction was “no way – you should never add an artificial delay”, but the basic psychology of wondering why something happened “too” quickly makes a lot of sense. I’ve certainly experience that feeling myself, though that might be a learned behaviour from years of software testing :)

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.

Aen

January 4, 2011

I wouldn’t see such delays as dishonesty. Waiting for the user to catch up cognitively is an act of empathy.

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.

I’m with James here – why not just add a “Your blog is ready. Yes! It was THAT quick!” line to the completion page? By acknowledging people’s wonder and turning it into a boon, they benefit twice.
It’s different with the coinstar, because here there are matters of trust – how do I know the machine isn’t cheating? So it’s more inline with the locksmith example. There’s a difference between wondering “did it work?” to wondering “did he rip me off?”.
Though it’s funny that dishonesty is a good way of dispelling fears of dishonesty…

We conclusively tested this in a lead generation platform a few years back. A user would fill out their form with 30+ fields (!) then hit submit. We would submit that application to several different loan companies, and the results would be almost instantaneous.

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

Dave Wyland

December 28, 2012

An old saying: “If the customer wants a green suit, turn on the green light.” If you have found something that measurably improves the user experience but offends your sense of “how things should be done,” you have some thinking to do. Either figure out why the improvement works and run with it, or question whether you really want to be in the UI business, doing what the user wants, not what you want.

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.