Frosted-ui Design System

Stats

• Stage: Seed
• Size: 23 total, 9 engineers
• Location: Williamsburg, NY & Remote
• Profitable & Funded!

---

Introduction (situation)

When I decided to work with Whop in early 2022, the company was growing rapidly but lacking efficiency and consistency across their three web apps. Not only that, but the team had big plans to expand their maintained apps significantly to meet a wide variety of customer needs.

Tim Gutieras, the Founding Product Designer at Whop - Hey [ ] Tim 👋 - was one of the first people I met when Whop approached me about their Design Engineer Role. Immediately we started discussing a design system for Whop to cover the different app surface areas, as well as the shortcomings of the current component library. In my first day of assessing the current state by talking to Frontend devs and Tim, I had come up with the scope of what I needed to address ASAP.

1. Whop had recently matured up market to customers running upper 6 figure businesses past impromptu entrepreneurs. The new designs passed to the dev team represented this shift in design.
2. Components had many instances. Actual components that existed in the codebase included ButtonWithLink alongside Button and ButtonNew. There were also some components like Tabs that were built as a component in some places, and in others, completely customizable implementations that were not re-useable attempting to closer match the production implementation needed.
3. Developers were very unclear on which components were available, or how to use them. Many components were default exported, didn't have exported types, didn't have clear overlaps between the Figma components, and were undocumented in general.
4. Figma and Code were confusing to translate between. Components in Figma had starkly different namings for properties than in code. For example Figma would have a type and color where as code would compound those things into variant="primary-ghost".

Taking stock of what was needed

After assessing the shortcomings of the current system, I created a project in Linear to accurately break down the solution and scope. Specifically I methodically went through the Design System Figma components, upcoming designs, and the existing products to find overlaps and missing components. This gave a quantitative view to the Design system components we needed as well as a qualitative view into which components needed prioritization.

Having all of the components in Linear issues made it simple to communicate with the remote team on which components were needed for a feature to ship properly and simple enough to estimate the time investment needed before starting.

Fun tidbit - the name frosted-ui comes from the company's initial name, Frosted Inc.

Components are the star of the show here, but a few more things needed to be completed in this project to succeed.

• Developers actually using the components (visibility)
• Documentation to understand where to turn to for implementation
• Principles to create a streamlined set of expectations needed to be defined

A component library becomes a bonafide Design System

I created a slack channel dedicated to announcing design system changes, requesting components/features and general feedback.

Things I did to make sure usage took hold:

• Any time UI was touched, I made sure to do a PR review
• Weekly frosted-ui open hours, dedicated to feedback and digging into frustrating / missing bits of frosted.
• Prefixing every component in Figma that had a Frosted sibling with an 🧊 emoji. This made it really easy for developers inspecting a Figma handoff file to know when to reach for a frosted imported component.
• Documentation using Storybook.js and later integrating component documentation into the Figma Dev Mode side panel.

Frosted-ui's impact on Whop

With 3 months of intensive component work, and 5 of maintenance and composition work invested, here are the stats, stacked up:

• Overwhelmingly positive feedback from developers using frosted-ui.