Building a dashboard for busy GP doctors
This project was created in response to Artiom Dashinsky’s Product Design Weekly Challenge. It was made over a couple of days as a brainstorming exercise and shows my thinking process, not a polished design product. Previously, I designed an app to aid busy teachers in memorising their students’ names and a tool for helping people to relocate to a new country. Today’s challenge is to design a desktop app dashboard for a general practice doctor.
First things first, what is a dashboard and how does one go about designing it? I found this article by Taras Bakusevych packed with useful advice, including a spot-on definition:
A dashboard is an at-a-glance preview of crucial information important for the user at the moment they are looking at it, and an easy way to navigate directly to various areas of the application that require the user’s attention.
A dashboard gives an overview, helps to spot patterns and trends and is an entry point for accessing various areas of the application for more details. Now, what would this include for a GP doctor?
Research
As usual, I kicked off the design process with research to better understand what tools and practices are currently in place. In the UK (where I live) most medical practices use one of IT services provided under the GP System of Choice (GPSoC) umbrella — TPP SystmOne, EMIS Web, InPS Vision and Microtest Evolution (the first two cover about 90% of the market).
These are fairly complex systems, way too complex to be simplified to a simple dashboard, but they offer some interesting insights into the kind of tasks a GP might be performing on a day-to-day basis, notably remote appointments, referrals, communication with staff, file management, access to patients’ medical records and more.
Survey:
In addition to learning about the digital systems that are currently in place, I felt it was essential to conduct at least some user research to understand how they are used and where they might be failing. Fortunately, through my network of contacts, I managed to find two GP doctors who kindly agreed to volunteer their time and expertise to answer my questions.
The main goal was to understand a GP’s day-to-day work, learn about the tasks they perform on a regular basis, what challenges they encounter and what tools they use to resolve them. I chose a survey as the most convenient form of remote user research and used Google Forms to write a three-part questionnaire:
- Describe your work process in your own words. I led with three open-ended questions to help respondents ease into the process and gather insights before their answers become too heavily swayed by the choices I made on their behalf.
- Rate and describe specific tasks. As one of the dashboard’s aims is to provide an overview and easy access to the most commonly used features, these answers were instrumental in helping me shape the content of the main dashboard panel and map possible user journeys.
- Rate proposed features. Ideally, I would have liked to finish preliminary research, then have a follow-up session with the GPs to test some early prototypes. However, I knew the respondents were doing me a favour, so I had to get as much as possible out of this opportunity. In the last section, I asked GPs to rate and give feedback on some of the proposed dashboard features. It wasn’t perfect but returned some valuable insights.
Information architecture:
Based on my research and survey results I created an information architecture diagram for the dashboard. The top level in blue represents the navigation sidebar, while the “Home” tab hosts the main dashboard. It provides an overview and one-click access the most commonly used features, such as the patients database, current staff rota, to-do list, as well as some key statistics about the practice. Each dashboard element has its own tab, which provides more information and allows further interactions.
Dashboard:
This is the moment when all the research, testing and planning come together — here is my take on GP dashboard. Thanks for reading!