Avie is a CRM tool designed specifically for medical clinics. Its purpose is to streamline workflow and give an all-in-one view of the clinic so that better decisions can be made for patients and for the business. Doctors and staff use this product to manage and track patient information, schedule appointments, process insurance approvals, and manage communications.
When I joined, I was given a set of product requirements and a visual identity to work with. I had access to brand fonts, colors, and iconography.
A few screens had already been mocked up, but we ended up moving away from those designs. As development began, it became clear that screens had been thought of as an individual websites instead of as software made of components that work together. Each screen had slightly different UI elements and there wasn’t a clear understanding of how things worked together, as a system, across the application.
I designed Patient Profiles and the Communications Center. As I worked through Patient Profiles, I defined an interaction model and a component-based design system.
As the only designer on the project, I worked with the client and the project manager to understand what they wanted to accomplish and why. Then I turned what we talked about into visual designs. I iterated based on client feedback, reconciling issues raised by the team by explaining my rational for each decision and then making changes where necessary.
It’s important to understand the situation you’re designing for. I spoke with doctors and clinic staff to understand what information they use to make decisions and what actions they take as a result of the decisions they make.
I found that doctors and administrative staff were managing their clinics with a handful of fragmented systems—spreadsheets and databases that don’t talk to each other. This way of doing things was inefficient and led to unbooked treatments, denied insurance claims, and missed opportunities to serve patients.
Doctors and clinic staff needed to quickly find and make sense of patient information so they could offer suggestions on what to do next. Often this happened while a patient was on the phone or in the clinic. The actions they took most often were scheduling appointments, processing insurance approvals, and following up with patients via phone, email, or text message.
My challenge would be to organize the different types of patient information in such a way to be quickly accessible and easily readable. Second, I’d need make it easy for users to take action quickly from anywhere within the application, in context of the information at hand.
I outlined various structures and patterns for navigation and content organization. My intention was to come up with a few concepts that’d be able to display all data types while being simple enough to navigate with ease. By combining and rearranging UI patterns in this format, I was able to quickly show how they’d work together to achieve the desired outcome.
In the sections below, I’ll go through some of the design decisions in more detail.
To access a patient’s profile, doctors and clinic staff can search for a patient or choose from a dynamic list that shows recently viewed patients and patients who have appointments that day.
The patient profile shows a patient card with their avatar and most important information.
Below the patient card is all the information about the patient and their history with the clinic.
I explored different ways of organizing patient information, starting with a list view. Here I also used labels to show the status of an appointment.
To show more information at a glance, I moved from a list to a data table. I also moved from labels to icons, shown to the left of the primary column, to indicate appointment status.
Content is grouped in reverse chronological order by default, using a sub-header row to indicate the grouping.
Next I explored navigation options. Because of the header row on the data table, the available vertical space for content was reduced. Moving from tabs to an embedded side navigation helped free up more space for content.
Both tabs and side navigation are good options for quickly moving between views, and keeping the user aware their options. Ultimately the side nav was chosen because of its flexibility for use in other sections of the app and because it pairs better with the data table view.
Users can filter content in the data table by using a persistent filter panel. The benefits of a panel are that it promotes the available filter options and displays what’s selected at any given time. Since horizontal space is available for this panel, it was chosen instead of using dropdown menus in the header area.
Selecting a row in the data table slides in a detail panel. When a row is selected, it’s highlighted the same color as the detail panel background. At the same time, the opacity of the remaining rows in the table is reduced. This makes it clear at a glance which row the details belong to.
If the user scrolls down while a row is selected, the selected row will stick just below the header row. If the user scrolls up, the selected row would stick to the bottom edge of the viewport. In this way, the detail is always shown in context of its parent row.
I applied the same layout (side navigation, data table, filter panel) to the Communications Center.
Here you can see the Quick Action Button present in each row. Clicking this button triggers a menu showing the most common actions for this context.
The filter options have been updated so they relate to the content in this view. Here a user can filter by patient or staff member. They search for a person, select them from the autocomplete menu, then keep the checkbox selected as a filter option. To remove a person from the filter set, the user could uncheck the checkbox or remove the option completely.
Just as in the Patient Profiles section, selecting a row in the data table slides in a detail panel. In this case, the full conversation thread is shown. The user can reply in-line via the original communication channel or use the contextual action buttons below the chat window to perform a follow-up task.
I created a style guide to make sure we were consistently applying styles, components, and design patterns across the entire application, and to help the developer with specs for each component.
Copyright © 2017