How do you maintain and evolve a design system for multiple web and mobile products?
To find out, we spoke with Joe Preston, Director of Design Systems and Engineering at Intuit. Co-founder of the enterprise UX consultancy Momentum Labs, he joined the Intuit team in 2016 to help them scale their design system across all products.
Joe explains how to sell a design system, strike a balance between consistency and creativity, and other lessons learned over the years. Check out the full video and transcript below.
To learn more about the benefits and processes of design systems, download the free e-book Why Build a Design System?
What’s your background and how did you come to join the Intuit design system team?
I’ve been with Intuit for a little over a year and three months now. Before that, I was partner at an Enterprise UX agency where I did mostly enterprise software design.
I interviewed. I actually knew Suzanne Pellican because she had spoke at some meet-ups that I run for client and Enterprise UX meet-ups, and I was always really impressed with her, and I had always thought of Intuit as a design-driven company.
Coming out of an agency where all I felt like I was constantly selling even really large clients like in Intuit on how to build, and design, and even ship your product, but really not having experience that from a large software company perspective, so that was really what I was looking for in my career. Then, the small business group, basically QuickBooks side of Intuit, had had a design system working for a while known as “Harmony,” and so I took over when I started for the previous person that was managing Harmony, and it was just an interesting … I just found it an interesting challenge.
Coming from enterprise, I always loved systems, learning about different systems and what makes them tick, especially…not necessarily even from a technology standpoint all the time, but I love people, and processes, and what tools do you use, and so I had the benefit of walking into a design system that had already done a significant amount of change across the company, and it had been very successful at least for Intuit in terms of changing the landscape of especially QuickBooks and all the products under that to the point where all the top-level executives saw it as a key contributor to the success that was about that business group. I had the benefit of coming in with that sort of groundwork already laid for me.
Really, what I was looking to do was take the design system to the next level, figure out how to add some pieces to it maybe that were missing. Design systems can become dated or they can become irrelevant to companies for a variety of reasons, and so part of what I found interesting and challenging was how to make it more relevant and how to make it solve problems that the company was having now when I joined, which were different from when the problems it was trying to solve when they started Harmony.
I love a new challenge, and I think the stars aligned for me somewhat in that I was walking into a design system that already had some legs underneath it, but there’s a good and a bad to that too. There are some legacy issues with the design system that I also inherited too.
How did the problems faced by the design systems team change over time?
I think that one of the problems was that Harmony in and of itself really was focused on taking QuickBooks online products and making them have a cohesive experience. I think what changed over the business is people started to realize that, “Look, your customer experience is actually end to end. It’s not just your product. It’s everything from the point in which they hit your marketing website to even when they call up and talk to a care agent. That’s all really part of your customer experience.”
When we looked across that landscape, it was very disparate and very all over the place, and so the company’s mindset had shifted to thinking about really the product only being the core tenant of the experience to looking more holistically at that, what we call the “end-to-end experience,” so that was one change.
Another change was that mobile became more of a focus. Harmony started in the early on days of … especially for mobile apps within Intuit being not really evolved, not well-adopted, and so the early stages of Harmony was … It was really for a web desktop sort of product experience, and the company had shifted in terms of wanting to focus on mobile or even mobile-first, and we didn’t have a design system at the time there who supported that.
To some of the other sort of things that I think had changed for Intuit is we had decided as an Intuit wide ecosystem, so now think QuickBooks, think TurboTax, think Mint, and a product group we have called “ProConnect,” and because Harmony had been fairly successful as a design system enacting change for one business unit, it makes sense that all the business units begin to see like, “Well, we actually could benefit from a design system because we’re now seeing customers move from product to product, and those are very different experiences.”
The first part of Intuit design system was aligning on the core tenants of what we consider for our system, which are really the brand visual language, and so that was really … When I came into the business, when I came into Intuit, it was really starting with, “All right. Well, let’s at least align on our core tenets of our visual language, and then we can begin to build on that.”
To be honest, we’re still in the midst of it. For a company of Intuit’s size. I think we’re at 8,000 employees. It’s going to be a long journey, but I think what we were getting to see the fruits of creating the model of our process in terms of working together as brands because we have really different customers and use cases on it, so I think that’s the biggest challenge for at least Intuit design system.
After defining the visual language, what was the next challenge you faced?
Arriving at a process, and a contribution model, and a decision-making framework that we could scale, especially where all the businesses of Intuit felt like they had ownership, felt like they had a sense of the design system is by the people, for the people. I was talking to Nathan Curtis yesterday, and we were talking about this same kind of concept.
That was crucial to get right because before I got to the company, there had been central top-down-driven initiatives to try to get all the brands to adhere or be cohesive, and those initiatives from my understanding had failed just from the standpoint that they were top-down-driven.
One of the first things we wanted to get right was making sure we’re taking more of a bottom-up approach in terms of not only what gets proposed to be added to the system, but then also, how decisions get made and then how decisions get disseminated. That really I think is the crucial piece to making it work, and that’s really … to use another Nathan courtesy dimple. That’s really having a small central team to help drive initiatives. Then, really having a delegated model where there’s a whole wide variety of stakeholders that give you that diversity of thought that you need. To be honest, I think that was actually the more crucial piece to design system.
How did you structure out your design systems team?
The QuickBooks side of the house already had a design systems team, which I came into, and so that consisted of four designers.
First, I brought in two contract front-end developers to work with the design system team, and then we actually built out a design engineering team that works in parallel with design systems. That way, we could really have a nice blend of designers and developers, but again, we were still operating mainly under QuickBooks with that model.
Then, when we became more involved with Intuit design system, what we decided is there needs to be a central team to drive this, so at the Intuit central or group, we hired a small team, and that was a designer, a developer, and a program manager since they like … That person acts basically like a product manager.
Then, each of the business units have assigned representatives that really drive the initiatives forward. I’m the representative for QuickBooks. There’s another equivalent for TurboTax, Mint, and ProConnect. Then, we meet multiple times a week going over … reviewing proposals, talking about what we’re going to do next, aligning our roadmaps together, and then we try to involve different designers and teams from each of our businesses to actually be the boots on the ground so to speak. Sorry about that, the boots on the ground so to speak, doing the work.
The central team really acts as…making sure the work scales for the ecosystem, making sure the documentation is tight, and then making sure that the information is served, collected centrally, and disseminated out to all the teams.
We’re still in the early stages of that. We’re building basically a toolkit or a source of the truth for Intuit design systems, starting with components and those sort of foundational visual language elements. Whereas on QuickBooks Harmony side, we’ve actually had a site, a source of truth for a long time, so we’re taking all our learnings from Harmony, and we actually have a new site, design.quickbooks.com. We’re taking all those learnings and applying them now at an Intuit-wide level.
How many people are on the design systems team now at Intuit?
We probably have eight or nine people 100% dedicated to design systems. If I were to add in all the contributors though, then we’re probably getting up until like 30 or 40 people, but a lot of those people are just brought in part-time capacity to drive through whatever initiative we’re working on at the time.
Is your work 100% dedicated to the design system?
I am, but I’m straddled between the two.
QuickBooks in and of itself has a whole bunch of products under it, and QuickBooks … Just to give you an idea of scale, the small business group or the QuickBooks group has 170 designers in it. Just QuickBooks. Whereas all of Intuit has, I think, 200-something, so over two-thirds of at least the design support we have to offer is just for QuickBooks because there’s QuickBooks Self-Employed, QuickBooks, QuickBooks Accounting. There’s desktop. It just goes on, and on, and on.
I’d say I probably spent about 60% of my time on components and patterns changes just within the QuickBooks ecosystem, and then as we’re doing that, we’re trying to either think about how to scale them for Intuit-wide or use stuff that we know some of the other brands have more established like QuickBooks … TurboTax has a lot of really great components and patterns that we’re starting to leverage now. The other 30% of my time, I’m trying to dedicate to the Intuit design system and make it more over time.
What does the approval process look like for the design system?
First of all, we align all of our roadmaps, and we make sure that the design system hopefully is going to provide solutions that we need by X amount of time. That’s a balancing act.
Secondly, once Intuit design system takes on an initiative, we’ll basically have that person write a proposal. What’s the business case? What’s the customer case? And then we’ll actually turn that into just this document. Think of it like a creative brief.
The creative brief is then reviewed by essentially like the drivers board, which I’m on.
Mint, TurboTax, QuickBooks, ProConnect. We all review everything, go, “Yeah, that’s a great addition to our system. Let’s move forward with it.” Then, that team that initially proposed it from whatever product it’s from drives it through … There’s a driver, and then they’ll go and basically gather use cases from the ecosystem of what this affects, and they’ll basically … We call it “go broad to go narrow.” You’ll start doing concept exploration and testing with customers
Then, over time, you’ll start to narrow down your focus and iterate on particular past. This is where we also might start prototyping it in code, putting it possibly in front of customers again in code, and then final process is the same group basically approves it. We do have approvers … or Leslie Witt from SVP and Kurt Walecki from TurboTax. They’re the final approvers.
Then, it’s live. Essentially, if we don’t have component code yet, then we would start production, but a lot of these things will finish with a code component, but it could be other things. It could be adding styling variables to our CSS framework. It could be … We added a new color to our color palette because we realized that we’re having some accessibility issues with one of our colors in particular. It can be a whole range of things, and the delivery … so the artifacts of delivery also can range quite a bit.
Is any designer, or developer, or even product manager free to suggest changes to the design system?
Absolutely.
How do you measure the success of a design system? Are there like certain metrics that you’re looking at?
That’s a great question. I think it depends on the element that we’re using, but let’s say like a UI component gets introduced. What we’re starting to measure now is the number of contributions to that UI component. We’re measuring the velocity. We should be, let’s say, story completion time that it took us to build that component, but now we’re taking it to the max level, and we’re actually looking at how many instances of that component are being used in the product and where, and we’re also starting to look at how much traffic, how much customer traffic is actually going through that component.
Over time, what we’re thinking is that will allow us to really focus on areas that we really want to refine or get better based upon things that are actually being used a lot. If it’s something like more brand or visual language related, that stuff is tougher to measure. Honestly, like if it’s a tight phase change, we’re measuring things like accessibility and usability of customer feedback. But then, there’s other more qualitative or even subjective measurements which is just, “How are we perceived as a brand? Are we perceived cohesively as a brand?” That’s another measure we’re looking at called “brand health.”
Like it depends on what the artifact of the system is and how we would measure success, but we’re definitely … Velocity is huge to us, and then also making sure that what we put out is being contributed to a lot, and then is being adopted by teams a lot. Then, the next level is it’s actually being used by customers and they like it. Those are the KPI or the success metrics that we’re working with right now.
Since you’ve started working at the design system, have you seen changes or improvements to the product development process?
The design system isn’t fully adopted across all the products to the same level.
I think that QuickBooks probably is the most adopted the most things out of the design system out of the other brands, but one of the things we use in the design system for is when we change our visual language, we actually use some new elements of our design system such as the CSS framework to roll out all the color changes, all the typography changes across … Shoot, there’s like 12 different products.
When I came into the company, part of what drove this was a lot of the design leaders getting frustrated by saying, “You know, we want to change our button colors to green across the board, and all the engineers are telling us this is going to take like 40 months or …” The estimates were like in the years’ timeframe, right? By the time we get done with it, we won’t even be using UI anymore. We’ll be on to like voice, or gesture, or something. When I came in, I was used with this catalyst of like changing our button style, right?
When we looked at it, we said, “Hey, look. We’re not on the same technology stack, so what can we develop that will help accelerate adoption and help with cohesiveness or dare I say consistency, which was a CSS framework?” That was just really like a lightweight set of semantic variables that you find in any UI component library that we could apply to a variety of components or even marketing websites, so that was like our first step is, “Let’s develop a set of style variables,” and then we’re going to actually go around to all the teams and train them and let them know the variables exist, how to use them.
Then, we also had to embed and pair programmers and designers with each product team. It’s amazing what happens when … If you just ask an engineer for an estimate based on a red line spec, you get a very high estimate. Whereas when you sit down with them, and you open up the IDE, and you start changing the code, boy, it was a lot faster than anyone expected.
I think that was the other part of it was just really not just mandating that teams have to adopt it by X timeframe, but sitting down with each team and understanding their needs and understanding … You’d walk into a product manager’s office and you tell them, “Hey, I want to change all your button colors to green, and I need like two of your engineers to do that over the next few months,” and they slam the door right in your face.
Whereas you come in, you go, “Hey, look. We’re changing the whole ecosystem. Here is the reason why. We’ve done a lot of customer testing, and we’re getting really good results in this visual language. How about we sit down with one of your front-end developers and give us a couple days, and we’ll just crank this out?” That makes the conversation go a lot easier.
We used at least the starting phases of Intuit design system as a way to prove we can roll out a whole new brand in a fraction of the time that it would have taken us before, and that was a big sort of proof point I think. We started really doing the brand work I’d say about July of last year, and we rolled it out across at least all of our online products, a couple of our mobile products, and then our web or marketing products. It was all done by December.
How did the team balance all the requirements without turning the design system into a total compromise?
Having a defined process, so like I said, it’s really important actually to have creativity for some set of requirements initially about, “What are you trying to accomplish? What’s everyone role?” Hopefully, that’s backed by some customer or some business benefit, so I think as funny as it sounds, I think it is crucial to at least upfront spend a little bit of time defining that stuff.
Then, I think it’s useful for you to gather use cases that we still flagship products or flagship experiences because those might be your highest sort of customer touch points, and you also have to weigh that some … in a larger organization that has lots of products, there might be some products that are on older legacy text stacks or just the cost to them to adopt a new design system or whatever it is, is just too high.
There are pretty easy matrix you can make in terms of cost benefit ratios about adopting the design system, and you can make tradeoffs about what are the elements of the system that you need to be aware, and so we did a lot of that. In terms of … We also identified like who are influencers amongst each of the product groups and made sure that they had a hand in helping not only gather use cases, but helping review the design proposals that were coming through, so that they felt like their voice is heard.
Then, once they got back to their product teams, the other advantage of that was those people had just been involved in the design system work, so who better to be an influencer of that product than that person? We found a lot of those people and took them out to coffee and beers a lot.
In terms of future-proofing a design system, that’s a great question, and it’s probably my biggest concern always. That can be really frustrating to people because most of the design systems are not on the bleeding edge of innovation. Brad Frost actually had a great article about this recently called like “The best design systems are like the really boring ones,” and there’s some truth to that.
If you do believe that your job as a design system is really to enable the products to do the best work that they can and to support them, but not to be the determinant factor of what gets released in products. The product teams and the marketing teams, they own basically their destiny, and all we can really try to do is help them achieve that destiny, make sure our tools are the latest and greatest tools, make sure whatever artifacts we’re providing to them are really easy to consume, really easy to use, well-documented, and I think that in relationships and an inclusive process where people feel part of the design system is the key to future-proofing it.
Do you find that there’s also a challenge around prescribing enough guidelines to ensure consistency versus giving some wiggle room?
That’s a great question. At some point, you don’t want to step on the product designer’s toes and be so prescriptive that you’re really restricting them from doing their job, which is figuring out how to make a great experience, and so there’s definitely a balance there in terms of … I think we’ve made the mistake plenty of times of probably being over-prescriptive. We try to develop this concept in Intuit design system of having what we call “fixed” and “flexible” elements as a way to help give guidance … depending upon your use case or however, whatever context you’re going to use it in. We’re anticipating all these elements will change, so we’re trying to do that.
Then, the other part of that I think would be the … This is the difference between a component and a pattern, most people would say, so like you think of components as being really reusable, really modular. They’re usually coded, but they don’t necessarily solve that specific of problems, and they’re not really that contextually relevant, whereas … That’s why people develop interaction patterns so you can have a more prescriptive set of instructions of like, “For this particular context, this is how we want you to treat, let’s say, navigation,” or, “This is how we handle search,” or whatever it is.
I think that’s where you can find that kind of balance of having these really reusable modular things like Lego pieces that can be put together in a variety of ways. But then again, you need some semblance of cohesion, so you have to have some prescriptive instructions maybe in the form of patterns, maybe in the form of fixed, flexible sort of properties on things. I don’t know if that answers your question or not, but …
Dos and don’ts are another great way to show more example-based guidelines in terms of where you’d be prescriptive. Fixed and flexible, that’s a concept that … I think when I initially first … When we were talking about, I really struggled with that concept because I felt like it was being overly prescriptive, but then I’ve seen tons of cases where designers and developers love those constraints or love to have guidelines around constraints because it gives them … People sometimes do their best work when they’re just giving a few sets of constraints to work within, so I’ve come around to realizing that I think those properties on some of our elements actually help people. It’s something interesting.
How did you evolve your technology stack with the design system?
When I came in, there was a … If we just take, let’s say, our web products, there was a variety of JavaScript-based UI component libraries out there. All the usual suspects. JQuery, a little Bootstrap over here. Dojo all over the place. Another initiative I was part of was essentially looking at re-platforming the web technology into something more modern. We had another team on angular as an example. That was also where we looked at … We borrowed from the salesforce lightning tokens, design tokens idea of, “We could at least develop like a CSS framework or a set of CSS variables.” We can even transpose or transform those variables into like whatever syntax or format we want, so that helped become this bridge between the design system and the disparate at technology.
Separately, we did arrive at using the React for our UI components, so we built our UI components using React, ES6 syntax. They’re responsive. They do use a flex box. Then, separately, we’re looking to do similar with native mobile components, and so we’ve got some competing technologies at play. One is basically a single-page application show that we can embed in a native app that allows us to show web experience seamlessly.
Meaning, like we pre-cache everything. All the components are responsive, even adaptive, and the user doesn’t really know that it’s actually web, which is … It’s funny. Like in my old job, that has been tried so many different ways by so many different companies that when I heard that, I’m like, “This is a terrible idea.” But then, we actually pulled it off where it’s actually pretty seamless.
The other competing technology is like React Native, which when we started down this path of picking React, React Native was still very much in its infancy, pretty buggy at the time, and so we weren’t ready to dive 100% into React, but recently, it’s actually … It made some leaps and bounds, so we’re revisiting that, but just to give you like … When we chose to go to React and we … from just pure web JavaScript components, we’re looking at … on average, it’s like 60% to 70% less code for the React component, so it’s significant.
The other things we’re doing are adding like continuous integration, so some CICD stuff where we’ve got linkers, we’ve got automated functional tests both locally like an automated unit test, and then we fire off a more significant set of functional tests, functional automated tests the minute you try to submit a poor request, so we’re trying to like tighten up our CICD of our library. Right now, we made really good progress.
Some of the other tools. We really liked the lightning team had built just for internal testing or internal monitoring of how people are using stuff. We’ve been looking to build not exactly like they’re doing, but had some similar concepts. Yeah. That’s basically where we’re at.
Should designers in a design systems team have some development background?
Not so much. Of course, that’s a really nice bonus. I think basic HTML and CSS. Yeah, that’s probably a must. In terms of, “You have to be a hardcore JavaScript programmer,” certainly not. I think what’s more interesting for a skillset for me as a designer is systems thinkers, so people that can think scale, can think about … I’ve heard it described as, “You’re not designing cars. You’re designing the tools that build the cars.”
Another example is Nathan Curtis was talking about how the skillsets involved with the design systems team member are a lot more soft skills. They’re like communication. Can you influence people? Can you walk into a room full of a bunch of other designers, executives, and engineers, and have everyone essentially convinced by the end of that meeting that we’re all aligned on whatever direction we want to go?
I think that’s really the key skillsets of design system folks because you’re the connective tissues with all these different people, and so it’s those social and the soft skills that come in the most handy more than I think technical skills, and that’s hard. When people come on my team, it’s like I know they just want to put the headphones and start cranking away a sketch, but it’s like unfortunately, you’re in a lot of meetings because you’re having to influence people or you … The other part of it is you have to see the breadth of what teams are designing in order to have those conversations in order to figure out like, “Oh, wow. That’s a new emerging pattern that we’re seeing happening right now. That is a really nice addition.” You have to be there and talk to those people to be able to experience that.
That’s what’s hard about … especially in the existing design system. I could see on a small company that doesn’t have a design system where it’s just like, “All right. Wipe the slate clean. Let’s do something from scratch. We’re not going to talk to you guys until we have V1 out, and then we’ll figure out how to have other people start contributing.” When you get to the point of … You’re at V2, V3, V4, and you really want to involve other people in terms of them feeling like the design system is theirs, that’s where those skillsets change of being more soft skills of a designer.
What are some of the goals you have in mind for the Intuit design system at the current stage in its evolution?
Some of the goals are more around some of the more connective tissue elements of our products and our marketing experiences. Not just a UI component, but you look at things like headers, notification centers, sign in, sign on. There’s a whole slew of stuff that when you look at larger companies, those are really the pieces of connective tissue if you have customers moving from product to product like think of Google, right?
I think those are what we’re seeing now on the horizon as a big value add that the system can bring to the company. Then, the other thing is there are some business units that don’t have a design system, don’t have a team, don’t have resources, and for them, it’s nice to get a whole bunch of stuff that’s highly involved and been tested essentially for free.
Maybe at the hands of QuickBooks and TurboTax, but that’s okay because we know that if one of us gets better, we all get better, so I think that’s the other thing we’re looking forward towards is, is everyone contributing their own little special areas that they’ve spent a lot of time focusing on? Like TurboTax, those guys have been through the wringer as far as like usability testing with customers and all sorts of stuff. The way they build their UIs is really progressive, and so they can bring a set of expertise to the table that we can all benefit from and vice versa. QuickBooks too has been doing some really interesting stuff in terms of … The new sort of text stack we’re moving with is something that the whole company actually really likes that new text stack.
Just the fact that we’ve had a functioning design system for longer in the QuickBooks side of the house, we’ve learned a lot of things about process, and we’re able to bring that to bear when we try to do it at a larger scale. Then, we’re looking at other stuff like we know … like the world is moving beyond the graphical UI. We all know that, right?
I think the next challenge I see on the horizon for design systems is that … I think a lot of elements of design systems will become automated where the tools that we all use will export out. We’re already seeing this like Craft from InVision, or Inspector, or Frontify, or … There’s all these mini style-guide-generating apps, and that’s only going to get further, and so the next level for us is looking at other forms of user interface that are happening. How do you make a system out of those?
We don’t really know yet. We’re just dipping our toes in the water with this stuff, but because we all see that as part of our brand experience, if you’re talking to your phone, and repairing it, or you’re chatting, or VR/AR stuff, it’s like those are all ways that our customers are going to experience our brand, and so we’re going to want to have a system behind them to make sure they’re a cohesive experience and that they feel like Intuit.
What advice would you give to someone embarking on creating their first design system?
The first question will be questioning why a design system?
I think the answer would be, “What problems does your organization or your product have that you feel like a design system could provide a solution for?” Right? Especially, can you explain that to executives and stakeholders, and even quantify that problem, sometimes you need to, down to a dollar amount, or a time amount, or some sort of customer experience metric or whatever? Then, based upon that, I would decide what is the design system that we need that fits our org, that fits the problem we’re trying to solve for our org.
I think you can go really big like I would actually say we probably maybe have too big of a design system sometimes or you can go really small. You can just do like the mini Bootstrap library. It’s plenty fine for most start-ups and most small companies. .
My advice would primarily to be understand what’s the problem. We have a saying around our company a lot which is, “Don’t fall in love with the solution. Fall in love with the problem,” because solutions are always going to change, but I think … and understanding what is the problem that the design system solves for your company would be what I would spend a lot of time on, and making sure you’re really clear on that, and making sure you can communicate that to other people.
Like a product, you need to have a roadmap, and you need to almost have a product manager to it, and you can have … By what sprint do you want to have X? That could be like a nice milestone. Everyone is happy. You can take that around. Say, “Look at what we did in this time.” But then, soon or after, you have to set the expectations like, “But hey, now this thing doesn’t stop. There’s another milestone and another milestone.” Even on the stuff we just did, this is a living design system, so if we learn new information that improves upon that, we’re going to change it.
I think some executives can think of like in design just seem like, “Okay, cool. So, you work on this for a couple months, and then we’re done, and it’s all good? Awesome.” I think it is important to set that expectation of like, “No, we have a milestone we’re going to hit, and you’re going to see some success from that. But then, this thing keeps going.” Setting that expectation early is crucial.
