Case Study

Case Study

Case Study

Improving collaboration in data-rich medical records

Improving collaboration in data-rich medical records

A regional health insurance company need a better experience for teams to authorize coverage for medical procedures.

The Project

The Project

The Project

Streamlining communication and collaboration to improve efficiency and transparency

The client was using an outdated, homegrown utilization management tool that focused on functionality, not usability. The information-dense screens were difficult to analyze and time-consuming to teach to new employees. There was no built-in task notification, so users had to check other communication channels to know when they had a record to review. Each record had to be reviewed in a timely fashion, so numerous staff members were working overtime to get through their queues.

I joined the project mid-way to refocus requirements-gathering with research and workshops. When our insights made it clear that we needed a custom solution, I stayed on to design an experience that would blend seamlessly into a larger implementation and Salesforce as a whole.

My Responsibilities

Design workshops, journey mapping, solution design, wireframing, prototyping, mockups

team

1 project manager, 1 analyst, 2 architects, 2 developers, 1 designer

TOOLS

Miro, Figma

My Responsibilities

Design workshops, journey mapping, solution design, wireframing, prototyping, mockups

team

1 project manager, 1 analyst, 2 architects, 2 developers, 1 designer

TOOLS

Miro, Figma

My Responsibilities

Design workshops, journey mapping, solution design, wireframing, prototyping, mockups

team

1 project manager, 1 analyst, 2 architects, 2 developers, 1 designer

TOOLS

Miro, Figma

What is Utilization Management?

I put together a 3-5 min overview of the utilization management process and key players to give you some helpful context. Beneficial, but not required to get value from this case study.

Coming Soon

Coming Soon

Coming Soon

User Research

Identifying User-Generated Success Criteria

Challenge: The project team brought me on because they were extremely frustrated: "The client rejects every screen we build for them, but can't tell us why."


User Research

Identifying User-Generated Success Criteria

Challenge: The project team brought me on because they were extremely frustrated: "The client rejects every screen we build for them, but can't tell us why."


User Research

Identifying User-Generated Success Criteria

Challenge: The project team brought me on because they were extremely frustrated: "The client rejects every screen we build for them, but can't tell us why."


I recognized the source of the frustration right away. Our team had been gathering "requirements" by asking the client, "What do you want to see?" and then building those elements into screens. The client had a viscerally negative reaction to the screens that they couldn't articulate, our team was building against subjective success criteria, and no one was happy.

I designed a client workshop to help bridge this gap. To prepare, I created a Miro board with one sticky note for every data point that was captured on the authorization record. With the client, we first identified all of the jobs to be done on an authorization and then, job-by-job, assigned each data point to one of three groupings - entered net new, consulted or not consulted for this job. Finally, we stack-ranked the data points by priority.

SCREENS

SCREENS

Solution Highlights

Solution Highlights

A more intuitive authorization creation flow

One of the client's biggest complaints about Salesforce's out-of-the-box utilization management product was that it didn't feel integrated enough into the platform. Though authorization records are created for existing members, and usually off of other authorization records for those members, the only way that Salesforce allowed you to create them was from the homepage.

One of the first design decisions I made was to move the authorization creation function directly onto member and authorization records. It was a more intuitive starting point, and allowed the platform to inherit more information from the starting record.

From there, I created a simple guided workflow that would conditionally display different information depending on the authorization type. This reduced the cognitive load of seeing unnecessary fields as well as the risk of errors. We also utilized the groupings from our research exercise to lay out the fields here.

Scrolling vs. tabs

Tackling the main authorization record page layout was a beast. Even though we could more intuitively organize the data based on our research, there was still just so much to place somewhere. I took all of the data we had and prototyped two experiences:

  • Long scroll: All data would live on one page, with the ability to open and close different sections.

  • Tabs: Users would click between tabs to see data. Data that didn't live in the active tab would be hidden from view.

Though the tabs experience was cleaner and felt less overwhelming, I had a suspicion that the client would prefer the long scroll. For one, it seemed like a more palatable change from the data-rich screens they currently loved so much. For another, each subsequent user who needed to work on the record relied upon the information entered by their previous teammates to complete their work. It was a more natural flow for them to read through the previous data, then have their fields appear down below, than have to click between numerous tabs to gain the context they needed to do their work.

Our user testing confirmed my theory, so we set about creating a custom, complex page layout with an emphasis on the long scroll.

Addressing all of the little details

Authorizations can be created about all types of medical procedures and, as such, need to be flexible enough to display a wide variety of data for a wide variety of situations. I needed to design a handful of custom card layouts to handle different authorization use cases, and each one had many variations to consider.

Reflection

Reflection

Reflection

This project gave me such rewarding validation about the power of UX to quickly gather requirements and create an informed vision that sets projects back on the right path. Design workshops and rapid prototyping helped to unblock conversations as well as allow frustrated team members who'd been spinning their wheels on this project for months to get some of their ideas out on paper.

Things That Went Well:
  • Aligning the client and our team on common goals
    It was amazing to see how quickly the tone of the project changed after our workshop. Simply identifying jobs to be done gave everyone a better framework by which to assess solutions - instead of asking, "Do you like this or not?", we could now ask, "Does this achieve the job of X?"

Things That Went Well:


  • Building trust through respectful use of time
    I was grateful that our thoughtful decisions about how to spend our user’s time (co-creation vs. validation, rapid-fire Q&A vs. empathy-building) resulted in users seeing us as partners, not just stuffy consultants. They constantly messaged us insights during their shifts, which benefited our work as well as gave them reassurance that proactive change was coming.

  • Achieving alignment with visual artifacts

    Both our client and build team praised our current-state maps for clearly highlighting the highest user priorities for our MVP, and our future-state maps for clearly articulating the optimal process. Both artifacts were successfully shared with individuals outside of the project, and were successful in bringing them up to speed with little additional clarification.

Things I'd Do Differently
  • More robust developer documentation and handoff
    Every business use case and its corresponding screens needed to be clearly communicated to our developers so they could build in the appropriate display logic. I stored all of those notes directly in our Figma file so developers would see them in context of the screens; however, they were hard to keep updated and for my team to ask clarifying questions in this format.

Things I'd Do Differently


  • Better knowledge transfer of detailed delivery insights
    During our discovery, the client inevitably shared tons of important technical details that were too granular for our research outputs but critical for our eventual build. Once our build team consumed our artifacts, they had to comb through raw meeting notes and recordings for the next level of detail. In future projects, I got better at indexing our notes so that build teams had an easier time finding more granular information.

  • More innovative future-state visualizations
    We were so proud of the solution that was represented in our process maps, but if I often think about I could have combined the maps and the supplementary slides into a single deliverable that represented both the solution and the change.

Can I add value to your team?

I'm currently looking for my next opportunity. If you think I'd be a good fit, or you'd just love to chat about design, please get in touch!

Made with

+

in 2024

Can I add value to your team?

I'm currently looking for my next opportunity. If you think I'd be a good fit, or you'd just love to chat about design, please get in touch!

Made with

+

in 2024

Can I add value to your team?

I'm currently looking for my next opportunity. If you think I'd be a good fit, or you'd just love to chat about design, please get in touch!

Made with

+

in 2024