Why my eye doctor is (probably) a better UX-Designer than you
One of the most frustrating things when I use a computer is the time I spend watching loading screens and progress bars. Probably nobody likes this and I discovered something else nobody likes: visiting the doctor. It is not just the fact he knows much about me, I don’t know or he might has to tell me I am not as healthy as I hoped, but it is even more frustrating to wait until I can speak to the doctor. But yesterday I experienced how it can be done so much better when I visited an ophthalmologist for a routine control.
It felt not like a process of waiting until the doctor would call me, but it was a process of coming closer to the moment the doctor would call me. I almost appreciated the waiting time as I could analyse how the journey of waiting was designed. One day later, I am sure: my eye doctor is a genius of UX-Design and probably a better UX designer than you, as I assume you use progress bars. I hated them always — and now even more as I think I know how to do it much better. But one step after the other.
3 why reasons progress bars are evil
1. Programming them is a mess
Ok, ok, maybe I underestimate all coders on the earth and I am just incompetent, because I was never good at programming them. Maybe. But how often did you experience a progress bar that doesn’t move at all for five minutes and then suddenly is completed? I experience it so often — and hate it. Jony Ive said once, if an indicator doesn’t indicate anything, drop it. Boy, was he true. A progress bar can easily be an indicator indicating nothing if it doesn’t move in a linear way. Now you can say, it is the programmers’ responsibility to do it right. And I won’t disagree on that with you, but a progress bar is pretty much work for (at least in my opinion) not so much positive outcome. And it is risky to think it will work, especially if you rely on an internet connection, which speed can differ from time to time. Summarizing: A progress bar is very likely not to move consistently and therefore fails.
2. Knowing the time you have to invest can be frustrating
If you use a progress bar in a (installation/loading) process, it is hopefully there all the time as design should be consistent — even with the bad elements, in my humble opinion. But the problem of a progress bar is the start of the time span of which it shows the progress. If it takes an hour to install something the user already is frustrated, even in the beginning how long it will take — and maybe will stop the installation. Even worse: as progress bars are not exact, it could happen that you show a time that is not precise but one hour too little. So, why should you show a time at all? Sorry, omitting the timer doesn’t seem to like a solution, you just hide the symptom. When you can look at a countdown, at least you have something that moves constantly, while a progress bar without a countdown is just boring. Summarizing: A progress bar can be a pure frustration for the user if it shows longer periods of time.
3. Nobody wants to wait — so why should you remind your user he has to do it?
The problem with the progress bar is that its name is wrong, it should rather be called “Slow-moving-how-long-to-wait bar” because it shows the user how long he/she can’t do anything — not being in control never feels good, right? And a progress bar shows this to you. After thirty seconds staring at a loading screen with a progress bar in a game, you feel annoyed by how long you weren’t able to play your game. This should be enough to explain why I assume progress bars are evil. Summarizing: Progress bars show the user not the progress, but how long he has to wait.
What my eye doctor makes better
When you visit an eye doctor in Germany for a routine control, it usually works like this: you look into a refractometer, which is operated by an assistant and then the ophthalmologist examines your eye with some tests. Before you are examined by the doctor, it is not unusual to wait about an hour and sometimes even much longer.
But what my new eye doctor did in his office is way better. Firstly, I had to fill out an anamnesis questionnaire while waiting. Then I handed it back to the assistant and went back into the waiting room. After some minutes I was guided to the room where the test with the refractometer (which took some minutes) was done and then I was sent back to the waiting room. Of course, I had to wait some more minutes until I was called and guided to another waiting room near to the doctor’s surgery. There, I needed to wait another time, until the doctor called me. In the end, I waited around 45 minutes, but I was completely comfortable with this waiting time.
But why was I comfortable with almost an hour waiting time?
- Honestly, I had my iPhone with me and read some articles. But I also did this when I visited my previous eye doctor and it felt much less convenient to wait there.
- Waiting a certain time if you visit a doctor is just normal — so I was mentally prepared as I expected it.
- The most important reason: I did not wait 45 minutes. What does this mean, you ask? I waited maximally fifteen minutes each time. My waiting time was divided in several periods and in some of them I even could do something that would help my eye doctor (at least it felt like this). Therefore I filled out my anamnesis questionnaire, did the refractometer test and I was seated to another seat to support the organisation in the medical practice.
So I never waited, but was always able to do something or at least I had several waiting periods which didn’t feel as long as they were.
What does this mean for the use of progress bars?
You shouldn’t tell the user how long he will be forced to wait. At least if you can’t predict it precisely. Numbers are something very precise. 10 is exactly ten. And not almost ten or a little bit more than ten. So, if you can’t indicate something precisely and you want to show at least some kind of time spans, why don’t you use something like this?
Suggesting what to do during the installation process is something many people will appreciate, because they want to feel like they are in control but often the program they want to control needs to tell them how to. If you don’t want to do this, give an approximate time span the process will take all together and after that show just “short”, “medium”, “long” as time spans for each single step.
I am also a great fan of engaging with the user. If he has to wait, give him something to do, like filling out some forms, you could even let him/her play a mini game on the load screen or show him the Terms of Service scrolling down so he can read it. The user should be able to do something during your installation process so he can feel like he is helping the application or at least is entertained. One of the easiest things would be to let him/her fill out a form, that you usually would show after the installation, during the installation.
But in my eyes the most important and also easiest way is to divide the whole process in several intermediate steps like my eye doctor did. It is the same as filling out a long form. If you have several inputs, it is more likely that the user will fill them out, if they are presented on several pages. If you “reward” the user with interim goals he/she “achieved”, he will more likely wait one more minute and then one more…
This comes to the best if you also allow the user to engage with your application during the installation process and if you show him how long it will take (approximately) — and what do during this time.
What does this mean for UX-Design?
The lesson is less how to design an installation process (at least how I would do it) but how think about UX-Design. Design is not something we should do only with wireframes, sketches and whatever, but it is a discipline we should be aware of during the whole day. And sometimes we can recognize a pattern like how your a doctor makes thewaiting times feel short — and how to use it for our next project.
