Premera Mobile Design System

Premera’s Design practice and Mobile team was growing quickly. The UX team needed a more streamlined way to make designs, iterate on those designs, and hand them off to Developers. So I took on the task of making a consistent Mobile Design System that could be used by multiple designers on the team and that eventually streamlined our development handoff processes.

Premera Mobile Design System Hero

Team

Premera Blue Cross, Mobile & Emerging Technologies

Project Years

2018 - Current

My Role

Researcher, UX Designer, and UI Designer

Problem

Premera Mobile was at one of those pivotal moments that most teams feel as they begin to grow. Smaller teams, like SMS, Virtual Assistant, and Mobile Apps, were forming and new features were starting to make the core iOS and Android apps feel disjointed. We also knew that our apps did not meet the needs of our users with disabilities. We needed three things: a consistent set of elements for our designs, a better way to communicate these elements across teams and disciplines, and to make our experiences more accessible.

Learn

These needs aren’t particularly new and we understood that a Design System would be the ultimate solution. The real question, though, was what sort of system would we need and how could we make sure the team understood and used this system? So I began this project by researching each team member's specific needs. I created a research plan based on a process from Isaak Hayes and Donna Chan in "Building Empowering Style Guides with Practical Research”. With some small edits to help the results map to our team structure, I was able to capture much of the most important information I needed to understand the pain points the team was experiencing.

Design System Research Plan + Interview Analysis



One huge finding was how important it was for many different team members to have a say in the UI design. Product Managers, Developers, and Designers alike felt like a core piece of why they enjoyed their jobs was because of their ability to directly impact the user's experience in a project. But why was this so important to the team? And can a true Design System really support both standardization and constant changes to the visual design?

Understand

In talking with the Development team and Product Managers I found two big concerns with a standardized system. First, because the system would be generated by a Designer – me – the team was worried it would put more of a burden on the Developers while making a Designer’s job easier. Second, with our old development handoff process screens would change as future features were designed, constantly impacting the stories the Developers were already working on. Additionally, outside of the Design team there was a lack of understanding of the current design process which would need to be fixed before any system was adopted effectively. However, in our case, a Design System was the perfect avenue to establish more trust and understanding between the teams while also making our designs more usable.

App Before Design System and Accessibility Projects

Explore

Design Tools

I first started thinking about the system as it connects to the team’s design process. We had already used Sketch and InVision and security needs around Health Insurance meant we would have to wait months to get access to any new tools. So I would need an incredibly compelling reason to change tools and ultimately a reason was never found. Other tools would solve some of our problems, but would often cause problems in different areas of the process. The biggest change in our design process became stricter version control standards through Abstract and using a Sketch Library file for all of our components. However, it was still the same core process and that meant that there was very little for the Design team to learn outside of new styles and components.

Development Tools

Because our Design tools were basically the same as before, that also meant that our Development handoff tools were the same. We were using InVision Inspect and beginning to use the InVision Design System Manager (DSM), tools the developers were generally familiar with and that became the first step in establishing more trust in the system and with the team. However, there were huge holes in how these tools worked within our processes. Components and styles were beginning to be built in the Design System Manager and in our design files, but they weren’t connected to InVision Inspect. This meant that the Developers would need to check the properties in Inspect and match them to the element in DSM, an inefficient process that would break down some of the Design understanding we were trying to foster.



I don’t believe in true epiphanies, but there was one moment in this process that certainly felt like one. While talking with another designer about the problems with our tools he mentioned, “It would be great to see the styles here,'' referring to the InVision Inspect side panel. I instantly realized I could implement that and updated a few layer names to test the hypothesis. Before, layers were named something like “Title_copy 3” because we had never really needed to be stricter about our naming conventions. But changing those names to “Title/Body Semibold/Brand-3” gave so much information and value with so little additional effort.

Produce

Styling

The first real phase of implementation was to update our styles. This was especially important for accessibility, but also useful for making the apps more consistent and increasing the team’s efficiency in building UI. I started by rebuilding our color palette and typography and quickly learned just how flexible our system needed to be. I had originally defined our colors based on their use: blue should only be for actionable elements, coral only for navigation. I did the same with typography: page titles have a specific font style that is different than section titles. Both of these systems did not scale well across our apps and just caused more confusion though. So I decided to make the styles more generic so we could implement them easier and more consistently. I still knew that we needed standard styles for elements, but I understood that the team would be more likely to use these standards if they were connected to components instead of just defined in the style rules.

Premera Mobile Color Palette

Premera Mobile Typography: Android + iOS

Premera Mobile Iconography

Building Components

This phase of the project was honestly the most challenging. The team already had styling, we had already used many of the same tools both before and after the system was built. However, components were new and how to build, integrate, and communicate them was a novel problem. We tried a few processes to see which would work best. I built the first set of components with the elements we already had in our apps. The designers began to use them and the developers would use InVision Inspect in the same way, but didn't have access to any of the component attributes to build the UI. This quickly resulted in inconsistent UI across features though and ultimately didn’t work.



The most straightforward solution was to meet more frequently with the developers. This did help get the developers excited about including new elements, but it did not increase usage of components because these elements weren’t truly in a system. This is where abandoning the Design System Manager really hurt the implementation of the complete Design System, but I also knew moving back to DSM wasn’t a good option because of the low adoption previously. So I decided to try documenting our principles in our team-wide documentation tool, Confluence. The tool wasn’t built to specifically hold a full system, but maybe identifying our principles and core components would be helpful.

Principles and Documentation

It turns out this was the perfect solution for the team in our current state. An introduction to components through buttons, links, and inputs was the best way to make sure we are making elements that need to be obviously consistent. Principles about spacing, icon design, and content were very effective at both communicating our design decisions as well as keeping the Design team honest about our decision-making. This is also where governance became, and I cannot stress this enough, the catalyst for building a real system that all team members contributed to.



A lot of the visual design had grown quickly with the growth of the system, partly for increased accessibility and partly because we wanted to make our brand more consistent across platforms. With this, the other Designers wanted more agency in the process of creating components and we set up a regular meeting to discuss how we can build out the Design System more effectively. This was huge because I knew I could create components 8 hours a day, but if Designers weren’t interested in using the components it was a pointless pursuit. The team saw the value of the System and wanted to help make it better.

Results

And that brings us to the Design Systems current state. I’m meeting with the Designers and Developers to define components that are easily scalable across both iOS and Android. Components are constantly being revisited and the entire UX team from Design to Content to Research is involved in the process of building out the System. Admittedly though, because I’m still owning this system, it’s much too design focused. I meet with Developers as often as possible, but without dedicated resources it is difficult to gain buy-in on any components outside of the UX team. That’s my next task, bringing a Developer onto the team and moving the system into a place where it can truly help all members of the team do better work.

Reflection

Our successes:

  1. 1. Creating more standardized and consistent patterns for mobile app users.
  2. 2. Making our apps more accessible and increasing usability.
  3. 3. Streamlining the Design and Development handoff process.
  4. 4. Adding more intentionality to our design patterns.

A few areas for improvement:

  1. 1. I should have proven the importance and value of a Design System earlier on.
  2. 2. Developers needed to be involved earlier in the process.
  3. 3. I should have communicated how components are built sooner to the Designers.
  4. 4. I need more patience in implementing the system. Regardless of how much buzz there is around Design Systems, teams are slow to adopt them.