Patient Dashboard
Project Description
The “Patient Dashboard” was a solution I proposed early in a project to redesign our entire fitting software platform – Aventa. One of the primary problems our user research had identified was the overall information architecture of the platform and how the architecture did not support the user’s flow. Specifically, the platform had grown over many years with scant attention placed on navigational structures and the overall architecture. Too many items or functions were displaced from one another resulting in a fragmented system for the user.
My early efforts to address this were supported through user research – semi-structured interviews, observations and card sorting. It was a primary objective for me in the early phases of this project to begin grouping functions. One of the solutions was to build a single location in the system for patient-related content. That is, I wanted the system to support a component of patient information much in the same way an electronic health record does. This would be a single place for the audiologist to access all-things patient related such as basic demographic information, hearing instruments prescribed, audiograms, patient history, usage statistics etc. Thus, began the idea of a “dashboard” for the patient.
Project Details
Client GN ReSound
Date December 2015
Skills Interface Design, Interaction Design, Visual Design
The Approach
My initial approach to this was to group all patient-related information into a single page design – much like a dossier a doctor or nurse might use. In so doing, I went through the existing system piece by piece to ensure we included all patient related content.
I wanted this section of the system to have a high visual value so a clinician could quickly scan the page and gather needed information on a patient. The problem with a single page design was that we wanted each section to have some functionality to it. Limited functionality would not have been an issue. But as with many medical software systems, some of the sections needed extensive functionality making it hard for a single page design to support.
In the second iteration of the dashboard, I began breaking the sections out into their own pages with navigation to support the different sections. This took me back to the drawing board where I quickly sketched out sections so I could walk stakeholders through how it might look and function. This proved to be a much better approach.
I then moved over to Sketch by Bohemian Coding to develop higher fidelity mockups for approval and for the functional specifications. We went through multiple iterations of each screen and aligned requirements with the design in tandem. I also worked closely with our visual designer during this phase and passed off approved work to her for a final product.
Results
The dashboard was eventually split into 3 primary sections – basic patient information, a timeline visually representing the patient’s history and a section for usage statistics. Each of these sections needed to have a considerable amount of functionality per the requirements. Additionally, the entire dashboard needed to tie in with our mobile app for the patient as well.
Conceptual Examples
These are early screens developed in Sketch and used for iteration to the final concept.
