I wanted to share with you a little story about a tiny doorbell and what impact such a tiny doorbell might have on a business.

The other day I was on my way to the dentist and remember I glanced up from my mobile from a distance and saw their company logo on the facade of the building. A minute later I turned into the doorway and from habit lifted my hand to press the doorbell, except it was gone.

Where there used to be a panel of old fashion mechanical buttons next to all the company names, there was now a huge touch display. This display showed me a company logo of the system provider with a message «Do you want to ring a doorbell? Touch to start». A little perplexed I stared at the message for a few seconds wondering if I was in the right doorway as the dental company name I was used to see was gone, as were all the other company names that used to be there.

I pressed the screen, and the screen filled with names for all the companies in the building. I searched until I found the dental company name and pressed a second time. Then I was presented with a dialog box saying «Do you want to call this company? and the choices Call/Cancel»

At this point I think my mouth dropped open. I only wanted to ring the doorbell! I pressed again for the third time now, and heard a dialing sound … ring… ring… ring… 20…25…39 seconds. Then I saw the status message change from «Dialing» to «Connected», but no sound and no buzzing the door open.

I waited for something to happen, someone to say something, but there was no sound. I tried a weary «eh.. hello??» and heard someone at the other end trying to say something. They were probably nowhere near the microphone as it sounded like they were addressing me from around the corner, but at least the door finally buzzed open.

I took the stairs up one story where I usually had to ring another doorbell, and noticed a big post-it note covering the old doorbell saying “please use the doorbell behind you”. I turned around, pressed the old fashioned doorbell at the other door and was buzzed in immediately.

Inside the clinic I prompted my dentist with a smile «So… new doorbell system, huh?» She rolled her eyes. Turned out it was worse than the part I had been exposed to. Not only did their clients not understand how to get in, but the new routine on receiving clients was giving them grief.

Instead of just opening the door with a press on a button as they had used to do, they now had to respond to an incoming call and in addition input a code on a tablet every time they wanted to open the door. Knowing that they are 4–5 dentists in that clinic and that a generic control takes 15 minutes, they could in theory need to buzz in as many as 5 dentists x 4 clients/hour x 7 office hours = 140 persons ringing the doorbell on a workday. If all these are only 1 minute late, that would add up to 2 hours and 20 minutes of lost work hours, overtime or rescheduling to get through the day.

The building manager had installed the doorbell system with no upfront information or dialog, and you don’t have to be a mathematician to understand the dentists in the clinic where quite desperate for the overhead and delays it was creating!

Because different people experience and use systems differently, it is extremely important not to rely on solely your own opinion and experience when you develop a new product or system. You always have to test how it works with real users other than yourself, before and after deployment — even when it should be the simplest of things, like a doorbell.

Jacob Nielsen was a pioneer in his field when he wrote his usability heuristics for user interface design more than 20 years ago, but they are still the de facto standard today. I thought I’d evaluate this doorbell solution to his heuristics and see how that turned out. So here it goes:

1. Visibility of system status: I did get a clear message on what the system was doing as it was trying to reach the clinic, but after it connected nothing happened and I did not understand what was going on. #Fail
2. Match between system and the real world: The designers have used a known concept (phone) from the real world, but this concept did not meet my expectations for how a doorbell behaves. It seemed like it could potentially fail to connect, and I wondered if I had pressed the wrong button. #Fail
3. User control and freedom: I was given the option to abort calling the company I had chosen, so I’ll say this heuristic is respected. #Pass
4. Consistency and standards: There is consistency between the different screens in the system itself (no use of icons and no graphics or colors, so would be hard to fail that one on such a small system), but I don’t find it consistent with other platforms like the familiar intercoms with or without camera. In particular because of the dialing and all the actions I had to take. #Fail
5. Error prevention: The only error you could really do here would be to call the wrong company and that would not lead to an error in the system. You would just have to call again, so in my opinion this heuristic does not apply.
6. Recognition rather than recall: The dialog displayed for “call or cancel” a company shows the name of the company, so you do not have to remember or wonder what you pressed. #Pass
7. Flexibility and efficiency of use: This is a simple system so it would be limited how much flexibility you could add. Still, all this clicking would be very annoying for a user having to enter every day, and being able to circumvent that would be nice. #Fail
8. Aesthetic and minimalist design: The design is pure text in frames, so it meets the minimalistic guideline for no clutter, but I do not find it aesthetic. I doubt anyone with a graphical design focus has been involved in the development. This one fails or passes depending on how you weigh the heuristics. It would pass for no clutter, but it would fail for being pleasant to look at. If this system had had only one more tiny feature I would fail it. #Pass
9. Help users recognize, diagnose, and recover from errors: I did not make any errors, so I cannot evaluate this.
10. Help and documentation: There was neither help nor documentation available. I don’t think documentation is needed here, but some help could have been useful when the call connected, nothing happened and I did not know what to do. #Fail

Performing a heuristic evaluation of such a simple system as a doorbell would usually be overkill, but my point here was to use a well known qualification method for UIs to demonstrate the importance of testing. If you don’t let other users test the system for you, you will not know how it may fail to serve its purpose.

It is often hard to convince the one with the money, but no product development experience on how important this really is. Even for simple systems! Feel free to use this to make your point. No system is too small ;)

Update: I passed the door today and saw it fixed open. They had given up entirely. I am too curious, so I stepped in to ask a few questions, and it turns out they are close to 10 dentists, so the trouble is double compared to what I thought. They told me they would need to hire a full time position to operate the door with this solution. In addition the doorbell only works between 8 am and 16 pm, so if you have the first slot in the morning, you cannot get in to be there on time.

I also took a closer look at the touch screen downstairs and it turns out there are indeed more features. I managed to get into a search screen and hide the keyboard. There are no menu buttons so I couldn’t get out again and I didn’t wait for the system to reset to the start screen. I take back everything I said about the heuristics that passed or were not applicable. This system fails all of them spectacularly.

You can find a modernized explanation of the heuristics here: https://www.interaction-design.org/literature/article/user-interface-design-guidelines-10-rules-of-thumb

This is the original source from the Nielsen Norman group: https://www.nngroup.com/articles/ten-usability-heuristics/