Simon Data

2021-2022: Product design • Research • UX • UI • Design system

Simon Data is a customer data platform (CDP) that allows clients to unify customer identity, create audience segments, and set up marketing campaigns to target customers across multiple channels.

Simon Data website

Design system images

• • •

The problem

When I started working at Simon Data in 2021, a full product existed, but the design choices were not governed by a cohesive, comprehensive design system. As a startup, Simon’s main goal for many years was to build as quickly as possible, so a design system, which would have required significant upfront time and labor costs, wasn’t prioritized. In addition, since the company had low design resources, engineers and not designers made many of the actual design choices. This meant that the product didn’t consistently follow user experience best practices. For these reasons, Simon found itself with a product that had weak user experience and high inconsistency, both in build and ui. As the product expanded, so did the inconsistencies, which caused decision fatigue for designers and engineers, who were constantly trying to determine which patterns to follow. This ultimately made building much slower.

One of the company’s OKRs that year had been to: Build a sustainable and scalable business that reflects best-in-class SaaS metrics. To achieve this OKR, Simon needed to move on from building product in a quick and dirty way to streamlining and systematizing this process. Creating a design system is one of the best ways to do this. I was tasked with leading a group of designers and engineers (with the guidance of my manager) through the ideation and initial implementation of this new design system.

• • •

Where to begin?

I’m certainly not the first to say that creating a design system from scratch is HARD. Especially when you haven’t done it before, the process can feel extremely directionless, and it’s hard to know where to invest your efforts and in what order to go about things. This was an exploratory process and this casestudy is intended to emphasize the main decisions and pivot points that got us to our goal. There were also steps in the process which, upon looking back, weren’t necessary or had less impact than expected. However, I’ve still included these in the casestudy to give a full sense of what was done.

I initially started by reading lots of articles on how to create a design system and studying best-in-class design systems published by other companies, like Mailchimp, Shopify, and Uber. My hope was to find some kind of solidified process to follow. However, I quickly learned that no two design system projects are the same, and that in many ways, the particular needs of your company dictate the best process to follow. While I took inspiration from my reading, I recognized that there was no one prescriptive path, and we had to just jump in and make sense of what to do next as we went along.

• • •

The current state of things

We started with a visual audit of our entire product to get a better sense of the breadth of inconsistencies that we were working with. Our full design team worked together to document every component variation in our product. We weren’t very surprised that we found quite a few. Below are some examples of the inconsistencies we found in button styles and colors:

Image of audit showing wide variety of button types used.

Image of audit showing wide variety of colors used.

• • •

Talking it out

I then interviewed five engineers at Simon (most of whom specialized in frontend) to understand their current perceptions of building product at Simon and what they would need from a new design system. I used the following questions to guide the conversation:

• What is your experience with design systems?

  • Have you used one previously?

  • Thoughts, feelings, comments?

• What problems are you experiencing now with how you’re required to build things?

• How would you advise we go about implementing a design system?

  • Library versus starting from scratch?

    • Which library? Why?

    • How could we go about evaluating libraries?

• What are some things you need from a design system?

• How do you think we could maintain a design system?

  • What does that look like? What tools would you want to use?

• In your opinion, what are the biggest challenges we face?

  • What percentage of components do we already have? What can we reuse?

After transcribing the interviews, I wrote up the following analysis:

1. Material UI isn’t working.

• Most of the engineers interviewed were frustrated with Material UI (which they had been using for the past year) and thought that it wasn’t the best choice for us.

• Material UI is too robust for our needs, and it’s generally harder to remove things than add them.

2. We should use a library, but one that falls somewhere in the middle of the spectrum would be best.

• Most engineers recommended a library that would fall somewhere in the middle of the spectrum in terms of how robust it is.

• Ideally, it’d be something that included most of the behaviors but was more open in terms of the visual design.

• We don’t need to pick one library to fit everything. We can take different components from different libraries.

• Most agreed that starting completely from scratch wouldn’t be worth it because building out the behaviors would be so hard.

• Libraries that were named: Reach UI, Chakra, Kendo, and Facebook Open Source React.

3. We should build the design system iteratively.

• We should build one component at a time and push it through. It doesn’t need to be all or nothing.

• • •

Getting principled

