Intuit Design System
Where I learned about design system and collaboration at scale.
Context
Intuit hired me at the beginning of the pandemic to join their Intuit Design System (IDS) team as a Principal Designer. IDS is a system that supports over 400 designers and 4000 developers for all of Intuit’s flagship products, such as Turbotax, Quickbooks, Mint, etc. When I joined, each product had its own design system and team, and IDS was formed to define how all those systems should work together.
After a few months, I became a UX Engineering Manager again because it was clear that I could be most helpful to the director as a technical right-hand man. I was effectively in charge of the platform side of the initiative and building partnerships with our engineering counterparts. I also formed a small team of UX engineers around me, with each member empowered to focus on a dedicated domain, such as design token management, the developer experience, the designer experience, and the handoff process.
Later on, the IDS director left the company, and while we were looking for a replacement, I became more involved as the acting leader of the team.
During this time, I focused on building strong relationships with engineering partners and advocating for the importance of design systems within the organization. I also worked on streamlining the design token management process and improving the developer and designer experience with IDS. As an acting leader, I continued guiding the team toward creating a unified and cohesive design system for Intuit’s products.
Interesting bits
A system of systems
When I joined, IDS was defined as a system of systems, meaning each product design system had sovereignty and independence. In reality, it was mainly a product of history.
The tension was between the design leadership’s will to unify the Intuit experience and the teams wanting to keep their autonomy in service of their audience specificity. This is usually referred to as “a branded house versus a house of brands”.
The other challenge was that IDS as a team was smaller — 5 people when I joined! — and less established than the other design system teams, so our scope had to be pretty restricted and at the higher levels of abstraction to be successful.
After experimenting and brainstorming about this situation, we proposed a mindset shift to the design organization. We offered to move away from this idea of a system of systems to a new framework where IDS was the only design system, supporting multiple themes for each product and able to systematize the specificity of each experience.
Durable / Adaptable framework
An essential piece of this new framework was defining what would express the familiarity between the different Intuit products and where we would introduce the flexibility to differentiate the experiences.
The challenge was to create a simple framework to be understood and remembered and at the same time introduce enough flexibility, so the different product teams didn’t feel too restrained. Getting them to agree on what would be flexible required a lot of discussions and compromises.
Leonardo De La Rocha — the IDS director then — published an article about it if you want more details, but we came up with this notion of Durable vs. Adaptable.
Durable elements express the familiarity between the different themes of the system, whereas adaptable elements can be changed to better meet products’ audience experiences. But what is interesting is how this framework could be found at different levels:
- First, determining which components (like buttons) or foundational elements (like typography) would be the same across the themes and, therefore, the products.
- Inside those components, we also had to define which attributes (like their background color) would be adaptable and which were durable.
- And inside those attributes, determining which options (mostly design tokens) were available to apply.
Another remarkable part of this model is the choice of durable wording. It used to be “fixed,” which was not conveying the correct meaning. Indeed, nothing in a design system should be fixed but involve different layers of change, therefore requesting different quantities of resources and timescales. You can find a good analogy in architecture with Shearing layers. Its central argument is that “there isn’t any such thing as a building. A building properly conceived is several layers of longevity of built components” (Brand, 1994).
And it is composed of the following:
- Site (the geographical location)
- Structure (the foundation and load-bearing elements)
- Skin (the exterior surfaces)
- Services (the wiring, plumbing, ventilation, and moving parts like elevators)
- Space Plan (the interior layout)
- Stuff (the furniture)
You can then easily understand that each layer could technically change over time, amid different levels of time and effort, just like in a design system.
Multiplication of variants
Another aspect of this mindset shift to a unique system supporting several brands is that we consecutively had to manage a lot of variants.
Each component had to be thought of in multi-dimension:
- By theme (in our case, we supported 6)
- By platform (Web, iOS, Android, etc.)
- Light and dark modes
A quick calculation will give you not 1 button component but 36 in our case, which is often the case for larger scale systems. The maintenance cost is not trivial; once again, the team had to devise ways to automate edits and changes as much as possible.
The best strategy, in my experience, is to leverage a design token management tool, and I highly recommend checking out Style Dictionary first.
For IDS, we had a central theme with sub-themes with overrides for each product, platform, and mode (in that order). I was also envisioning how we could potentially go even further and introduce locale-based customization on top of everything else to best serve a global company’s users.
If you want to know more about how our design token architecture was conceived and built, I highly recommend my friend and now ex-colleague Kelly Harrop’s article.
Naming council
Introducing the notion of design tokens to the company meant we would have to write many of them. And as you probably know already: naming is hard.
It has to do with the fact that a good name for a token needs to be distinctive and immediately understandable by most, including designers and developers. Unfortunately, some terms have different meanings in different contexts. Understand here tech stacks.
We have overcome this challenge by creating a naming council, where each platform’s technical lead would state what would be a good name for each token, especially the component ones. It was a tedious effort but also a great experience to understand each other better and ultimately build a shared language that makes a more robust design system community.
The need for a CRM
We were fortunate to have a gem as our Design Ops in the team. Running the business with them was so much more efficient, and when you’re supporting over 400 designers and 4000 developers in a company, you absolutely need to stay organized. So much so that one day while I was talking with them, it just appeared to me that if you consider your design system — as you probably should — as a small-sized company with clients, it just then makes sense to invest in a CRM (Customer Relationship Management).
It might be rudimentary compared to the full-fledged tools that exist for professional organizations, but keeping track of:
- who in your team owns the relationship with a particular group
- who’s their point of contact (or sponsor)
- when was the last time we talked
- what’s the status of the relationship
And so on is essential to the success of your design system.
If you’re interested in building one in Notion, I wrote an article that you might find helpful.
Outcomes
When I first joined the IDS team, I knew that it would be a valuable experience. However, I didn’t realize just how much I would learn. Not only did I gain knowledge about scaling a design system, but I also learned about the importance of prioritizing relationships and partnerships. Despite the fact that our team was small, we were still able to have a significant impact. This was only possible because we made sure to engage with our stakeholders, users, and partners as much as possible.
After all, as Jina Anne coined the term before: design systems are for people.
