On this sponsored episode of the podcast, we talk with Demian Borba, Principal Product Manager, and Kelvin Nguyen, Senior Engineering Manager, both of Intuit. We chat about how their design system is evolving into a platform, how AI keeps their brand consistent, and why a design system doesn’t have to solve every use case.
Any large organization with multiple products faces the challenge of keeping their brand identity unified without denying each product its own charisma. That’s where a design system can help developers avoid reinventing the wheel every time, say, a new button gets created
On this sponsored episode of the podcast, we talk with Demian Borba, Principal Product Manager, and Kelvin Nguyen, Senior Engineering Manager, both of Intuit. We chat about how their design system is evolving into a platform, how AI keeps their brand consistent, and why a design system doesn’t have to solve every use case.
Treating a design system as a platform means providing a baseline of tokens—colors, typography, themes—and allowing developers to deviate so long as they use the right tokens.
Alongside a company-wide push towards greater AI usage, Intuit’s design system team is beginning to leverage AI to help developers make better design decisions. As an example, they’re including typeahead functionality to suggest possible solutions to design decisions.
The team is using a Figma plugin to manage a lot of the heavy lifting. Their presentation at Config 2022 built a lot of excitement for what’s possible.
Congrats to RedVelvet, who won a great question badge for The most efficient way to remove first N elements in a list?
Find Kelvin and Demian on Linkedin.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. Today we have a great sponsored episode brought to you by the fine folks at Intuit. I am here as I often am with my colleague and collaborator, Ryan Donovan. Hi, Ryan.
Ryan Donovam Hey, Ben. How are you doing today?
BP I'm doing well. So the focus of today's episode is going to be talking a bit about design systems and language and how when you're working at a big sprawling organization you can tame that and make it work across multiple organizations through code and AI at scale. We have two great guests who are coming on the show today. Demian and Kelvin, welcome to the Stack Overflow Podcast.
Kelvin Nguyen Thank you.
Demian Borba Thanks for having us.
BP So Demian, let's start with you. How did you get into the world of software and technology, and what led you to your role that you're at today?
DB Oh man, it's a long story, I’ll try to keep it short. But I'm 41 now, originally from Brazil, living in California for the last 15 years. My beginnings in technology started in computer science at college and everything, but it really started with Flash. I spent 10 years of my career designing and developing on Flash for agencies and it was amazing. And then I went to a big hackathon in Vegas in 2011 I think, and it was like 3000 developers. It was probably one of the biggest ones in the US and we ended up winning it. So after that, Blackberry saw it –they were a big sponsor– and then I became a developer advocate for Blackberry, later PayPal, and I joined Adobe as a product manager in 2015. I helped build something new from scratch, one of the very unique apps that were born inside Adobe. And almost two years ago, I joined Intuit as a product manager, also focused on design, design systems, and always super passionate about developers and everything. But yeah, that's my short story, but a lot of ups and downs in the journey.
BP Yeah. I used to work at The Verge covering technology and gadgets, specifically smartphones, and there were some colleagues of mine who really carried a torch for Palm or for Blackberry and they stuck with them to the bitter end. I don't know if you're carrying a torch for Flash, but great technologies in their time for sure.
DB Yeah, 100%.
BP So Kelvin, how about you?
KN Yeah, my story's a lot more clichéd. I have a very clichéd engineering Silicon Valley journey. Went to school and grew up in the Bay Area, studied computer science. Intuit was actually my third college internship at the time, so I went to Intuit, did my internship here. I worked for the– at that time it was called the Intuit Partner Platform, so third party services, API platform, all that good stuff. Really enjoyed my time here at Intuit so I came back to work full time in engineering and I was working on a new flagship product for Intuit at the time called QuickBooks, Capital now, and I was one of the founding engineers on that team. And it's now like a 600 million revenue business, so it's a really great product and team to be a part of.
BP Do you get a percentage of that or that's not how it works?
KN I wish I did, but it comes with the territory, I guess.
BP Fair enough.
KN But yeah, did that for a little while, wanted a change of pace, went and tried some other things, worked at other companies, did my own startup for a little while. COVID had me sort of reassess some of where my priorities were and one of the things I was always fond of was my time here at Intuit, and so I found a great opportunity to kind of rejoin the Intuit Design Systems team here and it's where I met Demian and been working on some really cool stuff since then.
BP Very cool.
RD Well, we're here to talk about design systems. Stack Overflow has a design system and I've worked for companies that had pattern libraries. So what are the challenges that these large companies face that makes them turn to the design systems and other ways to kind of unify brand?
KN That's a great question. Well you should know Intuit is, I think, a 40 year+ company at this point now. We've been around the block for a while, and because of that our products have always evolved and changed to adapt effectively to how consumers decide to use all the products that we facilitate out in the world. The transition from desktop software to web software to now more mobile based software, et cetera. And one of the things that has sort of been a great outcome as a result of our growth and being around for so long is that we now serve hundreds of millions of customers. And what's been really a challenge for us, and really a challenge for any organization this big, is how do you unify the visual language for what you are trying to build? How do people associate all of our flagship products with each other to sort of align back to what is Intuit’s brand and our ethos and our values and et cetera. And so the Intuit Design System was formed to sort of help facilitate that. How do we ensure visual consistency, ensure the same brand identity, and also at the same time still empower all of our product teams to really provide their own character and even their own unique, for lack of a better way to put it, their own sort of charisma to the products and the values that each of our sub-products preach. Credit Karma might speak to a different subset of users than maybe some of our QuickBooks counterparts, and so how do we maintain that visual identity in our brand while keeping things very characterized for the audience and the users that they serve?
BP So as you set out to build this, where did you start from? Was it the architecture of how you're going to do it? Was it the language of the platform? Was it, as you pointed out, the essence of the brand itself?
DB Yeah, I was going to just compliment a little bit on Kelvin's point. Developers really hate to repeat the same thing over and over. They're always trying to automate processes, any opportunity to make it better. And as development teams grow to 1,000 or to 10,000, that desire, that hunger really grows. And also from a business perspective, every big company tries to improve processes and optimize and really focus on productivity. So our design system really helps there. It avoids really creating duplicates. In theory, it's this beautiful thing that everyone follows and it really helps the business, but in reality, there are a ton of challenges like political challenges and technology challenges. In our case, we have different business units. They're very independent, so we're dealing with different tech stacks, we're dealing with different design styles, and they are serving different customers. I'm a product manager, Kelvin is an engineering manager. Our main customer for IDS, for Interdesign System is the internal developer and the internal designer. And eventually we want to have more presence outside as well. But now answering your second question, this whole idea that we're talking about today about the infrastructure that we have in place and everything, really started with us stepping back and really getting closer to our customers. So we spent months just running research and speaking with all these customers, designers, and developers, understanding their pain points, prioritizing the problems that they mentioned, we watched them work. And Intuit has this internal process called Follow Me Home that started decades ago, and even before Design Thinking was a thing. It's used until this day, so every new employee has to follow a customer, not in a creepy way, but really watching and capturing pain points and finding opportunities to improve. Really we are allowed to spend time really understanding the problem and the why's behind the problem, and that was the beginnings of everything.
BP So I guess, yeah, I'm really fascinated by the way you put that. What were some of the sort of political or organizational challenges that you were able to identify and then solve? And how does technology, whether it's AI or code, help you solve problems like that at scale, break down the silos and make sure everybody, like you said, feels empowered to be able to automate and save time, even while maintaining their own identities?
DB Yeah, that's a great question. I really feel our customers are always trying to find better ways of developing, of shipping code and really running the business. But because in our reality our business units are very independent, you can imagine different teams, some new, some old, running different tech stacks, different processes, different customers. So it was very, very challenging for us to really create something that could be used by everyone. So that was one of the biggest findings. So instead of acting as a dictator and saying, “Hey, you have to use this or that, this version of this component library or this Figma library,” we decided to serve them the best way possible. So we are doing all the hard work and we can talk more about the infrastructure, but we are doing all the hard work of, let's store everything in one place, let's make sure that whoever is consuming the system can get that information in a very contextual way. So a designer using our Figma plugin working for QuickBooks will only see QuickBooks information. They will not be distracted by TurboTax or Mint. It's really contextual. It's very easy to switch a theme. There's a lot of infrastructure work there like tokens and all that to make it all possible. But we are trying to contextualize that consumption experience as much as possible. And then there's the other smaller audience, but super critical audience, which is the system editor. Every business unit has a smaller team that has designers and developers. They're responsible to really maintain the system for their business, and we are also serving them and we have tools and all that.
KN One thing I wanted to echo from Demian's statements is, as you know, engineers don't like to repeat themselves. And so one of the biggest things too is, at the same time, what engineers don't want to spend time doing is reinventing the wheel, but also they want to make sure that the tools and the components and the libraries that they use are predictable and adhere to sort of the standards and rules that they're familiar with. There's going to be situations and times where the stuff that the design system provides to our engineers might not best fit their needs, whether it's an edge case we haven't accounted for, or there's something about it that just doesn't quite fit their needs. And so really our biggest shift within our Intuit Design System is to really not try to solve for every single use case and every single product and every single team's design principles, but we really are trying to do a shift more to a platform strategy within our design system. I think that's something that's very different from what a lot of enterprise companies are doing with their design systems. And what I mean by establishing a platform system is, we provide a baseline of components. We provide a baseline of themes, foundations, style guides, et cetera. But if folks want to deviate from that path, or if teams want to deviate from that path, as long as they adhere to the same tooling, the same infrastructure, and the same principles that we preach, we're all good for it. One of the large guiding principles of design systems are tokens– design tokens in particular. Design tokens are considered the source of truth of every design decision ever made in a design system, which is colors, typography, foundations, place gapings, et cetera. And so if a team wants to deviate from the components, for example, that we provide them, as long as they use the tokens underneath the hood to build the UI widgets or components that are most compatible for them, that's cool because they're still adhering to IDS, or the Intuit Design System at the end of the day.
RD Can you all talk a little bit more about how AI plays into this? I think for me that was one of the most interesting things, having seen the pattern library and design system and wondering how AI can help unify that in a large organization with a bunch of products.
DB Yeah, the same way that we are incentivized to really explore the customer need and really spend the right time doing the research, Intuit has this huge focus on AI across the whole company. We are always trying to unify or make all the technology available to everyone that's working at Intuit, and one of the things that any design system, or I would say any AI, to work well with is some sort of pattern, some sort of structure that will help the AI make all the decisions. So a design system is extremely critical for that, at least in the beginnings. And then there's a lot of customer-facing tools and internal tools that use AI to accelerate our processes. So we are in the beginnings of that process for the design system. One example is that we are now bringing to IDS that type ahead kind of functionality for input tax fields. It was created by one team and now we're promoting it to IDS so a lot of other teams can consume that in a more standardized way. So that's going super well. And again, I just wanted to highlight that the same freedom that we have to get closer to the customer, we have to explore and build things for AI cases.
BP Kelvin, what you said about giving folks the sort of freedom to build things that work for them as long as they stay within certain parameters is really interesting to me. Ryan and I interviewed some folks from Spotify recently about their backstage tool, and one of the things I thought was most interesting about that was it was about a large organization. You don't always know who owns what within the tech stack, but you want to be able to easily identify that and make sure that you can find the information you need or make a change without breaking something. And they allow folks to build sort of plugins and then the plugin takes you back to sort of the source of truth with the owner. So as folks are doing what you mentioned, maybe changing up to an individual component that's more useful to them, but adhering to the token. Are there orbiters of that? Do they have to put in a pull request and get it approved by a certain person? Do they have to run it through a review process? How much freedom do they have and how much is that sort of gated to make sure nothing breaks or nothing goes too far outside, doesn't color too far outside the lines, if we're going to use design terms.
KN Yeah, that's a great question. I sort of see two aspects of the question as, one, how do they adhere to the design guidance, and two, how do we as an engineering organization ensure that we're sort of not keeping tabs, but are understanding and seeing exactly the type of changes that they're making. So I'll answer the latter first which is on the engineering side of the coin. One of the things that's really unique about Intuit is that we have sort of operationalized to an extent a lot of the services or UIs or plugins or web apps or what have you that are being built within the entire organization and ecosystem. A great example is, let's say you're a team building a brand new UI component. We have a data lake where effectively anyone who builds a new asset, and an asset in this case could be a component, library, or a node module or whatever, all its metadata gets persisted and funnels into this data lake. And what this means is that even anything that it depends on, any dependency depends on, so things this component might actually rely on, let's say they're building a brand new text field type ahead component like Demian alluded to earlier, they need to use our text field component in order to make that happen. Just by specifying that dependency in their project and deploying that code, we get to see through the data lake which assets and which other teams and components are using the libraries that we have provided them. And from them, that's how we provide this sort of governance model, but also ensure and provide support where we need to to folks to make sure they adhere to the parts of our system like, are they using tokens internally, which tokens are they using, et cetera, et cetera. So we provide that kind of rich metadata internally to keep things like checks and balances in order. And on the design side of the coin, maybe Demian can speak more to this one, but to provide a bit of a summary there, we have effectively a steering committee within the Intuit Design System team. And every large product unit like QuickBooks, TurboTax, et cetera, they all have representatives from each of their organizations for the designers that represent each of those organizations that we call embedded designers. And they all meet regularly to sort of discuss and see what X is on the radar, what are things we need to be looped into, hear proposals we want to make, to team on something we want to uplevel to the actual Intuit Design System, et cetera, et cetera.
DB Yeah, that's true. And this is where things can get a little tricky. When I mentioned political, we all know design is subjective. So anytime a design decision is needed, if you run it by committee, things can get really slow. So we are learning as we go. So in this journey to start serving our customers even more, we created this big infrastructure that instead of running locally on someone's machine, all the transformations, all the storage is behind our API. So we have this design API that stores everything and it will serve Figma in our plugin for Figma, and it will serve a VS Code extension that we're building for developers in VS Code. But one recent learning that was pretty interesting is that a couple quarters ago we decided, “Let's work with one business unit and let's bring their mobile components to IDS in a way that it can be shared to all the other business units.” And then we learned that that worked for that specific business unit, but other business units were not consuming it because the tech was not matching the tech stack, so it was just not possible. So what we're doing now, pivoting in this scenario, we are developing a lot of the components, and we're developing also a very solid contribution model. So we have processes for both design and development. So the idea is, let's promote our components in a way that it can be used by everyone. It's teamable, it can run in different stacks and all that. And then if people find something missing, there is a process for them to contribute to. There is a way for them to add their code, their design, to make into the system. So that's what we're doing now.
RD You've talked a lot about the collaboration. Obviously design is a lot of collaboration. How do you do that sort of collaboration on new items like if there's a new component needed? Or if there's a merger/acquisition, how do you get new things into the system?
DB It's easy. Right, Kelvin?
KN No, these are very good questions and these are problems that we're actually tackling on a regular basis and we are refining these things as we kind of go along. I think as Demian mentioned, one of the things we were able to do recently was, to even give anecdotal evidence, there was a situation recently where the concept of a table, if you think about an HTML table, that's something that's existed forever, right? But tables run the show for a lot of the products we have internally. QuickBooks uses tables everywhere, for example. TurboTax uses tables. A team came to us and was like, “Hey, we built a table. How can we actually up-level this up to IDS to ensure that this is something that's become standardized within the Intuit Design System that anyone can now use?” Because they built it to fit their use cases, how do we up-level it to fit the use cases for some of our other products? That was a big component at the end of the day and required a lot of coordination, required a lot of design specs and et cetera. And for that it was really a great learning lesson for us to really understand what are all the nuances that are involved with up-leveling something this large to other products and other teams, but also what does this contribution look like for someone on the developer side of the coin and someone on the design side of the coin, and even someone on product who wants to implement something using this in the future. And so to Demian's point earlier, what we've really done is we use this exercise to really craft this contribution model where, in its MVP form it’s in right now, not to get too much into the details, but you could think of it kind of like a Typeform sort of setup where it's like, “Based off the current path that you're on in terms of the type of level of contribution you want to make,” and that level of contribution can be like, “I have designs but no code. I have code but no designs.” We sort of help guide the user on a path that best fits them and take them to the right folks within our organization and team to kind of help them figure out that next step. Design but no code? Okay. Have you reviewed the designs with our design team? If so, let's review it with the engineering team to see what's next. If the code's ready, cool. How do we review the code first and then take you back to our design partners to make sure they know everything coming down the funnel and we have accounted for all use cases, all businesses, all themes. And so that's something we're also figuring out as we go along, especially I think with the latest acquisition we made with MailChimp, that's something that we also like investigating and looking into and et cetera. So it's a learning process, but I think we have a solid plan to scale this out long term.
BP I was going to say, I had read up a little bit about your bios and see a few things in your backgrounds, but just curious, outside of work or as inspiration, what are the things not related to work or software that you find inspiring from the design front? Are there things that you take inspiration from or are particularly interested in?
KN Great question. I think in today's modern age of 2020+ software, design has become sort of a minimum requirement now to really go from zero to one. I think in the early days, in the early 2010’s or even earlier 2000’s, it was very highly experimental. People threw things on the wall to see what stuck. If you have read The Lean Startup or understand Lean Startup principles, there's a lot of theories around what does it mean to build an MVP? How do we build something minimum viable, maybe even unappealing, but can solve a subset of problems for a user in the best way way possible. And I think we've hit this juncture point where a lot of the principles that we preach are still valid today, but I think there's this even higher bar now from a visual consistency and visual design standpoint that needs to be met in order for someone to even consider adopting whatever it is that you're trying to build. I think that's something that I've been really much more interested in understanding, and really understanding what does it mean to build an MVP in 2022? I can't just ship a half-baked product in Times New Roman on an HTML page and people will find that acceptable today. Maybe not.
BP Yeah, I like that idea. We're in a funny new era where interest rates are going up and down, and my dad said, “Ah, you should buy some treasury bonds now,” and he sent me to Treasury Direct. And I mean the website has not changed since 1999 or whatever and it was hard for me to trust it, to believe that it wasn't a spoof site, because it doesn't fill up the whole page, it's in these awful colors, and you just think, “I'm supposed to give my money to this and this is the government?” Without design, it's very hard for me to want to utilize that product.
KN There's sort of a credibility factor I feel like tied to the design of something you ship nowadays. And not to be cliché, but in today's era of short attention spans, if something doesn't catch a user's eye immediately and provide value immediately, you're dropped instantly. And so that's been I think a huge area that I'm also trying to explore more and understand more what it takes to build something minimum, viable, but also nice looking.
DB Yeah. To me, I'm fascinated with product management, and to be super honest with you guys, our design system as a product is still looking for product market fit. We're not there yet. We're getting amazing signals. The Figma conference that we presented, now the VS Code extension that we're building, there’s a lot of excitement there. But making something that works, making something that people want, is extremely hard and it takes a ton of iterations. Shipping, really pushing that to production, is just the beginning of it. There's so much more that needs to happen, and the only way to get there, as we learn here and I think we're closer and closer, is really by understanding the problem, deeply iterating, and really good design, simple workflows. It's almost like survival. If you don't do that, you're going to die as a product. It’s that simple. It's much harder. But again, shipping is just the beginning. That's my biggest thing. It takes months and years to get to adoption.
BP All right, I like it. Shipping is just the beginning.
[music plays]
BP All right, everybody. It is that time of the show. I am going to shout out someone who came on and helped us spread some knowledge around the community. Today, I will give a shout out to Red Velvet who was awarded the Great Question Badge. You get a Great Question Badge if your question gets a score of 100 or more. “What is the most efficient way to remove the first N elements in a list?” It's always the most basic questions that go on to help the most people. In this case, 165,000 people, so we appreciate it, Red Velvet. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us, podcast@stackoverflow.com. Or if you like the show, leave us a rating and a review.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find the blog at stackoverflow.blog. And if you're looking for me on Twitter, you can find me @RThorDonovan.
KN So my name is Kelvin. You can find me on linkedin.com/in/kelyvin, or on Twitter @Kelvicthrust.
DB I'm Demian Borba, Product Manager here for IDS. And you can find me on LinkedIn, Facebook, Instagram, Demian Borba. And we can talk about design systems and surfing and product.
BP All right. Well, thanks to both of you for coming on. And everybody who's listening, we appreciate it. We'll talk to you soon.
[outro music plays]