After sharing my interview findings with the team, we determined that in order to make foundational decisions about the things that came up in the interviews (like whether or not to use an existing library), we needed to define a set of principles. These principles would ideally guide us to make the best decisions for our particular needs. Defining principles was also a common practice amongst the design systems I studied.

Somewhat coincidentally, our design team had recently defined some guiding product design principles, which I used to help shape our design system principles. The product design principles are below:

The design team’s product design principles.

After some team discussions and a few iterations, I wrote the following final principles for our design system with examples for how they might come into play:

1. Self-explanatory in design and build

Our goal is to create a design system and complementary documentation that requires no further explanation. We are a small company that needs to build and ship quickly. Our design system should facilitate efficiency through a high level of clarity.

• Ex: A team that does not currently have access to a designer needs to make some small UI changes. The design system should be clear enough that the developers and product managers can make these decisions without a dedicated design resource. 

2. Clarity even over simplicity

We work on a highly technical product where users can be easily confused. We should always aim for simplicity, but in some areas of our product, there is a certain level of complexity that cannot or should not be abstracted away. Our design system should support communicating these complex ideas in the clearest way possible.

• Ex: A design might look more elegant with less text, fewer error states, etc., but we should err on the side of over communicating even if that makes the design less visually appealing.

3. Flexible with an eye towards the future

Simon is a startup in an industry with lots of opportunity to build entirely new features and products. Our design system should take this into consideration and be flexible and open enough to accommodate many changes and additions in the near future. 

• Ex: When Journeys 2 was created, it had more robust functionality that required many new design elements not needed for Journeys 1.

4. Make exactly what we need

We can (and should!) use outside libraries and tools, but only insofar as they help us achieve exactly what we need. We should never choose resources that may cut corners in the short term but will cause headaches in the long run.

• Ex: Material UI was too robust for what we required and caused a lot of development to take more time than necessary. We will only choose tools and resources in the future that help us build exactly what we need and not more.

• • •

Finding alignment

Once we had our principles defined, I conducted a series of workshops with the team to discuss pain points and align on goals for the design system, which would hopefully lead us to clearly defined tasks. At this point, it was still unclear what to actually begin doing. Before we began any sort of project, we wanted to make sure that anything we did was in service of agreed-upon goals. Below is one of the mind maps we created around existing pain points:

Mind map of current pain points.

Our mind map helped us organize our ideas into the following main categories. I then drafted a set of goals for what achieving success in each of those categories would look like:

• • •

Writing our OKRs

Though we now had a draft of our design system goals, this didn’t include how they’d be specifically defined or measured. It also didn’t include any sense of timeline. For this reason, we decided to write OKRs, which would help us understand exactly what completing our goals would look like. Since OKRs can be deceptively simple, I researched best practices and created a deck to share them with the team:

After some discussion and iteration, the following are the OKRs I wrote for the first quarter of 2022:

• • •

Setting the stage

Now that we had our OKRs, we had to figure out a way to actually accomplish them. We landed on the idea of completing a pilot project. We believed a pilot project would help us develop an iterative process that could eventually be applied to the entire design system. It could also provide a tangible proof of concept to stakeholders to get more resources when we were ready to complete the rest of the system.

The pilot project would consist of designing and implementing one component, along with documenting it and determining how to change old versions throughout our application. All of these goals were encompassed in our OKRs.

We had a number of big decisions to make, including what component to even build. The following are the questions I brought to the team along with my notes to begin our pilot project:

In our discussion of these questions, we decided that our first component would be a button. Simon’s button is simple in both behavior and visual design, so it would be something easy to start with. However, it was also far reaching and existed on almost every page of our application. The button component had the potential to be used by almost any engineer building a new feature, which could be ideal if we wanted many people to use the new design system right away. The button also gave us the opportunity to expand into secondary components, since it had a few variations, which we might decide to explore in this phase as well.

• • •

Off to the races

After months of preparation, we were finally ready to begin work on our first component. We got the design system project prioritized to get assigned engineering resources for the first quarter. Below is the project canvas for our pilot project :

Design system project canvas for Q1.

The first order of business was to consider all of the elements involved in building our button. I worked with an engineer on the team to produce the following proposal:

Button elements proposal.

Meanwhile, another designer/engineer pair produced the following proposal for the accessibility requirements:

Accessibility proposal prepared by another designer and engineer.

• • •

Making tokens

Now that we had a list of the elements we needed to define for our button, we had to figure out how to organize them. Something that had come up early and frequently in our discussions was using design tokens.

