Lesson 1 of 10 lessons from building a user-friendly corona-app
The design process of the Dutch corona-app (CoronaMelder) was as user centered as it gets. During the project we did more than 25 tests with over 200 users. I had the honor to be part of the team. Together with my colleagues, I was responsible for collecting user insights and creating a simple, user-friendly app. One that everybody in the Netherlands can use.
Over the past months we have learned a lot and it would be a waste not to share our insights with the world. I hope other teams working on corona-apps can profit from them. I’m quite sure some of these lessons are universal and could apply to other (healthcare) apps as well.
If you’re working on corona-apps or (healthcare) apps in general, this article is for you.
I’ve summarized our most important lessons and give a few concrete tips for each insight. Enjoy the read!
Lesson #1: Help people understand when they’ll receive a notification. Avoid visual references to maps and radars.
Before people install the app, most people want to know how it works, what the added value is and what it does.
But the app is quite hard to explain. For instance, it warns you when you’ve been close to someone with COVID-19, in a privacy-friendly way. But there might be a few days between meeting an infected person and receiving a warning. This is a pretty complex technical story.
We’ve noticed that many people assume the app works as a sort of corona-radar. They expect it to start beeping when they get close to someone who carries the virus. It’s important to avoid misconceptions like these.
“I don’t know what this means — that I’ve been close to someone? It’s very unclear to me.”
- [Advice] — Avoid visual references to maps or radars. No blue dots, no top-views of people, no radar icons. Those images imply the app is scanning around for virus-carriers right now.
- [Advice] — Emphasize that ‘you will receive a notification after you’ve been exposed to a higher risk of infection’ throughout the app. For example in the onboarding.
“So that’s not at the market or grocery store, those 10 minutes. It has to be at your work or when you have visitors.”
People also want to understand in which situations they can expect a warning. Will they receive a warning when they pass someone by bike on the street? What about their neighbours, through the wall? Some people are worried they’ll receive too many notifications, mostly from people they’ve not been in close proximity with.
Whether people receive a notification depends on proximity (signal strength) and duration. We’ve noticed that it helps to add concrete examples to clarify that.
- [Advice] — Including concrete examples of the situations that might later trigger a warning improves understanding. We’ve also emphasized the word ‘later’ in those examples. This helped users visualize the types of situations the app would warn them in.
Read more
The article could have easily been called ‘148 lessons for people building corona-apps’. This is one of 10 lessons I selected and summarised. All our research findings are available on our public GitHub.
Through this process we developed a profound understanding of what works, and what doesn’t. Any questions? Want to learn from our mistakes, successes and experiences?
Get in touch! :)
The other lessons
- Lesson #1: Help people understand when they’ll receive a notification. Avoid visual references to maps and radars.
- Lesson #2: Focus on the intended effect, instead of on the technical details
- Lesson #3: Privacy and (perceived) usefulness are key
- Lesson #4: Don’t give people the option to skip an explanation before asking for permissions
- Lesson #5: Any notification sent by the app will freak people out
- Lesson #6: The more details you give about a moment of contact, the more likely people are to take warnings seriously
- Lesson #7: The devil is in the details, small differences in text will have a huge impact
- Lesson #8: It doesn’t hurt to ask to share the app
- Lesson #9: Take into account the entire ecosystem: app-users are not your only users
- Lesson #10: Test early, test often
