Skip to main content
added 4 characters in body
Source Link
rk.
  • 17.9k
  • 1
  • 58
  • 88

There are situations in which adding a delay will help in building a 'trust factor'. While the conventional UX wisdom dictates that faster feedback is better, sometimes, it is better if you slow down the thing to a level at which the user can imagine the things happening.

Here is a Hacker news thread touching upon the same conversation: Locksmith gets less tips and more price complaints for being faster

CoinstarCoinstar 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.

While this situation is quite common in expert services and such, in UX these situations are not that common. Mostly, because we are dealing with machines and not humans, and humans seem to trust machines with calculations and such more ;)

In your case, I would do a user study to see what the perceived model of the thing is for the users. If there is no evident trust (or similar) issues, there is no strong case to introduce delays. Also, if you do need to add delay, you need not slow down the thing, you can add a processing or some similar gimmick to keep the user entertained or something.

There are situations in which adding a delay will help in building a 'trust factor'. While the conventional UX wisdom dictates that faster feedback is better, sometimes, it is better if you slow down the thing to a level at which the user can imagine the things happening.

Here is a Hacker news thread touching upon the same conversation: Locksmith gets less tips and more price complaints for being faster

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.

While this situation is quite common in expert services and such, in UX these situations are not that common. Mostly, because we are dealing with machines and not humans, and humans seem to trust machines with calculations and such more ;)

In your case, I would do a user study to see what the perceived model of the thing is for the users. If there is no evident trust (or similar) issues, there is no strong case to introduce delays. Also, if you do need to add delay, you need not slow down the thing, you can add a processing or some similar gimmick to keep the user entertained or something.

There are situations in which adding a delay will help in building a 'trust factor'. While the conventional UX wisdom dictates that faster feedback is better, sometimes, it is better if you slow down the thing to a level at which the user can imagine the things happening.

Here is a Hacker news thread touching upon the same conversation: Locksmith gets less tips and more price complaints for being faster

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.

While this situation is quite common in expert services and such, in UX these situations are not that common. Mostly, because we are dealing with machines and not humans, and humans seem to trust machines with calculations and such more ;)

In your case, I would do a user study to see what the perceived model of the thing is for the users. If there is no evident trust (or similar) issues, there is no strong case to introduce delays. Also, if you do need to add delay, you need not slow down the thing, you can add a processing or some similar gimmick to keep the user entertained or something.

Source Link
rk.
  • 17.9k
  • 1
  • 58
  • 88

There are situations in which adding a delay will help in building a 'trust factor'. While the conventional UX wisdom dictates that faster feedback is better, sometimes, it is better if you slow down the thing to a level at which the user can imagine the things happening.

Here is a Hacker news thread touching upon the same conversation: Locksmith gets less tips and more price complaints for being faster

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.

While this situation is quite common in expert services and such, in UX these situations are not that common. Mostly, because we are dealing with machines and not humans, and humans seem to trust machines with calculations and such more ;)

In your case, I would do a user study to see what the perceived model of the thing is for the users. If there is no evident trust (or similar) issues, there is no strong case to introduce delays. Also, if you do need to add delay, you need not slow down the thing, you can add a processing or some similar gimmick to keep the user entertained or something.