Design tokens are all the values needed to construct and maintain a design system — spacing, color, typography, object styles, animation, etc. — represented as data. ~ Adobe

Essentially, a token can represent anything defined by design (ex: color, sizes, etc). They work well for design systems because they constitute a controlled set of choices and patterns that designers and engineers can use when building product.

At this point in the process, we felt ready to begin actually defining our tokens. One of the engineers led this process and introduced us to some great tools. One he showed us was Amazon’s style dictionary, which uses a hierarchical tree structure to define its tokens. We used this as inspiration to structure our own tokens:

An example of the hierarchical tree structure we used from Amazon’s style dictionary.

• • •

Getting visual

Defining tokens gave us the opportunity to hold a microscope to our existing visual design and reconsider it, which was one reason the design team wanted to create a new design system in the first place.

There were many visual design elements in Simon’s product that didn’t follow best practices and no longer served us. Some of these elements were directly pulled from branding materials intended for print that didn’t translate well to web. This was true of both the fonts and colors.

I did some tree diagrams to help us visualize the tokens for our own button. Here’s the one I did for the color category:

The other tool we took a lot of inspiration from was Tailwind, which has a very clearly defined design system structure. We borrowed from their naming conventions and categories.

• • •

Fonts

The font used currently in Simon’s product was Brandon Text, which is commonly used in print, on things like posters and shop windows. Though Brandon is fairly common on the web as well, it works best for larger titles and featured text. Since our product is data-focused, requiring little featured text, Brandon wasn’t the best choice. We needed something intended to be used at very small sizes for things like data tables.

Use of Brandon Text for featured text on Nordstrom’s website.

In order to find a font (or fonts!) that would work best for our purposes, I did a decent amount of research. I wasn’t particularly familiar with all of the elements to consider when choosing a font, so I looked to blogs like Pimp my Type and Web Typography.

I ended up choosing different fonts for the body text and the titles because the necessities for each purpose were so disparate that a single font didn’t work. For a body font, I wanted something that was highly legible at very small sizes because many pages in our app included lots of text (much of it numerical), and users needed to take in lots of information at once. However, when using the fonts that worked well for body text for titles, they simply didn’t look interesting or opinionated enough. The application just felt stale. Choosing two different fonts for the body text and titles was the best solution to this.

I went with Sofia Pro for the titles font. I wanted something that felt modern and sharp that communicated that Simon is a high-end technology product on the forefront of innovation. I did some testing comparing many fonts: looking at the full character set, using them in the titles of our pages, and pairing them with possible body text fonts.

The font tests I completed.

Choosing the body text font took a lot more work. The main goal was to find something highly legible at small sizes. I considered things like open apertures, x-height, even-spacing, and clear terminals.

Diagram example of how to evaluate open apertures.

I tried many different options, looking at them in our current app on multiple pages using the browser developer tools. A final consideration was that I didn’t want a font that was overused (such as Roboto) so that our product’s visual identity would feel unique. Ultimately, I landed on Magnum Sans. Magnum sans was highly legible at small sizes, not overused, and it paired well with Sofia Pro. The fonts had similar letter forms (such as single-story g’s), angles, and widths to compliment each other, but there was enough contrast to make the pair feel interesting (such as the shape of the a’s and t’s).

Sofia Pro (title) paired with Magnum Sans (body text).

• • •

Colors

Simon’s current color palette was worth re-examining as well. Simon had undergone a rebrand relatively recently, and though that branding worked well, the colors for the web app were taken directly from what was intended for print. This was particularly a problem for Simon’s purple color, which looked too muted and flat in the app.

A screenshot of the app showing a muted purple color for the navigation, text, and button.

I did different tests with elements in our app and came up with a color set for the purple that was much more vibrant:

Final purple color set for design system. 800 will be used as the brand color.

Color test on the navigation.

Simon’s pink color was also creating problems, not because it was too muted, but because it was being overused. The pink was used to represent the brand, like in Simon’s logo, but also to signify interactivity. This created problems for users, as it wasn’t explicitly clear what was clickable, as branding uses of the color weren’t interactive. Also, using the pink color for text, which we did for links, didn’t pass accessibility standards for legibility.

