EQ Dashboard | Michael Mabee

Highmark EQ

Team:

Michael Mabee - Product Designer

David Crane - Product Director

Stephen Elliot, Manjunath Padolkar - Developers

Margaret Lacey - QA

Tools Used:

Adobe XD

Available:

highmark.tech

As the product designer at Highmark Interactive, I was first tasked with upgrading the Users pages of EQ's administrative dashboard, because the admins found it slow to use and made them prone to making errors.

RESEARCH

After reviewing the initial state of things with our incredibly knowledgeable product director, who had been with the company since the inception of the product, I spoke at length with our subject matter experts – organization administrators from both inside and outside Highmark. For the dashboard, our user personas broke down like this:

Clinical Admin

Usually a doctor or physiotherapist within a clinic
In charge of a roster of patients who are coming to them for treatment
Ongoing monitoring and periodic contact with already-injured patients
Needs to address the needs of hundreds of patients, have easy access to review testing results previous to and during the appointment, manage user groups for their organizations

Sport Admin

Usually a physiotherapist, kinesiologist, coach or trainer who has been given the role for a team, league, or athletic program
In charge of managing processes for unruly groups of younger users
Periodic direct contact with users, unless they enter concussion protocols, at which point they would pivot to daily interaction
Needs to be able to manage groups of users effectively, have visibility for user status, and compliance with testing regimen

Enterprise Admin

Usually a trusted figure in human resources or organizational health
In charge of access for thousands of employees
Periodic monitoring for organizational health purposes
Needs to not have access to user health data/test results, but must have a clear picture of the aggregate health of the organization, down to a group or location level

The insights that I took away from those conversations were:

Our app and dashboard are used to inform the admins' regular interaction with their users, so we should be efficient.
With health products, especially those that cross over into the workplace, privacy is of utmost concern.
Seemingly at cross-purposes to privacy, our admins need more information in order to do their jobs effectively.

An additional learning from first-line healthcare: "Go slow to go fast". For example: ambulance drivers can seem to take forever to get from the vehicle to the patient, but they're really assessing the situation, taking stock of obstacles and absorbing as much information as they can before they get to the patient. All of that data factors into the decisions they make about exiting the building, working with people at the scene, and treating the patient. Taking a little bit of time and being mindful initially can save a lot of time in the long run.

After speaking with our users, it became apparent that our interface was slowing them down, and a new approach was going to be needed to give them the access and visibility they needed. It was time to start looking into interfaces that could manage groups at scale.

PLANNING

It was time to break down the elements of what was there, in order to optimize it for our admins. The original design was reminiscent of an e-mail client, with all of the actions and the user list stacked on the left, and client data in the preview pane on the right. The limited space meant that the user list was just group and user names, and that most of the buttons were presented out of context or without labels.

On the top level, our admins would need more non-medical information that could be skimmed to accomplish organization-related jobs (ie. grouping users, monitoring registration status and testing compliance). If one of those metrics wasn't what it should be, the admin could drill down to the user level and address the issue (ie. edit, e-mail, re-invite, or remove the user). All of the organizational tasks could be accomplished without exposing medical information to passersby.

Prior to beginning any work, I spoke with our developers to work out which frameworks I'd be working with, and to figure out what visual language I should be building with to make development efficient (Laravel & Vuetify, so Material Design).

DESIGN & TESTING

With a new collegiate athletics season looming, the pressure was on.

I started with creating a structure that would provide layers for role-based permissions:

a super-admin level allowing for both admin and medical data access for all groups within the organization
- a group-level admin view that would allow lower-level admins to work the same access, but within an assigned team
an enterprise admin level that would allow administrative access, but no visibility into medical information
- a group-level admin view that would allow lower-level admins to work the same limited access, but within an assigned team

Next was organizing and extending the the tools they'd need to complete tasks: I provided them with easily-digested data about each group as an aggregate, and the status of each user in that group, so that they could go about administrative tasks in an informed way at a glance, and could complete tasks in batches, rather than having to dip in and out of individual files to review and execute them individually.

I grouped together the search and filter functions, which would present only the users with a given status, for added efficiency in larger organizations. I also added a column-by-column sort function, in columns of the table where it might be useful.

I moved the group-level administration tools (create/edit/delete) from an entirely separate page to the Users page, so that they could be edited in context.

Finally, I moved the users' medical results to individual sub-pages, so that they could be hidden from non-admin staff that shouldn't have access to them.

Building out a high-fidelity prototype and the early stages of the build allowed me to test the changes with our users to gather feedback. In testing, we found that:

With organizations that were particularly large (ie. sports leagues, enterprise organizations, busy clinics) the number of users placed in a group could number into the hundreds, so the even with collapsible groups, loading and navigating a large org could be time consuming.
When performing daily reviews of users with a given status (ie. injured or non-compliant with their testing schedule), our admins were still having to dip in and out of individual user files, but were doing it because they lacked a way to navigate directly between them.

I approached the large-organization loading problem with three tactics: search and filtering, a number-of-results-per-page select with pagination, and an open/close all groups toggle. Search and filtering made finding one user (or group of users with one status) easy. The pagination and limited number of results per group worked as expected – they reduced the call time on loading and gave the admin as many or as few results as they desired. The open/close all groups, when coupled with persistent settings saved in a cookie, meant that an admin now didn't have to load the full organization's user list at all – they could survey the groups for indicators, drill down through the group and into a user's results.

To tackle the time-consuming in-and-out movement between files, we added navigational buttons, but took them a step further - when the clients were filtered for a specific state, we made that state persistent when navigating using those buttons. If you filtered "injured" users, you could now see the full list, dip in at the beginning, review all of the "injured" users' files and re-surface at the end of the list.

OUTCOMES

With this being more of a re-organization than a build from scratch, we made the back-to school deadline for deployment, and after a short and relatively painless period of adjustment, our admins were happy with the results, as we had made their jobs much easier to accomplish.

This was my first big win with Highmark Interactive's users, and with open lines of communication, we continue to design and develop new features for the dashboard to meet or exceed their expectations.