Case study: Emissary Design System


Title: Product Designer
Location: Remote / New York City
Dates: Winter 2021 - Present
Until I joined in 2021, Emissary lacked any formalized design system. Several products existed for our clients, for our advisors, and for our internal customer support users. There was no cohesion of the users’ product experience with the established brand guidelines on our marketing materials and other external collateral. At the onset of a thorough overhaul of the digital product offerings, it was critical that a design system was created to support a cohesive and user-friendly suite of products.

Initial findings from design audit

  • No centralized standards set for user behavior patterns
  • No guidelines for component implementation
  • Duplication of common components
  • Poor visual language and hierarchy
  • Inconsistencies between web applications, marketing website, and brand collateral

Fig. 1 Product during design audit (2021)

Material UI Library

The product had been built using an out-of-the-box Material UI React+ Kit, which for ease of transition we decided to retain, but style with Emissary-appropriate branding.

Laying the foundation

The typography and colors for the product design system were adapted from our brand guidelines and assessed for accessibility in a digital setting.

Fig. 2 Typography guidelines


Fig.3 Color system


Fig.4 Iconography

Figma file

As I am the only designer (at this point) for Emissary, it was easy for me to structure my design file the way I understood it. But since we were starting our design system from the ground up, it was important for me to keep things as simple as possible so as to not introduce unnecessary complexity into the way our users interact with and experience the product.

The Figma file employs the following structure:

  • First, a cover page introduces the component and the potential types of the component (i.e. primary vs. secondary buttons).
  • Next, there is a page with more detailed guidelines about how a component is used within a design, and how it is implemented in code.
  • Then, a more technical space where design specifications are laid out, including interaction states, spacing relative to other components, sizing, and other relevant details.
  • Lastly, the section that contains all of the base components that comprise a component type.

For example, here are those four pages for the Buttons component.


Fig. 5 Button introduction & types


Fig. 6 Button guidelines


Fig. 7 Button specifications


Fig. 8 Button base components

Building out the Design System

I was able to start with a Material design file which provided the basic outlines for the components needed, but in order to build a design system that fits the needs of our users I needed to observe the way our clients interact with our product, become familiar with other digital experiences they might be used to, and familiarize myself with the key problems they needed to solve with our tool.

Fig. 9 Figma file

Building components in code


Based on my designs I could then create Engineering tickets to build out the component to my specifications. Using the documentation in Figma the engineers then code the style changes and I do QA on the ticket.