What I learned building GoDaddy's first design system theme
Product Designer · 2019 · Design Systems
Overview
What to know about this project
In 2019 I led the first iteration of the GoDaddy Pro design system, translating brand guidelines and wireframes for a three-year vision into a basic set of components our team could use to launch the product. The hardest part wasn't defining the styles. It was executing them in production when hit with business constraints. I learned a ton and found a deep interest in design system and accessibility work.
Context
Who is this for?
Users (Pros): Website designers and developers who build sites for clients as a living.
Product: The Hub by GoDaddy Pro is a variation of a customer's GoDaddy account that has features and tools tailored for tasks related to client management and site management.
The Problem
No UI system, no consistency
The first version of the Hub was designed with a mix of UI from GoDaddy's main design system and custom code, causing inconsistencies from screen to screen and slowing the whole team's productivity.
What we needed:
- To translate visual styles from brand into a system designers could use to expedite work and have a consistent experience.
- To map these styles back to the new theming technology GoDaddy engineers were actively building so the Hub could go to production with the right design system backend.
Discovery
Mapping brand to interface
I partnered with our design director to sketch quick high-fidelity screens showing how the brand guidelines could work on the interfaces our designers were building. By mapping 1:1 with the current design system, we defined the first components we'd need to theme and what we'd change.
The changes we scoped for the theme:
| Property | Change |
|---|---|
| Color | Yellow as primary instead of GoDaddy teal |
| Type | lighter headline weight; no adding or removing styles |
| Radius | Rounded components instead of square |
| Stroke | Lighter grey on strokes |
| Surface | White background instead of grey with floating white canvas |
Learnings
What the process taught me
Learning how to build design systems and standards is one of the most important things I've learned in my career. This project surfaced three lessons I still carry into every design system engagement.
01: Shared language
The design system has to match the tech stack.
What we didn't expect when we started was that the new theming technology used a different labeling and organization structure than the current GoDaddy design system. That breakdown in shared language caused ongoing confusion between design, the theming engineering team, and our local product engineering team. A design system is how engineers communicate with design, so it's crucial you're speaking the same language. The system you use to label colors, type stacks, and variables should line up with how those values are represented in code.
→Now, the first thing I do when working with any design system is understand its naming and organization structure. With AI automating more of the design system process, this is even more crucial to using AI successfully.
02: Flexibility
Understand the priorities of every team you depend on.
The theming backend wasn't complete enough for the styles we needed, and the team building it had higher priorities outside of the Pro design system. Working across orgs, I learned how important it was to understand what each team was optimizing for.
→When we didn't have priority on styles we needed, we adapted: sometimes hardcoding styles, sometimes accepting a less visually ideal approach to avoid tech debt we'd fix later. Knowing when to push and when to pivot is a skill I picked up the hard way here.
03: Documentation
The hardest and most underestimated part.
A huge pain point was keeping patterns up to date and making sure the team was aware of changes to components, while keeping parity between what existed in code, what existed in the pattern library, and what lived on designers' screens. I underestimated this when I took on the project.
→I'm genuinely optimistic about what new AI-assisted workflows can do to close some of these gaps, but it's still a step that requires real time and real priority to get right.
Results
Outcome
It wasn't perfect, but it unblocked a crucial bottleneck so the product could meet launch dates and expectations from leadership. Sometimes that's exactly what a v1 needs to be.
As the first team to try the new theming backend, we provided crucial feedback to the main design foundations team and engineering on where we ran into problems. That feedback helped jumpstart their work when the main theme needed to be revamped. I went on to work closely with the design foundations team as a contributor after this project.