Premera Blue Cross, Mobile & Emerging Technologies
2018-2020
Researcher, UX Designer, and UI Designer
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.
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.
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?
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.
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.
.gif)
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.
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.
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.
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.
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.
Successes:
A few areas for improvement:
