Objective
Help the team better understand the problem space by reassessing the user personas that had been previously developed for the product.
Background
A Shared Savings (Pay-Per-Performance) program involves physician practices or medical groups who collaborate to give coordinated high-quality care to people with Medicare coverage. When a practice or group succeeds in both delivering high-quality care and spending health care dollars more wisely, they are eligible to share in the savings it achieves for the Medicare program.
The Health Plan’s Shared Savings program delivers reporting data to its groups as a monthly package of lengthy PDF files and Excel spreadsheets, which can be cumbersome to navigate and difficult to use to compare data from multiple months or years.
I was assigned to a product team that was developing a web app that would provide a more dynamic user experience with a flexible, accurate and up-to-date view of a group’s performance in the program.
Project stakeholders included Data Analysts who are responsible for generating reports for each practice and group, as well as Medical Directors, administrators and clinical users who are responsible for implementing patient outreach strategies based on the data.
Up to this point, the design was dictated by the business stakeholders. The Product Manager requested my UX research and design expertise to learn more about their intended user base and to develop artifacts to articulate findings to the rest of the product team.
Process
The Product Manager provided me with a PowerPoint deck with 14 user personas to work from. There was also a video recording of a previous stakeholder review of the product and notes from user shadowing sessions.
I created a Miro board to compile all the information we had on each of the 14 personas, as well as notes from initial meetings and suggestions that had been made by the Product Manager when I started the project.
Right away, I knew this was an unrealistic number of personas for a relatively simple app. All best practices I’ve read suggest keeping the number as low as possible. I also got the sense that team was spinning on where to start because they thought they had to address all these personas.
I verified the list of existing personas through two business-side stakeholder feedback sessions, which yielded initial feedback on how we might combine or eliminate some of the personas.
By the end of the second workshop with the business stakeholders, we narrowed persona the list from 14 down to 5.
I consulted with Product Managers for their feedback, then conducted interviews with clinical Subject Matter Experts (SMEs), which confirmed these findings. I created a Miro board to compile all the information we had on each of the 5 remaining personas. These included:
- Practice-Based Care Managers
- Population Health Managers
- Quality Nurses / Quality Staff
- Office Managers
- Data Analysts
My next step was to add detail and realism to each persona. I conducted a series of interviews with practice-side stakeholders, as well as clinical SMEs, each one focused on a specific persona. I learned about their responsibilities, as well as how they interacted with the data. I also interviewed business-side stakeholders, as they are part of the user base and have specialized needs for the app. We reviewed the persona draft that most closely related to their job responsibilities and they provided feedback and additional insights.
I synthesized all six one-hour interviews into summary documents and iterated on the five personas:
- The Pop Health Paul persona could be eliminated, as Population Health Managers receive their assignments as a printed list from their supervisor and have no interaction with Shared Savings tools.
- The Shared Savings Sandy persona should be split into two separate personas, as Data Analysts / Quality Team have very different needs from Clinical Information Specialists and Value-Based Reimbursement Strategists.
I learned that each persona has unique needs for the app:
- Some users need financial data, others quality data, and some need both. Data Analysts need to be able to see everything, while a Practice-Based Care Manager (PBCM), for example, has limited data needs.
- Depending on the persona, users might need access to data at the medical group, subgroup or individual practice level. Administrative users would likely need to view at each level for different reasons.
- Administrative users who create strategies are looking for gaps to target that will have the greatest impact on their numbers.
- Quality users are searching for reasons why the gaps exist to address larger issues, such as incorrect code attribution in claims.
- Patient-facing users need to know how many members they need to close a specific gap or lists of members in that gap so they can plan outreach efforts.
I also learned that users need context to work effectively:
- Knowing exactly how a measure is defined and what is required to meet the goal for that measure is helpful for almost all roles.
- Being able to compare current performance with previous time periods and the target helps the user visualize trends.
Results
Based on these findings, I iterated on the personas to include core needs, frustrations and a description of what a typical day is like. I updated the job tiles and quotes to reflect the stakeholders I had interviewed. The completed persona artifacts were a more concise and accurate representation of real users, and helped identify key user needs, pain points, motivations and desired outcomes. I created a set of journey map artifacts to represent the unique journey of each persona as they currently interact with Shared Savings program documents.
All of these artifacts were added to our persona library in Azure DevOps, where they can be accessed by hundreds of UPMC Health Plan employees and used in the creation of new product features.
I shared the artifacts and findings during sprint reviews with the stream-aligned development team assigned to the project, as well as our entire SAFe® Agile Release Train (ART) of about 200 employees. My goal was not only to inform the rest of the ART of our progress, but to educate them on the value of conducting user-based research to better understand who we are designing and building for, and why.
Narrowing the personas down to 5 enabled the team to prioritize and get started, which they were unable to do when they were struggling with the 14 personas. Administrator Alex turned out to be a good starting point to drive feature development.
