MEMBER HEALTH RECORD
MVP
TOOLS
Wireframes, Usability testing, A/B and content testing,
Hi-Fi prototyping, Figma
SYNOPSIS
After demonstrating our Blue Sky project, our team received funding for the Member Health Record and was tasked with de-scoping for our MVP release.
TIMELINE
8 month project
ROLE
UX Research & Senior Interaction Designer
THE CONTEXT
After completing a Blue Sky (ideation work) project, we were asked to pare back our features and focus on the core of the health record, surfacing health information. Through this case study, we'll cover our iterative process, user testing, partnership with our product managers, data team and development teams and meeting our phase approached release plan dates.
Around this same time, our Health Record UX team was embedded in the Design System team which was developing a new Design System for our entire site and app. The Member Health Record would act as the pilot for using the Design System.
For the purpose of this case study, we'll spend most of our time on the visits page which paved the way and provided our strategy across the rest of this project.
Our team consisted of myself (Senior Interaction Designer), a Senior Visual Designer, and a Content Strategist. We all collaborated on performing user research using UserZoom for usability and A/B testing. At this point, we had a north star to guide us in the Blue Sky, so our focus was to assess all features and prioritize exactly what was needed for our MVP. We met with our Development team, Scrum Master, Product Management team, and our leaders to establish what features were absolutely necessary to launch this product. Our main goal was surfacing member health information which involved our Solution Architecture and Data teams setting up a schema, de-deduplicating data, and formatting data uniformly for user consumption.
THE TASK & APPROACH
DESIGNING FOR REALITY
When the reality of our data sources hit, we were faced with a daunting challenge. Our main task was problem solving in every sense. One of the first issues that arose and kept arising for every section, was the probability that almost every piece of data in the card or accordion could not be present. So with this knowledge, we were left with one remaining question for each feature section. What piece of data would be present 100% of the time for every card or accordion?
We had our Blue Sky designs and just had to reassess our data structure which started with the Visits section.
VISITS
We started by reviewing what features needed to be set aside for future state. The first was our "Upcoming appointments" feature. Our current platform did not have any existing capabilities to make, manage, or store appointments that hadn't already happened and therefore in our claims data.
Another feature removed was the search bar and filter feature. We had short timelines and were only able to design the structure and visuals for these sections. The Search and filter features were logged for a future enhancement.
The last page level feature that was removed was the ability to download records from the page. The question of security with health information came up here and required much more work with our Security team to be able to bring this to fruition.
From Blue Sky to our final MVP data card, we de-scoped and restructured the information.
As shown to the left, the Blue Sky card includes an after visit summary link and claim details drop down. The after visit summary was removed from the MVP as we did not have the data to support this feature. When looking through Snowflake, we noticed the Doctor's note section was blank 98% of the time making the after visit summary page futile.
The claim details were de-scoped due to the time needed to develop and implement this feature. Attempting to do so would have heavily impacted our effort to meet pressing release dates.
The date became the bolded information when we found that all other pieces of data had a high likelihood (60%+) of being absent or "unknown" in the data source. The date was the only piece that was present in all cases. The doctor, location and visit type could or could not be present in any combination or permutation.
If your head is spinning, so were ours at this time.
This same situation would crop up time and time again throughout this project, but this first go provided us with a strategy for all other sections. We now knew what to ask for from product managers and the data team so we could assure our cards and accordions were structured properly and would withstand the stress of inconsistent data.
USER TESTING
We presented our work to the product and development teams which garnered some discussion around usability and failure states. We started with usability testing which included the Health Reminders, Visits, and Medications pages as we were ahead of our design schedule.
Below were the results of our test:
We had a pretty successful test overall, with 100% task completion on every task except 1 which still had a high percentage of 87% completion.
After sharing these results, the question of graceful fail states was discussed. We'd learned a number of issues came up in our data:
-
UNKNOWN for facility (82% occurrence, will be mapped to “Facility unknown” to replace)
-
CAT% values for facility (5% occurrence, will be displayed as is)
-
Other non-meaningful values of uppercase letters, numbers, special characters (fall under 5-10% occurrence thresholds, will be displayed as is)
-
Start date > end date (3% occurrence, we will suppress either end date or entire record, pending data team confirmation)
We settled on an in-card tool tip but had a team conversation around which icon made the most sense to denote "more information" while not inciting frustration or alarm. So we moved onto creating a test to gauge user understanding of potential icons as well as those icons in-situ.
We first asked users what they understood each of these icons communicates, which provided the following results:
Next, we asked users to rank the icon preference that best communicates incomplete or unreadable data and saw the following results:
With these results – we recommended sticking with the “i” icon, as it was ranked the Number 1 preference most often out of the 3 icons and was understood by users as getting further information.
DESIGN HAND-OFF
After user testing, we finalized our visits page and sizes for hand-off to our product managers and development team.
Large
Small & Mobile
We passed these designs to dev, but our work wasn't done there. We had regular meetings with the development team to ensure that all elements of our work was reflected accurately in our environment for launch. They were able to use pre-set fonts from the Design System and colors from the new color palette as well as pre-set tool tips.
The framework of the experience, the header and tab sidebar functionality, was developed prior to the work on Visits.
After several meetings we were able to sign off on the work from the development team and pass over to the functionality testing team. After a final sign off from our Product Manager, we aimed to release the product in May.
RELEASE DAY
All prepped for release day, the time had come! Myself and our Senior Visual Designer joined our development and testing teams to work through all user happy path scenarios and error scenarios.
As we combed through, we took note of any small issues or missing pieces that would be resolved by the development team the following week.
DETERMINE OUR PRIORITIES
Our UX team met with our development, data, solution architect and product management teams to get a sense of timelines and priorities. The data team's work was well underway at this point and they had timelines set for each data sets' availability to flow into our designs. This gave us a great starting point to prioritize the sets that would be ready first and make sure that our error scenarios and information hierarchy within the cards acted accordingly.
As the Health Reminders section was an existing feature at Blue Shield this also became an easily attainable priority. All that was needed in this section was a re-skin.
After this meeting, our top four priorities to prepare to pass to development were our entry points, Summary page, Visits page, and Health Reminders page. For iOS and Android, we had an additional page to have prepared - the home page. To do this, we had to run all of our designs against the Design System team and make sure we were aligned with what had been implemented in our codebase to provide our developers with easy implementation of our work.
This case study will focus on the Visits section which encompasses testing, strategy around data availability, and error scenarios.
FINAL THOUGHTS
After we released, we planned to keep an eye on user feedback and adjust as needed.
In addition, we had a full list of enhancements for this section, as well as other tabs to get working on for the next planned release.
If you're still here - Thank you! I hope you had as much fun reading as I did working on this project. If you're interested in working with me - feel free to reach out at the email below.
