My Role: Senior UX Designer and Product Owner
HealthCo, a major Michigan healthcare payer, needed to a create a graphic-oriented and visually friendly account dashboard that showed up-to-date deductibles, out-of-pocket costs, recent claims, eEOBs and other elements pertinent a consumer-driven healthcare model.
After launching several high-deductible health plans that introduced deductibles, HealthCo needed to find a way to quickly and visually communicate the overall status of a member’s plan. This ‘bird’s eye’ view of the various aspects of the member’s plan needed to be a dashboard, of sorts, that included some kind of graphical indicator of deductible status, out-of-pocket maximums, the last 5-10 claims, electronic explanations-of-benefit (eEOB) as well a quick listing of in-network providers.
Additionally, the project would be converting old code from Microsoft’s .Net Webforms to MVC, so much of that code would need to be rewritten and a new interface would need to be designed to sit on the C# code. This was a large project that basically took the original, less functional and usable, member portal area down to bare metal for a complete and total rework and redesign.
We didn’t know how we were going to present the core functionality that had been defined at the outset
Initially, the team had scrutinized many approaches for how the UI would or could be done. The plan that we stuck with the longest was a WordPress frontend that would interface with the C# code. However, outside of some loose requirements we didn’t know how we were going to present the core functionality that had been defined at the outset.
This is when the research began. We started initially doing user interviews with HealthCo membership and internal staff. We had satisfaction surveys and analytics information available to us, so we had good sense of technical and demographic usage. With this information, we begin to create personas. Specifically, four types of personas that covered the primary age groups that represented HealthCo membership and users. From these personas, we began to create use-cases. Even with the use-cases, there were many differing opinions on layout, design, colors, etc.
If you could build a dashboard
any way you wanted,
how would you do it?
The team decided that we needed to take a more hand’s on approach with our user and our research. We began doing user interviews, but as part of the user interview, we gave the user a package that held a basic print out of the dashboard wireframe without any functionality represented, a series of shapes from UI and wireframe kits that represented functionality, such as gauges, tables, banners, buttons, etc. as well as a glue stick. We gave one instruction: If you could build the dashboard any way you would like, how would you do it. Use the glue stick to paste pieces of functionality to the dashboard print out.
After a dozen or so user interviews, something quite amazing started to happen: For the most part, unbeknownst to each other, these users were mocking up, the same layout.
As the team watched it happen, we almost couldn’t believe it
As the team watched it happen, we almost couldn’t believe it. After months of differing opinions and, at times, very heated discussions, we were finally getting consensus. When we completed this session, we know what the layout of the dashboard and user experience of the design would be.
We didn’t stop there with the research, we then did low-fidelity prototypes based on ‘paste up’ round of user research and when we encountered dissent, we showed people the video footage we had of the user interviews where the members created such similar mock-ups. After a short period of time the prototypes took on a life of their own and became the standard expectation for the dashboard, as if that had been the plan all along. The research brought everything together beautifully.
While we were doing this research, the development team was working simultaneously to code, with the expectation that user interface and user experience design decisions would be forthcoming. About the time we received final sign-off on our prototypes, and after some paper prototype usability testing, we were able to begin bringing the design and development work together.
We hit a snag here, as we had been planning on using a WordPress frontend that would act as an interface with the C# code, but the teams just couldn’t make that work. A decision was made to fork the WordPress theme, which stakeholders had gotten used to seeing, and connect the functionality using Bootstrap elements. Fortunately, this was more of a change in perspective rather than something that ended in rework and best of all it allowed for the overall user experience design to be smoother and less clunky than it might have been if we had forced things to work together.
Once all the pieces were successfully brought together, we complete two more iterations of usability testing to round of any rough edges. By the time it came to the high-fidelity design we were in a place with solid buy-in and consensus with stakeholders, but when they saw the functionality come to life, they couldn’t believe their eyes; we had successfully brought together organizational system and claims data represented in a graphically and visually engaging way that told a clear story about the member’s health plan status. This was a real win for user experience design at HealthCo.
After an internal pilot that lasted a couple months the new system was rolled out and unlike so many big changes immediately began getting great feedback.
It was a great big, satisfying job!
Some highlights from HealthCo’s redesign included:
Contact center volume was reduced by 23%
CSAT (customer satisfaction) score went up 7 points
NPS score went up 13 points
Call center call time was reduced from 15 to 1.5 minutes, cumulatively for deductible and claims-related calls
I have omitted and obfuscated confidential and proprietary information in this case study.