Lesson 7 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 #7: The devil is in the details, small differences in text will have a huge impact
Sometimes small details make a huge difference.
There are two types of codes: the codes two devices are exchanging when they’re close to each other, and an authorization code you can share with healthcare authorities when you’ve been tested positive. When you’ve shared the authorisation code, you can then upload the codes you’ve been transmitting, which can be used to warn people who’ve been close to you.
So, if there are two types of codes what do we call the second type: the authorisation code?
“Which codes am I uploading? It’s confusing to me, because they’re both called codes.”
We tested ‘control code’ first. But people were confused between those two types of codes. So we then tested ‘temporary password.’ But we then learned that people have been taught to never share any password with anyone, so that didn’t work either. This looks obvious in hindsight but was an important realization for the team. In the end we settled on ‘GGD-sleutel’ (‘key for healthcare authorities’). Which worked just fine and solved confusion between different kinds of codes.
The menu item ‘Ik heb een melding gekregen’ (‘I received a notification’) is another example. Visually, it was made clear that this was a menu item, an entrance point for more information about what you could expect from a notification. But when we tested this with visually impaired people, we noticed that many people thought they had actually received a warning. Even though they hadn’t. The problem was that screen readers just read the text, and visual hierarchy is lacking for this target group. We subsequently changed this menu item into ‘What does a notification say?’
Another example: Google and Apple notifications call the transmitted codes ‘ID’s.’ We tested this with visually impaired people as well, and screen readers read ID’s as ‘iets’, which is Dutch for ‘something.’ So when the screen readers read text out loud, they would say the phone needs bluetooth to collect a random ‘something.’ This was very confusing. We asked Apple and Google to change ID’s into ‘codes’, but as of writing, they haven’t.
“‘Random something’? What’s that?”
“What are ‘random hits’? Why would I have to share those?”
“Why do they need to gather information from random apps?”
- [Advice] — Use consistent terminology throughout the app. When you call something ‘codes’ in one place, call it codes everywhere.
- [Advice] — Make sure not to use similar terminology (codes, numbers, ID’s, etc.) for different concepts.
- [Advice] — The only way to really figure out misunderstandings like these is to test your prototypes with users. Test early and often.
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
