Zest, a Design System
A design language for the next generation of the Mirth Product Platform. The efforts of Zest resulted in a new UI Framework, cross-product design patterns and brand guidelines, usability principles, and a cross-functional team structure.

Design Challenge

Mirth was putting a tremendous effort in rebranding all their applications. They had 6 existing applications at the time, and there were more applications planned for the future. Management approached the design team with their concern that these applications didn’t look like they were from the same company. They wanted to take this opportunity to rebrand and make these applications look and feel like they were from the same family. The design team realized a need for a design language - a language that would guide the design and architecture of all these applications to ultimately create the Mirth Platform.

Creating a Shared Basis of Knowledge

The first thing we did was get all the product owners of each application in one room and we started asking questions. We wanted to understand what these applications did. Who were the users? What were they try to do within each applications? What value was the product providing them? From there we started defining use cases and job personas. This provided useful later on because it really gave us a shared basis of knowledge for decision-making.

Spreading the Zest

We wanted everyone to start talking about this new design language. We wanted to get everyone on board with it because ultimately it would be the product owners, management, developers, other designers using this design language. We called it Zest. The Zest design language. The name stuck. Before we knew it everyone was talking about Zest.

Growing Pains

We started out documenting all the design patterns and interactions on a google document. We knew this wouldn’t scale but we had to start somewhere. We documented design patterns and design rationale, defined interactions in detail, and defined page layouts, colors, fonts, and typography. This Google Doc was editable only by the design team but was accessible to everyone in the company.

Pretty soon we had people all over the company viewing this Google Doc and coming to us with their design dilemmas asking us how the Zest framework would solve these problems.The time had come to create a living style guide - a place for this language to live and grow and be maintained.

A Living Style Guide

This living style guide would be have to be maintained by the front-end developers so that the documentation would stay up to date with the code. So as a proof of concept I created a living style guide that would generate documentation from comments within the code - both CSS and Angular components. I presented this to the developers and they were excited to build this out knowing the value it would provide them in the future.

A Change in the Organization Structure

As more and more teams started using the Zest framework we also changed the organization structure within the team. There would be one UX designer assigned to each team. This designer would also be part of a bigger design team with a UX lead. This created an interesting tension because each designer had two leads - a product manager for the application as well as the UX lead of the bigger design team. I was in charge of design and UX for two of the applications. The bigger design team would then meet twice a week going over what we did within our application teams to maintain the quality, respect the design guidelines, and document any additional changes to the Zest framework.

I'm a strong believer that design should be prevalent throughout the company and baked into every decision. It shouldn’t just be up to the UX team to think about creating the best possible user experience. All team members -product owners, developers, marketing - should be thinking about the user. Being in charge of design within a team allowed me to work closely with these different roles. I taught developers to wireframe, create affinity diagrams, and even conduct usability tests. At this point, developers were willing to spend extra time on a particular interaction because they were invested in the design.


My team was constantly pushing for feedback from real users to be able to iterate and improve upon the components and various features we had designed. We didn’t have the time or resources to conduct user research out in the field so we worked with the product team to reach out to our users and conduct remote usability tests to ensure that 1.) we were building the right product and 2.) we were building the product right. I prototyped interactions using Invision click-throughs and conducted remote usability tests using LiveShare.

Lessons Learned

It’s important to expose team members to users- this results in a better team dynamic because it allows the whole team to build empathy for the users.

Designing requires collaboration. Designers needs to be able to understand the motivation of those we work with. Engineers, PMs, and other designers all come with their own particular needs and goals.

Invest the time in creating a shared basis of knowledge. A design project is simply a series of decisions - The time we spend on a project is greatly dependent on the speed of decision-making. Differences in individual perspectives often creates for a negative dynamic and results in time-wasting arguments. Research and exposure to users for all team members grounds decisions in evidence rather than sheer authority and preferences.

Be open to change. Designing something significant and meaningful requires team members to embrace change. We're not just redesigning the product, we're redesigning the process, the meeting, the organization structure, and the way we all work with each other to create a better product.