Building a gamified learning tool for healthcare professionals

Building a gamified learning tool for healthcare professionals
Do general practitioners in the Netherlands know enough about diabetes to treat the growing number of patients? If you have read our blog before, that question might surprise you. But not all of our work is concerned with robust software for a healthy internet; we also value work that contributes to a healthy society. In this blog, we'll discuss the design process behind a gamified learning tool for healthcare professionals.

This article was co-authored by Erwin from Grafische Republiek.

So, do GPs in the Netherlands know enough about diabetes?

In the Netherlands, GPs rely on specialists to help deal with subjects like palliative care, mental health and diabetes. While this has worked well, it also means educational facilities spend less time on these subjects, and practicing physicians tend to have less experience dealing with these cases directly.

To treat this growing problem, Tweede golf and Grafische Republiek were approached by Schola Medica - a company that provides accredited training for physicians - and by faculty members of the Radboud university medical center, to develop an educational game to help train physicians, based on clinical cases.

Can we really make learning about medical cases fun?

From the start there were two pitfalls we wanted to avoid; the game should be educational, but not feel like an exam. Neither should the game be a one-off; the game should ideally be fun enough to stimulate users to keep playing.

How to ensure both learning and fun?

Our approach is to split the game session into two parts: the quiz and the feedback. Even though the user is presented with medical cases, the quiz feels like a trivia game. To add realism (and more pressure), the user is interrupted periodically with emergency calls with medical questions unrelated to the current case.

When the quiz is finished, there is no more time limit. The user can relax and calmly look at the scores and walk through all of the answered cases, with feedback and the ability to look at background information about the cases. The first part really feels like a game while the second part provides the education.

To keep users playing, we have different strategies for different types of players. Some users are more competitive, while others are completionists. To appeal to the first group, we added an anonymous leaderboard (based on the users region and profession). To appeal to the second group, we split the game into multiple rounds. Completing a round with a sufficient score, yields an achievement for that round. This encourages players to keep playing until they have completed all rounds.

"Achievements and scoreboard" Image: achievements and scoreboard

How did we design the game?

As fans of pub quizzes and gaming, this project was a perfect fit for us. Previously, some of our team members had worked on B\Slash - an educational game to stimulate literacy for students - and Mindsort - a gamified research tool designed for learning languages.

The design process began with exploring different styles and analyzing how other trivia games are structured. We quickly noticed that successful trivia games often use bright colors and playful elements. This inspired us to take Neo-Brutalism as a starting point—a web design trend characterized by simple yet bold illustrations and vibrant colors.

Since this game was specifically developed for the medical sector, we refined the style by combining some elements from Neo-Brutalism with clear, functional typography, to ensure that the questions and content remained the focal point. At the same time, we deliberately opted for a neutral design without direct references to diabetes, allowing the game to be easily adapted for other medical or educational purposes.

What is the balance between a game and application?

Designing a game requires a different approach than developing a traditional web application. While user-friendliness is the top priority in a web application, a game must strike a balance between usability and fun gameplay. In this project, we emphasized usability slightly more while ensuring that the game element remained engaging.

To enhance the fun aspect, we introduced interactive elements such as achievements and a privacy-friendly leaderboard that tracks players' progress. These additions help maintain player motivation and encourage them to return and improve their scores.

Did we succeed?

As the Apple design guidelines stated as early as 1982: “You should begin testing as early as possible, using drafted friends, relatives, and new employees, to uncover the really big holes in your design.” 1

"Launch of the game" Image: a picture of the launch of the game

We took this seriously, and organised multiple user tests at various stages of development. Our game was launched in April at a Dutch expo for GPs, to great success and with a packed workshop. As a result, we are fairly confident that most users find the game to be both fun and educational. But don't just take our word for it; you can try it for yourself here. (Note: only in Dutch.)

We would like to thank Schola Medica and Radboudumc for the opportunity to work on this tremendously enjoyable project. We are currently preparing work on a spiritual sequel for Schola Medica, an educational game about emergency care.

(our services)

Using Rust in a web application?

Get help from the experts!

  • reduce first-project risk
  • interop with existing code
  • train your team on the job

> Contact us

Stay up-to-date

Stay up-to-date with our work and blog posts?

Related articles

July 31, 2020

Rust wide web (2/5)

Ruben has experience with a lot (and I mean a lot) of programming languages. When I asked which ones, he could name 21 off the top of his head. He loves experimenting with them, seeing what each can and can’t do. What makes a language unique? What can one language do better than the other? Why was Ruben the one to first evangelize Rust within Tweede golf? Let’s ask him!

Fuzz testing is incredibly useful: it has caught many a bug during the development of NTP packet parsing and gzip/bzip2 (de)compression.

But I've always been unsatisfied with the fuzzer being a black box. When it runs for hours and reports no issues, what do we actually learn from that? In ntpd-rs we've previously had a bug fly under the radar because the fuzzer just did not reach a large chunk of code. So, does my fuzzer actually exercise the code paths that I think it should?

This article was authored by Jordy Aaldering and Folkert de Vries

Over the past couple of months, we teamed up with Bernard van Gastel and Jordy Aaldering at Radboud University's Software Energy Lab to measure nea's energy efficiency.