Redesign with a Design System

My primary effort at CoverMyMeds was supporting the redesign and rebuild of the core web portal where users would process and manage prior authorization requests. This required coordination across multiple product teams to implement and create cohesion.

The Problem

At the time, the core portal design and tech stack were more than a decade old and in need of updates.

For design and experience, this meant meeting modern usability, readability, and accessibility standards as well as creating more cohesion between parts of the portal owned by different teams.

In regards of tech stack, this meant enabling faster development and experimentation in an application where it was difficult to accomplish either.

My main objectives as the designer were:

1

Redesign the core portal apps with our new design system in Figma

2

Do a 1:1 redesign of functionality to ease users into the new experience

3

Identify technical constraints and affordances early and often

Design System V1

I used the first iteration of our new design system to redesign the core portal apps.

Most existing components and functionality were accounted for in the first iteration of the design system. However, a lot of the work was also building new versions of things like form headers and modal dialogues.

I educated my product and engineering partners on best practices for using the design system.

For instance, we had various types of notifications for different situations, but many of our partners weren’t aware of when best to use them.

I taught engineers how and when we would use these components going forward and added these explanations to our Storybook Github repo for future documentation and reference.

Iterative Development

We were doing the redesign and rebuild by features and capabilities over the course of a year.

For me, that meant creating components and patterns with the new design system in Figma and then working with engineers weekly to verify that those items could be rebuilt in the intended manner. If they couldn’t, I’d come up with new variations of their designs and functions if there were constraints

Responsive Design

I had a few considerations in the responsiveness of this redesign:

  1. Adding a global nav bar and actions panel meant we had less horizontal space to work with.

  2. Keeping the white space to the right of the form kept it from feeling too stretched and left room for potential opportunities to use that space.

  3. Analytics revealed that 1280px was the most commonly used resolution by our users.

  4. For smaller resolutions like tablets, I decided to move the action panel to the top of the page, presenting the most common actions and putting the others in an expandable menu.

  5. We had small user base accessing our portal from mobile phones, so we accounted for that as well just in case.

Testing & Feedback

Pre-launch usability testing and a beta test helped us uncover some areas of improvement.

For testing during build, I collaborated with UX researchers on these efforts, creating designs or clickable prototypes for tasks in Figma and helping craft test plans. For those tests, we often received feedback that the new experience was cleaner and more readable due to the naturally larger text and elements.

In beta testing, users identified on some capabilities or functionality that wasn’t working as expected, and this allowed us the opportunity to fix those issues before launch.

Post-launch data gave us a couple of key insights:

  1. There was no decrease in access rates of those requests which we found to be a positive indicator.

  2. A very small user population was displeased with the new, lighter color scheme. However, we were planning on conducting some research in this area to better understand the stories on this sentiment.

High Fidelity Design Samples

(Click to enlarge)