Blue Cross Blue Shield of Michigan

I was a user experience designer on the team that redesigned and built the BCBSM (Blue Cross Blue Shield of Michigan) retail and member web portals from the ground up.

Overview

Both of these were extensive projects that took over a year to complete and involved incredible dedication and communication. The work took place in the shadow of Health Care Reform, which meant that we had to understand and communicate new ideas about health insurance in a way that was easy to understand.

I faced many personal challenges and developed tremendously as a designer working on these projects.

Roles & Responsibilities

I was a full-stack designer throughout the course of this project. My roles included:

Participating in Stakeholder Workshops

BCBSM is a massive organization that has as many experts in it at there are complications surrounding health insurance itself.

Domain Research

The health insurance domain is so vast and complicated that the process of mastering and documenting the information went on throughout the course of the engagement. Every time I thought I knew something it got more complicated, and new laws were being passed all the time that changed the game.

Creating Extensive Annotated Wireframes

Creating the wireframes was the least pleasant aspects of this whole project. Static wireframes are sometimes a bit of an antiquated deliverable, but it they were necessary due to the the makeup of our team and the size of the BCBSM organization. A lot of money was being spent and we had to make communication tools to ensure that thousands of people were on the same page about the product requirements.

In the end, I participated in the creation, annotation and maintenance of over 500 unique wireframes that captured the many possible states and nuances within the applications. Brutal.

Defining HTML/CSS Components

The websites were maintained with the Adobe CMS, and it was my job to take our wireframes and restructure them so they were made of re-usable components. I had to consider many things, including:

• Which parts of our designs can be adapted to fit within existing CMS components?
• Which parts of our designs are important enough to justify the development of custom components?
• How do we create a system that can be maintained by the BCBSM organization without experiencing decay in the quality of the product over time?
• What is the best way to pass this information to their on-site developers? (I ended up writing the HTML and CSS for the components myself and passing that along.)

Developing Prototypes for User Testing

In the earliest stages of the project, our team did a lot of paper prototyping. To test the member portal we had to create a high fidelity, data-backed prototype. We used iRise to create the prototype and generated fake insurance claims data for three different personas that we wanted to test.

Over the course of the project I observed over 40 hours of one-on-one user testing sessions using prototypes that I helped design and build. We used that information to make the products better.

Assisting with Front-End Development

I was the only member of our team with true front-end skills, which meant that I was ideally suited to write the code snippets for the pattern library and also write the HTML and CSS styles for some of our key design pieces.

Knowing that I had some of the responsibilities waiting for me down the development road, I started building some of the wireframes in HTML from the very beginning. They started out as gray boxes that I presented to the client on trips to Michigan and grew into fully-designed and coded user interfaces that could be handed directly to full-time developers for refinement and release.

What Did I Learn?

This was the first enterprise-level project I worked on, and still the biggest product release I’ve been a part of to date. I learned a lot:

• When you commit to making static wireframes, you commit to maintaining the wireframes and annotations for the duration of the project. You spend massive amounts of time simply maintaining and re-publishing documentation.
• It’s okay to not be an expert on the domain. I spent too much time feeling self-conscious about not knowing as much as the client did about insurance. In reality, how could I ever be expected to know as much as a person who makes health insurance their full-time job? My job is to be a design expert and ask lots of questions. It’s okay not to know everything.
• We should have thought more about the CMS in the beginning of the project. I ended up having to go back and break things into components after too much design work had been done. It would have been better to work with components in mind along the way.
• At any given time, you might be surprised by having to present to executives in the company. Now I’d prefer to know, but back then I’m kind of glad I didn’t know. It would have made me more nervous.
• You’re never going to get things perfect. Maybe the toughest part of this project was the changing nature of the health insurance landscape, as well as the sheer depth of the information. Every time I thought I had nailed a part of the interface down, someone from BCBSM would see it and point out something very important that was missing. That bothered me a lot but now I accept that there’s not really any good way to control that. The best thing you can do is creative a process that is optimized for the game-changing things that you learn along the way.
• Insurance is kind of boring, but so are a lot of things. If I ever got tired of working on insurance problems for so long, it was helpful to remember that these are not actually insurance problems. They’re people problems, and I was solving problems that would make their lives easier.