This product had been in use for 8 years and was developed with no usability direction or regard for accessibility.
Case in point: when I was first shown this product, I asked the two people I was speaking with about a function I saw on the screen. They gave me puzzled looks. It turned out both were colorblind and so neither of them
could see the on-screen elements I was asking about.
I created both short and long term improvement goals. Using heuristic evaluation, I determined immediate usability needs that could be easily amended. I used qualitative and quantitative research methods to uncover the truth about our users real work, what struggles cost them the most work time, and their ad-hoc processes to make work more efficient. In tandem with this research I worked with the development team on modular improvements.
We restructured the UI into discreet "zones of work" that allowed care coordinators (CC's) to work much more efficiently and quickly with less far clicks and minimal scrolling. Average call times per patient were reduced by 5 minutes each, meaning a single CC could reach at least 2 more patients each day.
TDH Initiatives | Care Director Plan | Care Director | Experience Transformation
Agile User Research
User comments were normalized across users to build a picture of users real experience with TimeDoc software. (example of a portion of the data model)
Isolated specific sequences of user activity and identified process breakdowns. (example of a portion of the data model)
Quantitative Analysis
I used Full Story to track users' journeys and discover what functions within the UI were being underused or misused.
I was able to see exactly where repetitive clicks and scrolling were bogging users down as well as measure exactly how much time was being wasted.
After noticing a significant pattern I would ask follow up questions with users during the Continuous Discovery meetings to get more of the "why" behind their behavior.
SUS Scoring
Before updating a feature I would run a SUS survey. After any updates had been in production for a couple of months I would then run a follow up survey to get a measure of the improvement.
Because of the nature of the survey I was able to track scoring & participation trends by different user segments. These segments were based on users longevity, whether they were bilingual, or any number of varying roles that would affect their experience of the software.
Personas
Comment from qualitative testing were used to build a persona library based upon users' real qualities and attitudes.
These personas were then brought into ideation sessions so users would be represented during all brainstorming work.
I was eventually able to associate personas with each user that we had ever interviewed or who participated in users testing. This helped build an understanding of which personas would be the most successful at the company and influenced what hiring managers listened for when interviewing potential CC's.
Because we dealt with sensitive patient information, it was necessary to represent those users whose attitudes and qualities posed a risk. From the user data I isolated characters whose potential misuse of our software and security protocols could lead to negative consequences for the company.
Again, this provided hiring managers with a guide to things they should listen for when interviewing potential candidates.
Vision Sessions
Team collaborated on understanding the most effective flow of data and potential choice sets before any mockups or visual models were created.
Truth Tables
Once we understood the basic structure and flow, it was important to match that with the database so that we weren't creating potential problems for ourselves down the road.
We used "truth tables" to ensure that the functionality could be organized in a tabular form. If something didn't quite fit or it felt like sub-tables were needed...then something about how we were approaching the problem needed to be rethought. Even though the function may not eventually appear in the UI as a table, we had to make sure it worked as one. Because if it doesn't work as a table, it won't work well as side panels or cards.
Storyboarding
I realized that the term "wireframe" meant very different things to teammates from different areas of expertise. As I worked out the basic interaction and placement I used the term "storyboard" instead. These gave us a low effort way of proving our ideas before investing the time in a prototype.
Design System
I wanted to craft a deliberate system that established all color, sizing, and type variables and then put these together to create elements and then build components. This provided a much needed sense of how all aspects of the design fit together.
This established consistency made it easier for developers to know which styles to employ and created a more readable, predictable interface for our users.
Interactive Prototype
Gave the team a thorough feel for experience and allowed for further questioning of functionality.
This established consistency made it easier for developers to know which styles to employ and created a more readable, predictable interface for our users.
Remote User Testing
Comparison of click pattern through original and proposed interfaces
Users were presented with real world scenarios to solve within the new UI.
Up to 6 users were tested individually for each feature design.
Updated UI
Recent patient events shown in a horizontal timeline wasted lots of time and clicks and did not help CC's build a picture of patients' recent activities.
Events presented in manner that gave a full picture in one glance. Users cited the change as "a great relief" and "what I've been asking for for years".
Medication management earned the worst SUS score of all functions tested. The interface is rife with inconsistencies, conflated functionality, and confusing signifiers. Because the functionality was so unclear CC's would refrain from verifying medications over the phone with patients. The poor layout also led CC's to misunderstand their real role in patient medication management.
I realized that there were 2 things being tracked here. First, is the patient taking meds according to directions and second, is the dosage information we have accurate. The original interface pushed these two disparate functions together, causing CC's to edit medication dosages and record adherence issues incorrectly.
I separated these two functionalities, making the CC's real work more obvious. A common complaint was the difficulty in finding a medication in the very long list. I decided to exploit a familiar UI layout CC's used daily to sift through lots of information: their email! Thus I moved the medications into a searchable, filterable left column and set it up so that selecting a medication on the left changed the main content area on the right. They loved it.
Added a dashboard to patient record making it easier to quickly skim and see what was going on with a patient. Drastically reduced clicks and scrolling and shaved minutes off call times.
SUS Scoring
Comparison of scores from all tests conducted
Redesigned features consistently showed an improvement of at least 10 points. Newly designed features consistently scored in the "excellent" range.
Continued Quantitative Analysis
I continued to use Full Story to monitor usage and measure time saved.
In addition, we were able to detect low adoption or anti-patterns and address these either with continued redesign efforts or user training.