Desinging internal enterprise software, hand-in-hand with our users.

2017

Overview

THE TASK

Design and build claims-processing software for Collective Health to replace the decade-old third-party platform we have been running on since the start of the company.

Collective Health is essentially a one-stop health insurance platform that connects medical, pharmacy, dental and vision benefits for employees and employers. As a growing company who’s mission is to simplify health care, we need to be able to change the world of plan design, and changing the way health insurance works means changing the archaic way health claims are processed.

THE TIMELINE

Back End got an early start on this one in Q1.

Starting in Q2, Design and Front End came on board, and we’ve been working together since then.

Get the new software functionally to-par with the current (Beacon) by 01/01/2018
Increase Ops efficiency and scalibility by reducing manual effort
Eliminate reliance on third party software by creating ownership of our own tech platform
Increase job satisfaction and decrease time to manually process claims.

THE GOAL

I was partnered with a lead designer for this project. While both of us are categorized as product designers and tasked with everything from research to working with Front End to implement designs, his emphasis is in systems thinking while mine is visual design.

Research and user observation

System architecture

Workflows and wireframes

Visual design and design-system evolution

User testing

Dev collaboration and implementation

MY ROLE

Product Managers

THE TEAM

Front End Engineers

Data Scientist

Designers

Back End Engineers

Research

Never in my life did I think I’d need to know how insurance claims of any kind are processed. Surprise! Design is never what you expect. So, in early spring, we set to the task of not only learning how the sausage is made, but really getting to know the people who make it.

GETTING TO KNOW OUR USERS

One amazing advantage to this project is that our users are right on the floor above us.

OA's (Operations Associates) are the people in the company tasked with the adjudication of claims, among many other things. We conducted multiple interviews asking users like Kimiko what her pain points are and what her blue-sky wishes might be.

UNDERSTANDING THEIR PROCESS

New OA's go through weeks of training, and we were able to get abbreviated versions of their training to attempt to understand the world of claims.

Training looked a little something like this. Needless to say, it didn’t really land with most of us, but we had to keep making progress.

OBSERVATION & TOOLS

Next we did about ten hours of shadowing to watch the OA's do their job. Seeing first-hand what they do and how they do it was quite an eye-opener. I apologize for the coming assault on your eyes, but you have to see this to understand just what we were dealing with.

This is Beacon. This travesty is the primary software OA's have to attempt to navigate to adjudicate claims, and this is the ancient, industry-standard-of-a-beast we were tasked with replacing. The scariest part is, OA's need to access tons of other tools and windows to complete regular tasks.

High-Level Findings

Dozens of things could need manual review, so there are no set steps or flows. Additionally, every team and really every OA has their own processes. This means we’ll need to make errors obvious in the UI without forcing too much inherent hierarchy on the page.

Any edit or adjustment that needs to be made is heavily influenced by the other data in the claim. This means we’ll have to veer away from common notions of simplicity and make sure we never hide vital content or force our users to do much scrolling.

We had always heard it sucks, but wow does it suck! Teams have developed their own fixes to Beacon’s shortcomings and need to access a ton of tools to get the job done. Aside from this being inefficient, it is a terrible user experience. Our OAs are far too awesome to have to deal with such bad software.

3 –

Beacon sucks.

2 –

Operations Associates are super-users and want high information density.

Claims really only need to be manually adjudicated when something goes wrong.

1 –

GETTING STARTED

We got to work on trying to make sense of all that we had learned by diagraming all possible routes through the adjudication pipeline. We knew this wouldn’t be perfect, but it was enough to get designing.

BUILDING BLOCKS

Even though we were building something totally new, we weren’t completely starting from scratch. The Claims Engine was going to live within a larger internal-facing tool we like to call Falcor.

By this time, Falcor had been around for almost two years and was complete with it’s own mini design system which included interaction patterns, color, type, and grids, among other elements.

We used existing pages in Falcor and what we knew from studying Beacon to come up with our first mocks.

V1

In Q1, the company had officially started it’s own design language system. The project was only a few months along, so little more than colors and type were decided upon, and all were chosen with our member-facing products in mind. Because we were starting from scratch on a part of our internal-facing product, this was a great opportunity to test, adapt and progress the system for Falcor.

Curveball!

Test & Iterate

While working on implementing the new design system, we continued to iterate and test quick prototypes with the OA's at the end of every two-week sprint. We did testing with at least three OA's, pulled insights, and shared with the team. Then we would update designs and start the process again.

LET'S TAKE A STEP BACK

With the opportunity to change Falcor’s standards, we decided to re-evaluate everything down to the breakpoints and grid.

During our observations, we noticed that OAs only ever adjudicate on their giant monitors. So we took a look at Falcor’s breakpoints and decided to add a new, HD+ size and actually optimize for taking advantage of more screen space. .

Where we are today

Over our six sprints of testing and iterating, as well as some pauses for brainstorming and refinement, we made a ton of progress, lots of changes, and have started defining and sharing a new chapter of Collective Health’s Product Design Language System.

We recognized that generally, OA's do some quick visual scanning of the page and the claim’s data, but spend the majority of their time deep inside the claim lines. When they’re adjusting lines, they don’t want any other information obstructed, but don’t want more tabs.

V2

V851.5 (ROUGHLY)

We moved all of the claim’s metadata into the left colum and allowed for dual scrolling so it’s always accessible. This allows OA’s to dive right in to the claim lines and never miss claim data.
This change also allows for much more data on-screen with less scrolling, and cleaner hierarchy of importance.
We redesigned the subnav (main nav not under our control yet) to be a dropdown which allows for scalability of pages. We also exposed the action buttons so they’re not hidden.
Claim lines are now very slim, but all the data and edits within them are only a click away. Additionally, the lines themselves expand instead of a pop-up that obscures data.
Color has been eliminated from everything that’s not an alert, status, or an indication of interation. This allows for easy-to-spot alerts.

CHANGES TO NOTE

What's Next

Rebrand?!

Design is about 3-months ahead of dev, which we don’t want, so we’re taking the opportunity to take a step back. We’ve been building a bullet-train as we rode it and now we’ll have a chance to imagine what this experience could be in the future. Then we can take a stab at evolving the current design to be closer with the ideal.

Visioning project

Currently, this project has been named “Ingenuit,” complete with a word-art logo, brought to us by our PO. We’ve been attempting to push a new idea– “The Adjudicator,” which would be personified in a Mexican Lucha Libre wrestler. We want to add some delight with animated wrestling processing states and fun errors. We’ll see if we can get resourcing on-board…

We need to design out what a claim adjustment looks like, and bring back in the “Notes & Flags” section that we had punted. We also need to sort out what the history of claim edits will look like and how users will interact with them, especially when they’re auditing claims.

Last bits of bringing functionality to-par

Opportunities

We’ve had a lot of changes to the size of our back-end team, and have oscilated from Scrum to Kanban as a reaction. We’re starting to learn that while we can’t be as agile as we like with this project, Kanban leans much too far towards waterfall, and doesn’t allow for enough collabroation. We’re starting to develop our own rituals that are a blend of the two styles.
If I could start over, I would spend much more time getting to know Falcor as it exists currently, especially its style guide and patterns. I think that could have saved me a lot of time and accelerated some of our designs.
I’m also attempting to up my frequency of brainstorm sessions with both OA's and Front End engineers before starting designs, and increase the rate of post-design reviews.

I wouldn’t be a designer if I wasn’t ruthlessly critical of all of my work. This project has been a constantly iterative process, and our team continues to adjust. Here are some things we’ve learned, and I’d like to do differently.