Simon Data

2021-2023: 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

• • •

Overview

The wild west

When I first started working at Simon Data, a full product existed, but there was no real design system. As designers, we had some Figma components to work with, but they weren’t governed by any foundational principles, and there were no rules around adding new ones. The process of using these components and figuring out which patterns to follow was laborious and frustrating.

Engineers were left even more in the lurch. There were no companion engineering components for the ones in Figma. The engineers were generally using Material UI, whereby they would adapt the components to our designs, but this was leading to lots of issues.

I experienced these issues personally when I designed my first project and handed it off to engineering. A fairly simple page that I expected to take less than a week ended up taking nearly three. When I checked in with the engineer, he explained to me that what was requiring so much time was all of the elements from Material UI he had to remove. Material UI had many extra features built in that had to be stripped away to recreate a fairly simple design. Even after the build was completed, we went through multiple rounds of QA to make the visual design accurate, changing things like shadows and rounded corners that were never in the design to begin with.

Having previously worked at companies with a design system, I knew that this process was far more inefficient than it could be. I brought the idea of looking into building a design system to my manager and proposed that, if we committed to it, I would lead the project.

THE PROBLEM

• • •

RESEARCH + EVALUATION

Making an argument

I first went to engineering leadership to discuss the prospect of building a design system. They weren’t really aware of the problems I brought up, and even still, they didn’t think that they were bad enough to warrant building an entirely new design system. Their argument was essentially: We don’t need a design system because we already have one: Material UI. It’s not perfect, but it’s good enough for what we need. I didn’t agree, but in their defense, my personal gripes probably weren’t enough to make a convincing argument for such a huge overhaul 😉.

• • •

A look under the hood…

In order to present a better argument and get a full picture of the state of our current process, I decided to do research. Essentially, I wanted to understand: how big of a problem is this? Are my coworkers finding this as frustrating and laborious as I was? But beyond the difficulty for employees, what is the effect on the health of the entire product and business? I knew that not having a clear, cohesive design system could negatively impact the product, and I wanted understand what that impact was.

I interviewed 5 engineers and 2 designers at Simon. The following are the major takeaways from my conversations:

1. The pain is REAL and pervasive.

I wasn’t the only one feeling the pain of our current process. Everyone I interviewed across design and engineering felt that our process was laborious and time-intensive. They unanimously agreed that having a real design system would save them a ton of time and headache compared to the process we have now.

2. Material UI is too robust for our product and is the source of this pain.

The choice to use Material UI as an out-of-the-box design system was intended to make things easy, but the opposite is true. None of the engineers I interviewed liked this solution. They said it was far too robust and that every component they used required a lot of work to change, making building very slow. Most said that if we did end up using another library, we should pick one that was more flexible and offered components closer to our needs.

3. The current process incentivizes decentralization and inconsistency.

Because we don’t have a clear, consistent process, engineers are incentivized to make their own components instead of using ones other engineers built because they could cause their apps to break. Then, because everyone is making their own components from Material UI, they’re changing them differently and separately, which is making the product highly inconsistent in build and visual design.

• • •

The big picture

After conducting research, I felt like I had a better sense of what the bigger picture was: Even though Material UI is our “design system” it’s actually doing the opposite of what a design system is supposed to. A design system should make things painless, quick, and consistent, and our process was painful, time-intensive, and inconsistent.

Leadership didn’t know how Material UI was being used and the effect that was having on the product. The third point about the decentralization and inconsistency of the product felt meaningful to extrapolate on, because it had strong implications for the health of the product and business. 

Basically, we had an ever-expanding problem. The longer we kept going with the process the more inconsistent and unwieldy the product would be, as everyone would be continuing to make changes differently and separately. An inconsistent product is very, very difficult to manage. With every page built differently, it would be an enormous task to ever change anything across the product. Even something as simple as a color change if the company wanted to rebrand would be an enormous task.

And this wasn’t just an under-the-hood problem. This problem was exposed to customers because our current process was also making the product visually inconsistent. The other designers and I did a visual audit of our entire product, and it confirmed what the engineers were saying: the inconsistency was bleeding into the visual design as well. We found visual inconsistencies in every component in the product.

Image of audit showing the inconsistencies in color.

Image of audit showing the visual inconsistencies in buttons.

• • •

Business considerations

Though I now knew this was a big problem, it was still worth considering whether a design system project made sense for the company. Building a design system is really effortful and committing to one would take resources away from things like new features, so the investment should align with current business goals.

At the start of the year, leadership had set company-wide OKRs, many of which centered around the long-term viability of the business. Even though Simon Data was technically a startup, leadership was signaling with these new OKRs that they intended to move from taking shortcuts to focusing on sustainability. One of these OKRs was to: Build a sustainable and scalable business that reflects best-in-class SaaS metrics. A design system serves this OKR well because, fundamentally, we cannot have a sustainable and scalable business without a legitimate design system. All best-in-class SaaS companies have design systems.

Armed with the research in the context these business goals, I went back to leadership. We got approval to do the design system, but they determined that this would be a design-led project and we’d have to advocate for engineering resources down the line when the project was more specced out.

• • •

PLANNING

Laying the groundwork

Having never built a new design system before, I wasn’t exactly sure where to start. Initially, I read “how to” articles on creating a design system and studied 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, your company’s particular needs dictate the best process to follow. While I took inspiration from my reading, I recognized that there wasn’t a prescriptive path to follow.

I determined that we should approach this project as an exploratory process, which meant that instead of deciding every single step beforehand, we’d jump in and determine each next best step as we went along. 

However, this did not mean we wouldn’t be deliberate in our choices. The big takeaway from my research was that shortcuts led us to our current messy situation. We knew what we would end up with if we weren’t deliberate, so our mantra became: make decisions deliberately and make exactly what we need.

The goal was to make a design system that eliminated inconsistency and increased production time.

• • •

Principles

Once the design system project was approved, I began holding weekly meetings where we could brainstorm and collaborate to move through the process. Since we didn’t have engineering resources allocated, the engineers who were invested in the project joined us voluntarily.

From our discussions, we determined the first best step would be to create a set of principles for the design system. In keeping with our mantra to “Make exactly what we need,” the hope was that these would guide us to make the best decisions for our particular company. Defining principles was also a common practice amongst the design systems I studied.

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:

• • •

Goals

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. A design system should solve actual problems, and we wanted to make sure we understood what those were before building anything. 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:

• • •

PROCESS

A pilot project

Now that we had laid the groundwork, we had to determine how we were going to actually begin building the design system. There was a lot of discussion with the team about the best way to go about doing this, as this was likely the most significant decision to make in the whole process. 

On my part at least, there was a strong temptation to just make a bunch of Figma components and build them and call that the design system. However, going that route was divorced from the situation we were actually in, which is: we have full product where every page is built differently and needs to be changed. Building a separate, independent design system doesn’t convey anything about how we’re going to correct our situation.

We still didn’t have full buy-in, so we needed to choose a project that could serve as a tangible proof-of-concept to stakeholders that this would work: that we could make a new design system and change over our current product.

In the end, we landed on the idea of completing a pilot project, whereby we’d design and implement one component, along with documenting it and changing old versions throughout our application. We felt like this type of project would make the most compelling argument to stakeholders because it would communicate that we figured out an iterative process from design to execution that could be applied to the entire design system.

• • •

OKRs

Now that we had determined the structure of our project, we needed to define our goals for the project and how they’d be measured. We decided to write OKRs. 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 pilot project:

• • •

A button

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

In our discussion of these questions, we decided that our first component would be a button. The reasons for this were that the button was:

1. Simple in behavior and visual design: It would be something easy to start with. 

2. Far-reaching: The button existed on almost every page of our application, so it 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. 

3. Multiple variations: The button had a few variations, which gave us the opportunity to expand into secondary components, which we could decide to explore in this phase as well.

• • •

Advocation

After months of preparation, we were finally ready to begin work on our first component. At Simon, in order to get engineering resources allocated to projects, you were required to write a project canvas, whereby representatives from every team would vote. 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.

• • •

Organization

Once we had approval, the first order of business was determining all of the elements involved in designing and building our button. I worked with an engineer on the team to produce a button elements proposal, while another designer/engineer pair produced a proposal for the accessibility requirements:

Button elements proposal I worked on with an engineer.

Accessibility proposal prepared by another designer and engineer.

• • •

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. 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. We defined tokens for all of the elements required for our button.

A tree diagram I completed to help visualize our color token.

• • •

VISUAL DESIGN

Visual identity

Defining tokens gave us the opportunity to hold a microscope to our existing visual identity and reconsider it. 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 completed all of the research and design to re-engineer Simon’s visual identity.

• • •

Fonts

The font used currently in Simon’s product was Brandon Grotesque which is commonly used in print, on things like posters and shop windows. Though Brandon Grotesque 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 Grotesque wasn’t the best choice. We needed something intended to be used at very small sizes for things like data tables. That said, Brandon also didn’t work especially well as a title font for our app, as it didn’t really have a modern feel that represented what Simon Data did as a business. 

I didn’t know much about choosing and pairing fonts before working on this project, so I did a decent amount of research, looking at 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.

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.

Color test I completed for the navigation.

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.

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.

Diagram showing page of old product with 4 different uses of pink.

We decided to 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. I tired different blue colors in our current app using developer tools and then defined new pink and blue shades for our design system:

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

• • •

EXECUTION + SHIPPING

A pivot

By the end of the quarter, we had designed and implemented our button, which included defining accessibility requirements, creating a token system, redesigning Simon’s visual identity, and documenting the button’s usage.

Our button: designed and built.

We had met all of our OKRs except those related to changing the button throughout our platform. Many of us on the design system team were using the button in our designs and builds, but we couldn’t get full product adoption. We met with multiple teams to try and get our button implemented in their apps, but we were unsuccessful. They weren’t sure how changing the button would affect the functioning of their apps, and they didn’t want to deal with it. For me, this validated the need for a design system in many ways. If an app is so fragile that replacing a button might break it, that’s highly problematic.

We wanted to keep pushing forward, but we didn’t know what would be the best next step. I brought this to the team to brainstorm on about what we should do next:

Our brainstorming board for best next steps.

• • •

A redesign

After discussion, we determined that the best next step was to redesign a section of our application and build the components we needed as we went. Designing and building the components in the context of our product would allow us to make deliberate choices that worked for our product specifically instead of making those choices arbitrarily. We could also be iterative and adjust things as we went to make sure our choices worked across our entire product.

We decided to redesign the Settings section of Simon because the pages were simple but many different components were required, like input fields, checkboxes, and radio buttons, allowing us to make many tokens

The design team worked together to redesign all of the pages in the Settings section, making necessary UX changes in addition to UI changes and adding components to the design system as we went along. Below are some of our redesigns:

Before:

• • •

Building

After the redesign, we were still looking for a way to get further buy-in and engineering resources to build the pages. Fortunately, a great opportunity to get both came up with our yearly Hackaton. We submitted the project to build of all of the newly designed Settings pages with our design system.

Beyond just getting the pages built, I thought the sharing portion would be a great way to evangelize the design system to the rest of the company and show stakeholders 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.

Simon’s original Flow Details page.

Simon’s Flow Details page I redesigned.

• • •

Impact

In many ways, the impact of this (or any) design system can be difficult to measure. We made so many changes, from the organization, visual identity, principles, etc. that it’s hard to quantify the impact. 

However, I felt like our main goal with our Hackathon presentation was to get further buy-in and to get engineers excited about using the new design system. With that in mind, I felt that emphasizing efficiency was the best way to present our impact. There really wasn’t a way to measure time spent for either engineers or designers, since we had no idea how much time was spent building or designing the original settings application. (That said, anecdotally, the engineers said that pages that would usually take them a few days now took about an hour with the new design system).

In our Hackathon presentation, we decided to focus on lines of code, with the engineers comparing lines of code in the previously built Settings app to lines of code in the newly built one. There was a 30x reduction in lines of code, which was more than we expected and were really happy with.

Based on the results of the presentation, leadership determined that, going forward, new features would be built with the new design system, and we’d continue to looking into how to transition the rest of the product over.