Avie is a business tool for medical clinics. It was designed to streamline workflow and give an all-in-one view of the clinic so that better decisions could be made for patients and for the business.
I worked on Patient Profiles and the Communications Center. I also defined an interaction model and a component-based design system that was used throughout the app.
As the only designer on the team, I worked with our client to understand what they wanted to accomplish. Then I turned what we talked about into visual designs.
We found that doctors and administrative staff were running their clinics with a handful of spreadsheets and systems that didn’t work well together. This way of managing information was inefficient and sometimes led to unbooked treatments, denied insurance claims, and missed opportunities to serve patients.
I learned that doctors and clinic staff needed to quickly find and make sense of patient information so they could offer suggestions for what to do next. Often decisions were made while a patient was on the phone or in the clinic. Once a decision was made, action had to be taken right away.
My challenge would be to organize patient information in such a way to be quickly accessible and easily readable. I’d also have to make it easy for staff to take action from anywhere within the application, in context of the information at hand.
I played with various layouts 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.
To access a profile, staff can search or choose from a list of patients. I chose to use a list view here because lists make it easy to scan and find one item in a large set of similar items.
To make lookup easier, patients are dynamically grouped in a few aways. Because staff usually work on a few patients at the same time, the top three most recently accessed patient profiles are grouped and displayed at the top of the list. The next most relevant group of patients are those who have appointments that day. Finally, patients who have been marked as no-shows (i.e. people who missed appointments) are flagged as an opportunity for follow up.
When you get to a patient’s profile, the first thing you’ll see is a header bar that summarizes the patient’s most important information.
I chose this layout because it lends itself to the F-shaped scanning pattern that comes naturally to most people, and because it makes it clear that the information displayed below is in context of a particular patient.
I explored different ways of organizing the various types of patient information. While lists keep things looking clean and uncluttered, they aren’t great for displaying multiple pieces of information per row. For example, for Patient Appointments, I needed to show the name of the treatment, date, time, doctor, and appointment status and type. I used labels to indicate the status of an appointment, but the other pieces of information would have to stay hidden in a detail view.
To show more information at a glance, I moved from a list to a data table. With a data table I could display all related information in one row, which would help users save time as they sort through patient data. By default, I chose to have rows be sorted in reverse chronological order because upcoming appointment are likely to require a follow-up action and therefore should take visual priority.
The downside of data tables is that they make for a dense-looking interface, which can be overwhelming. To spread things out a bit, I chunked rows by time block and separated each grouping with a sub-header row.
Next, I looked at different options for navigating between content views. Tabbed navigation seemed like the obvious choice here. But because of the tab bar’s position between the header bar and the data table, it felt like a poor use of vertical space that created too much horizontal division in the UI.
To solve this issue, I explored using an embedded side navigation, which freed up vertical space in the main content view.
Both tabs and side navigation are good options for quickly moving between content views and keeping the user aware their options. Ultimately I chose to use a side nav because of its flexibility for use in other sections of the app and because it pairs better with the data table view.
Staff can filter content in the data table by selecting filter options shown in a side panel located to the right of the primary content view. The benefits of a panel are that it promotes the available filter options and make it clear which options are selected at any given time. Since the horizontal space was available, I went with this approach instead of using dropdown menus in the header area.
It’s important for users to be able to perform common tasks quickly and in context of the information they’re looking at. To achieve this, I placed an action button in each row of the data table. Clicking these action buttons triggers a menu with actions relevant to the information in the row.
The detail panel in the Communications Center reveals a conversation thread. In this way, staff 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.
If a user selects a row in the data table, a detail panel sides in from the right edge of the screen. To make it obvious, at a glance, which row is selected, the row’s background color changes to be the same as the detail panel’s. At the same time, the opacity of the remaining rows in the table is reduced.
To preserve context, 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 sticks to the bottom edge of the viewport. In this way, the detail is always shown in context of its parent row.
I created style guide that helped us consistently apply styles, components, and design patterns across the entire application.
When communicating a design to developers, it’s important understand their workflow and what they’ll find useful in a design spec. Early on we talked about the concept for the app and got on the same page in terms of how to define the UI.
We were both thinking in terms of components and states, so it was natural to define specs in a similar way. I showed each UI element and its various states. I used an 8-point grid and bounding boxes to show alignment and spacing. And I showed how components snap together to form different views and content areas.
Copyright © 2018