Why a design system?
Building an Enterprise Design System, Part 1
This is part of a series on the journey ServiceTitan took establishing their design system Anvil.
Part 1: Why a design system?
Part 2: Design System Infrastructure
Design systems are so hot right now. It’s hard to throw a rock and not find a Medium post or tweet on Design Twitter about design systems. I’ve spent the last six months at my role at ServiceTitan creating a design system for the company. I want to start this multi-part article specifically covering why we made a company initiative to form Anvil, the design system powering the huge enterprise app that we at ServiceTitan are working on.
Design Systems Are Abstract
The most common question I get from people who are not familiar with design systems is why. Why are we spending the effort building internal tools when we could be improving the experience or adding features? It’s an incredibly valid question that needs to be answered to get buy-in from stakeholders and leadership teams. It’s hard to see the reasons to spend the time working on it when you don’t experience the pains yourself.
Another reason that question is asked so much is that design systems are still abstract. Every company at every size has different challenges to solve and requirements to get there. Design systems are built to solve specific pain-points of the company. There’s no off-the-shelf solution (yet?) that will solve those needs without trying to solve other issues as well.
I’ve worked on three design systems at this point in my career and they were all drastically different in scope. I’ll be focusing on the problems we’re solving at ServiceTitan but I guarantee every company has experienced similar issues or will.
Explosive Growth
ServiceTitan hired their first designer in 2015. Since then, we’ve gone through four rounds of funding and have a double-digit design team. Most of that team growth has happened in the last year. With this newest round, we’re hoping to double the team in the next year (shameless plug: We’re hiring).
Scaling that fast is incredibly exciting. It’s also really hard. When you’re in a small team or a solo designer at a startup, you can basically keep everything in your head. You know the app inside and out. Design patterns start and end with you and your three Sketch files.
When you hit around the 5 designer mark, one of the biggest things that breaks down is the communication of existing and new design ideas. This is no fault of anyone, it’s just incredibly hard to keep track of what everyone is doing, and make sure information is surfaced in a timely manner.
Everyone is trying to get work done and ship useful experiences to customers. It’s easy for cross-application consistency to fall by the wayside.
“When can we update our legacy pages?”
Interfaces change. Design patterns change. Processes change. Branding changes. Technology stacks change (thanks React…). The people keeping track of the interface changes. All of that leads to design debt.
If you’ve never done an Interface Inventory, do it. It’s an enlightening process. Make it public. Do a presentation to the company about it. Show everyone that 43 button styles not only create a sense of disorder for the users, but it’s a time intensive process to figure out which button style should be used.
It can be much easier creating New_Button_final_v3 rather than trying to figure out what the most appropriate style is. It looks really good though. Let’s talk to the PM and engineer to use this new style across our app. Oh, it’s going to take days to get it rolled out and is out of scope for this project. Let’s just use it now and add a ticket to the backlog to convert the rest of the app.
Congratulations, you now have 44 button styles!
This is of no fault to anyone. I’ve done this myself. When an app gets larger and communication becomes more difficult, unless there’s a strategic effort to combat against this design debt, it’s going to happen.
Enable other work to be built
Product design is incredibly challenging work juggling multiple different tasks. Shipping good experiences requires understanding requirements, research, testing, wireframing, visual design, prototyping, iteration, handoff specs, feedback rounds from stakeholders, and more. You’re focusing on so many different tasks to get your product in a usable place, it can be inconvenient to have to design for consistency as well. It’s the problem of having to craft a tree and also build the forest at the same time.
It’s the problem of having to craft a tree and also build the forest at the same time.
If we have a dedicated person or team who is responsible for this high level view, it will allow other designers and engineers to focus more on creating the right experiences for our customers.
Anvils On The Horizon
So the issues we found above helped enforce the reasons we needed to build a design system. Those were:
- Communication breakdown as teams grow
- Inconsistent and expanding design patterns
- Design & engineering efficiencies
We kicked off an initiative to build our design system, Anvil, starting with a team of two. We’ve been working on it for about 6 months, and at the time of writing we have our branding patterns which include color palette, headline styles, typographic scale, and more, as well as over 20 components that our design and engineering teams are using to create and ship new experiences to customers.
We’ve grown the team to four, including a project manager, and since we’ve started seeing the impact across our Product org, planning to add more people to the team next year to continue this momentum.
In the next article, I’ll talk through our foundational strategy and how we got to where we are today.
I’m always thinking about hard and nebulous issues design teams are facing like design systems, scaling teams, and processes. If you are too, let’s chat on Twitter!