We determined that we should introduce a new color for interactivity and use pink strictly for branding. We were inspired to use a saturated blue, which is historically the most common color for interactivity and also commonly used by larger companies. Blue also worked well with our brand colors.

Use of saturated blue for links and buttons on Google’s webpage.

I tired different blue colors in our current app using developer tools and then defined new pink and blue shades for our design system:

A test looking at the new blue color in our app.

Newly defined pink color (used only for branding) and blue color (used only for interactivity).

• • •

Naming

Part of building our token system was figuring out how to name everything. It was important to make sure all of the elements we defined were understandable for both engineers and designers. The following was our process for figuring out how to name colors.

There are a number of different conventions for color, one of which is to give colors unique names. This helps reduce confusion if you have many colors that are similar (i.e. grape and violet vs. purple 1 and purple 2).

Example of using unique names for similar colors from Mailchimp’s design system.

However, Simon didn’t have that many colors in its palette (i.e. there weren’t multiple versions of purple), so that method seemed heavy-handed. The other option was to name colors by their purpose; for example, a green color would be called “success”, or a red color would be called “error.” This, however, felt too distanced from the color itself. It felt uncomfortable to refer to a color only by its purpose instead of its actual hue. After much discussion, we opted for a version that combined purpose and hue, referring to the hues with basic names, such as “brand-purple,” “interact-blue,” and “warning-yellow.”

To define the shades within each hue, we adopted Tailwind’s practice of using numbers from 50-900. This gave us a clear way to communicate saturation that was consistent with every hue. It also left room to add colors if necessary (i.e., a color between shades 200 and 300 could be called 250).

Our notification colors showing our purpose-hue naming system with numerical shades.

• • •

The button

After defining our tokens, we were finally ready to design our button. I designed the following in Figma, while an engineer built the prototypes:

The new button states I designed for the design system.

• • •

What next?

Now that we had officially completed and documented our button, we weren’t sure what to do next. We had met most of the OKRs we set out for the quarter, but after many conversations with engineers, we had to pivot away from replacing the button the current product. The project was more complicated than we anticipated and we didn’t have enough engineering resources right now.

We wanted to keep working on the tokens, but when I started working on this with an engineer, we realized that building tokens outside of the context of the product led to arbitrary choices. It was hard to say exactly whether we wanted spaces in units of 20 or 22, for example, since we weren’t able to see what worked best across the entire product. We felt like we needed to make more components or work on actual pages to make the best token system for our product.

We brought this to the team and decided to brainstorm about what would be the next best step:

Our brainstorming board for best next steps.

• • •

A redesign

After discussion, we determine the the best next step was to redesign a section of our application and build the components we needed as we went. We decided to do the Settings section of Simon, since the pages were simple but many different components were required, like input fields, checkboxes, and radio buttons.

The design team worked together to design all of the pages in the Settings section, making necessary UX changes in addition to UI changes. Together, we added components to the design system and redesigned the following:

Redesign of the Settings section by the design team.

• • •

Building

From the beginning of the project, we knew that it would be difficult to get resourcing to build the design system. It was a complex project that would take a long time to get off the ground, and it would be hard to prioritize with all of the other pressing features Simon needed to build. In fall 2022, we saw an opportunity with our yearly hackaton. We decided to use it to build the newly designed Settings section. We also saw the sharing portion as a great way to evangelize the design system to the rest of the company and show what a powerful and efficient tool it could be.

The hackaton took place over three days, and 3 engineers were able to easily build the entire Settings section. So much so, that I ended up redesigning another page of the app that they also completed. The engineers compared lines of code for the previously built settings pages to the ones they built with the design system and determined that lines of code were reduced by 30x. Anecdotally, they also said that building was far easier and pages that would usually take them a few days now took about an hour.

Simon’s Flow Details page I redesigned.

Simon’s original Flow Details page.

• • •

Final thoughts

This was a long project that took a very non-linear path. However, I do feel confident with where we ended up. Using the design system myself and watching engineers build so quickly, I do think we were able to significantly reduce decision fatigue and help Simon achieve its OKR of building a sustainable and scalable business that reflects best-in-class SaaS metrics.

Moving forward, the biggest challenge I see is finding a way to strategically transition over the full application. Significant thought should be put towards determining whether to complete the project all at once or in sections. Ideally, the transition would also be seen as an opportunity not just to reimplement what currently exists, but to create a better user experience across the product, both in terms of the user interface and overall architecture.