“There was never an IT-system that was too fast,
but all of them are too slow.”
These were some of the words that Prof. Dr. H. G., head of the surgery department of a large clinic in Germany, wrote to us in his first e-Mail when we asked him to give us some insights for an interface design semester project about surgery management. He reinforced this idea when we spent a day with him getting to know his workflow shortly thereafter.
What he is saying seems obvious: waiting can be nerve wracking and when we have to wait for technological devices we get even more impatient. Loading bars are the worst and don’t we all dread and despise the spinning beachball in OS X? This is especially true when talking about interfaces for professional use: when lives are at stake in a surgery room there is no time for waiting for the computer to finish some task or become responsive again. And even if the pressure isn’t always that high — users sit in front of these systems for ten hours a day for years, sometimes decades. As they come to know every detail of the application, they start to expect the disruptions of their workflow. Unfortunately this makes them even more annoying: It feels like the computer isn’t stopping because it is doing some complicated calculation, but simply because it always stops for a while at this point. Many people that work with data heavy software everyday would sign what Prof. H. G. said: All they want are faster systems and less waiting.
But this statement is very broad — might there be some situation in which an interaction with a digital system feels too fast? It would be hard for me to imagine a case, but recently I had an experience that reminded me of that quote.
When you pay at the cafeteria of our university you can either pay cash or use your student identity card that is using some kind of RFID system. Of course you have to load money onto your ID first. This used to be done by sticking your card into a machine and then sticking in bank notes. But recently, after a move, the technology changed a bit: Now you can only load your card on this machine if you pay using your debit card.
One might want to discuss the benefits and drawbanks of this change, but this is not the point of this article — the process of loading your card is. It works like this: There is one slot on the right side for putting in your student ID. You put it in and pick how much money you would like to load onto your card. You are then told to put your debit card into a second slot. As soon as you do that you hear a quick click inside the machine, and a blink of an eye later you are told to pull out your card. And that’s it, your done. If you have done it before this process takes about five seconds, ten at most.
Most people that use this machine for the first time assume something went wrong. Maybe their debit card couldn’t be read properly? But everything is fine — it just doesn’t feel that way.
The beginning of this micro interaction is very smooth. The slot to put in your student ID is contoured inwards and as soon as you have inserted your card a little it is softly pulled in — it feels great! The interface for picking the amount is utilitaristic, but it works. Interestingly the slot to put in your debit card is of a different kind than the first one: It’s covered with metal and the slot is barely any thicker than the card itself. Putting it in is a fiddly affair. This, however doesn’t seem to be too strange, since it’s a standardized debit card reader: users are used to this kind of slot.
But then there are two things that confuse the users, two things that don’t fulfill their expectations. The first one is that you are never asked to enter your pin-code. This is weird for two reasons: on the one hand it’s breaking the convention on how paying with a debit card usually works and on the other hand it’s unexpected, because underneith the slot for the debit card there is a standard key panel. The cafeteria decided not to use the pin checking method because it costs some extra cents for every transaction. Now that in itself is unfamiliar but I don’t believe it’s what makes this experience so unsettling.
What’s even more confusing than not entering you pin is that it doesn’t take a second to book the money off your account. If you have ever paid at a supermarket using you debit card you know that usually the process takes a couple of seconds because, you have to wait for your card to be recognized and for the transaction to be processed. This is not the case here and that initially sounds great: Less waiting! But it turns out it feels wrong: It’s not what we expect and what it communicates puts us in front of a decision: either something went wrong, or paying with debit card is not safe at all. Apparently most people decide for the former one.
Fulfilling user expectation is not always your number one task: sometimes it’s better to exceed these expectations — and often times that is in terms of speed. But if you are dealing with a very sensitive subject, such as processing users financial data, keeping your users comfortable and letting them feel safe(r than they actually are) is vital.
When thinking about artificial shortage in digital products until now it usually had to do something with limiting resources that are available virtually unlimited in the digital age: Both of the obvious examples, Twitter and SnapChat in the end boil down to artificially limiting memory space. But as computing and network speed continue to get faster they also eventually scrape the border of (perceived) limitlessness.
Maybe we are now starting to live in a time in which it is sometimes necessary to deliberately slowing processes down to help users staying involved. At first that seems quite counterintuitive, but the speed of computers is increasing so rapidly it sometimes is hard to (emotionally) keep up.
So when working with sensitive information, think twice about using as much processing power as possible and bear in mind that sometimes keeping the user waiting a bit might be a reasonable tradeoff for them feeling comfortable and secure while using your product.