Now it was time to try and tackle the totally subjective world of color! Having gone through this exercise a few times in Collective's past, I knew it would be full of opinions and feelings, and might be tricky to come to a consensus.
Time for Color
We started off by doing an analysis of the palettes of our biggest competitors, as well as other design-giants in tech. You can see that blues and greens are common in health care, and while Oscar and Alex are doing blue differently, we wanted to try to stay away from it as a primary, but still differentiating our palette from Airbnb.
Next we exploded with ideas and options, and refined over the next few weeks with frequent input from stakeholders and the larger design team.
Eventually we ended up pulling the best of all palettes and harmonizing the colors to end up with what I lovingly refer to as the Ultimate Everything palette.
Collective Health's first Design Language System
Create a functional and beautiful system that follows our design principles and scales across all products and touchpoints over time.
Collective Health was branded in the middle of a huge growth period and strict customer deadlines. This meant that we had to try to define our brand as we rushed to build our products, which resulted in a lot of inconsistency and design debt. Creating a design system was a chance for us to revisit our design principles and mission and make sure our products were embodying those values in their design.
This project is still running, but I was a part of the team full-time for only the first quarter of 2017. I remain involved, but am now contributing from the Claims team on the internal product language.
Develop a strong design language that enables CH to create a cohesive and consistent user experience across all touchpoints
Accelerate the product development process for design and development
Establish a language so designers can focus on creative solutions for complex problems rather than pixel precision
Evolve and extend our existing brand to further differentiate us in the market
Presentations to stakeholders
Collaboration with Engineering & Design
Front End Engineers
With one of the main goals being cohesion between our values and our products, it was important to consider what existed before beginning.
Lots of work had recently been put in to defining our design values. The Brand & Marketing team had just done their values, and Product Design had just completed theirs. Though we were only working on a system for Product, keeping a cohesive member journey was vital.
Setting our Target
With our values and principles in mind, we reviewed our member journey and all touchpoints involved to see what was and wasn't working.
We compiled as many examples as we could think of and held a session with the Brand Director, Design Director, and all members of the team to get us talking about what gaps this system needed to fill and where we needed to scale back.
Evaluating Where We've Been
Through discussion and analysis, two distinct directions began to surface, so we decided to pursue both.
The Fun Begins
We did three revisions of moodboards for each direction, and measured them against the brand values.
We taped up mood boards everywhere and got to sketching and collaborating, then hit the computers to start to play with the extremes.
We then had multiple sessions with stakeholders to pick what was working best and keep pushing it.
THE FINAL DIRECTION
As with so many design projects and exploration variations, we eventually came to the conclusion that Collective Health shouldn't be in one extreme, and shouldn't be in the middle. Our products could be both nurturing and strong, simultaneously.
Try to ignore the color in this one; we were trying to hold off on that for the style studies. Color here is meant to show how and where it could be used only.
With the style direction down, we moved on to stress-testing the styles on a few key screens of the member-facing product.
Although Collective Health has three different product domains, we needed to start with Member, as it is the biggest and most public-facing.
We may have gone a little over-the-top for starters, but the exercise helped front end and design to get on the same page and consider how we would start to phase out these changes in a way that would cause the least disturbance to users.
Documentation may seem pretty straightforward, but we wanted to work closely with Engineering to make sure we were giving them the right information that would lend itself to several easy-as-possible rollouts.
Where we are today
I got moved to the internal-products team, known as Admin, and have been using the opportunity of creating a new portion of the product to both test and evolve DLS for Falcor. You could say it's my cherished little side-project.
After the first quarter of the project, the Dev org had a huge shakeup and resources were shifted around. The DLS team has had a few different contractors since then and has continued to evolve the system.
Engineering involvement – A huge part of this project was and is the engineering side of the equation, which in my opinion had far too little representation and involvement from the beginning. To this day there is still lack of communication between engineers implementing the system across different products, but our team is trying to address that from the ground-up.
Team buy-in – When the project was forming, it was positioned to the larger design team, as well as engineering, to be a refine-and-systemitize-only project. When we started diving into the world of re-design, people were frustrated and wanted their opinions heard. If I could do it over, I would have set clear expectations from the beginning and asked who wanted to be involved more closely. Running more brainstorming workshops with those interested would have helped with co-ownership and would have created stronger, more scalable results.
Not enough time spent on auditing – We spent weeks and weeks refining and changing the moodboards and project goals, but when it came time to survey and test ideas, we did very little. This added to the larger team's frustration and created more re-work going forward.
The Design Language System was definitely the first of its kind at the company, and it was largely tasked with convincing C-level that it was a worthy cause and deserved resourcing. If resourcing had been less of an issue early on, things could have gone a bit smoother. Here are a few other things that I'd change if we could do it all over again: