Zeus Design System
This case study tells the story of how we created the foundations of a design system at Zeus. I’ll share insight into our process, the challenges, how we made decisions, the tools we used, and the impact for the company.
Zeus is a startup that offers thoughtfully furnished homes for business travelers. Our goal was to create a modern and desirable living experience for each of their residents that is far better than traditional corporate housing through tech-driven efficiency.
When I started working there, Zeus was in the middle of defining the brand in collaboration with an external design agency. Every rebrand is a major effort but it was an even bigger endeavor at Zeus because our brand identity had to be reflected far past our digital experience and into our homes.

My assignment was to implement the new brand across our whole digital experience: all of our landing pages, our whole product, and our emails. For a number of reasons (which I'll get into below) I identified creating a design system as an essential starting point for ensuring that the re-brand was executed successfully.
Why a Design System?
When I brought up the idea of a design system to the rest of PED most of the team was skeptical, including the Head of Product and the CTO. I knew that I could make a pattern library on the design side myself, but I felt that creating a design system across design and engineering would be beneficial. After a healthy dose of conversation we decided that creating a design system would be a worthwhile endeavor for three reasons.
Streamline Development
The scope of the rebrand was pretty wide. The engineering team agreed that creating basic shared styles and components would be beneficial for increasing the speed and quality of the rebrand, while also creating an opportunity to clean up some of the tech debt on the front-end.
Building a foundation for other designers
Since I was the first in-house designer, the team had almost no internal design files or artifacts that could be used as a starting point for future projects. The scope of the rebrand included designs for a few of our key marketing and product pages, but not all. I was going to have to design a good portion of our website in order for us to update our website anyway and it made sense to do that work with a systematic approach.
Planning for the future
The company intended for all teams to grow 3-4x in the upcoming year and we knew it was going to be a challenge. Creating reliable foundations, processes, and best practices internally was going to be important in helping us grow while minimizing chaos. By investing in a design system now we felt that we make our current work more efficient while also setting ourselves up for success for the future.
Our brand agency had already defined our primary colors and a few secondary colors. The key issue I discovered was that most of the grays that we had throughout our site for body and secondary type were far below accessibility standards. They were also not used in a consistent manner and I felt like the number of grays used for type could be reduced.I decided to create a gray palette that had an understanding of accessibility built into its naming convention. Each gray color in the scale that met accessibility standards for readable text had an "A" next to it. More "A"s meant it was higher on the accessibility spectrum and no "A"s meant that the color was only usable for decorative elements.
We had already selected new fonts as a part of the brand project. Noe Display Bold was used for all headings and text that needed a high level of attention and Mallory Book was used for body and UI text.

We were really excited about the fonts, but we were missing a consistently used set of type classes with a clear naming pattern. Additionally, I wanted the typography system to have responsiveness baked in. In the past, I had experienced the pain of having to provide design specs for mobile, tablet, and desktop to engineers during a project kickoff. I felt that there might be a lot of potential in a design system defining how type classes should shift with responsive breakpoints.
Layout & Spacing
The brand agency had created all of their designs based on a 12 column grid, but we didn't have rules for how that grid evolved responsively. I defined four breakpoints and how the grid should adjust based on the width of the screen. My choices here were heavily influenced by Bootstrap defines its grid system.

There was also no defined system for how spacing should be structured. I wanted to preserve the overall feel of the designs, but I also wanted the spacing reflect a systematic approach. I decided to use a simple base 4px spacing system for small elements and a base 8px spacing system for everything else. I also provided guidelines for how spaces should adjust across responsive breakpoints, but these were not baked into the system by default.
Define Our Key UI Components
With our basic styles and landing pages in place, it was now finally time to jump into our product and UI components. For time constraints, we focused on making components for elements that we knew we would use frequently throughout the product. With just these components in place, we were able to create 80% of our pages systematically. It was only a few pages that still required ad-hoc UI elements.
Buttons & Links
Buttons and links are used on almost every page and we defined a robust selection of 6 button and 4 link styles to accommodate. I had fun prototyped all of these elements in html / css. The arrows on the Display Links were animated to add a touch of motion to our designs.
Form Elements
Inputs, radio buttons, and checkboxes were used throughout our checkout and payment flows. It was important to us for these elements to be visibly accessible so we chose to use a darker gray than is normally used for outlines and inactive states.