This week we are joined by Nick Hahn to explore how designers, engineers, product managers, and entire organizations have changed the way they think about and work with design systems. Nick shares insight from his experiences at IBM, InVision, Meta, and Bill.com to highlight the importance of collaboration, governance, education, and cultural adoption. Join host, Chris Strahl and Nick to understand how design systems evolved and what’s next..
Check out our upcoming events.
Guest
Nick Hahn has spent 20+ years working in the design industry. He specializes in the human side of Design, building scalable systems and operations for some of the top brands in the world, including IBM, Meta, and Bill.com.
Transcript
Chris Strahl [00:00:00]:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at thedspod. We'd love to hear from you.
Hey, everybody, welcome to the Design Systems Podcast. I'm your host, Chris Strahl. We're doing a very special series of episodes. We're all here at Config, hanging out in a recording studio about two, three blocks from the conference center. So today I'm with Nick Hahn. Nick, welcome back. Really great to have you.
Nick Hahn [00:00:37]:
Yeah.
Chris Strahl [00:00:37]:
So is it config or config?
Nick Hahn [00:00:39]:
Config. Config. Config. Jam. Figma. I think it's. Config is where I'm waiting.
Chris Strahl [00:00:45]:
So that's how I've been saying it until last night. And there was a whole table of Figma people that were kind of, like, across the room from us, and I wanted so desperately to ask them, but I don't want to spoil it. So we're going to go through four episodes today, and we'll see what everybody says, and then I'll release what it actually is at the end.
Nick Hahn [00:01:04]:
We'll do a vote and then figure out what the Figma folks actually say.
Chris Strahl [00:01:07]:
So what I wanted to talk with you about today was this interesting place that you found yourself in, and we've had many conversations. You've been on the podcast a couple of times, and we've always kind of talked about these concepts about design systems. But recently you joined the team at Bill, and as a part of that career change, you're now, for the first time, I think, in this position where this is a design system that you have a very direct, very deep hand in, and you're sort of the guiding force of the build design system. And that's a big change over where it's been previously. Why don't we go back, at the risk of repeating ourselves, and talk about when you first really were using design systems back in the IBM days?
Nick Hahn [00:01:48]:
Yeah. So 2015, 2016, we didn't even know we were doing design systems. It was just like a, hey, there's carbon. Carbon design system exists. I was managing the cloud platform design team, and a big part of that was we were a huge consumer of carbon we realized that there was this thing called the carbon design system, but we were using it in a way that was a bit more complex, a bit more nuanced. We realized there was like a need for what we now know as system of systems. And then I just had this realization that we need to put structure around it in a way that didn't exist. We need to have operations and tooling, and it can't just be this library of assets that we expect everyone to use in a similar way.
Way. And I had that thought process come out seven, eight years ago. And now today, im actually being able to execute on that.
Chris Strahl [00:02:33]:
Yeah. And so when you were looking at carbon in those early days, you were a consumer of that system. And so you were using the carbon design system to build a thing and ostensibly contributing back to it. It was the very early days, nobody knew what to call these things. I think we called it component driven development or something like that back in the day. But on that consumer role, what were the things that you learned being the one that took the design system and made a product with it?
Nick Hahn [00:02:57]:
We learned that if you give 20 teams the same lego pieces with no instructions how to put them together, theyre going to build random crazy stuff that all looks kind of the same. Cloud wasnt just a consuming team. We were 150 products, I think 70 designers. We realized we needed a system for ourself that they couldnt build and manage. We needed to build and manage a system that tied into carbon. There was actually a trend at the time where the carbon team and IBM design as a central organization, was trying to shut down splinter factions of people that were taking carbon and running with it and doing crazy stuff. And we were trying to build something that integrated with and used carbon, but also extended it in a way that worked directly for us. Trey.
Chris Strahl [00:03:37]:
Yeah, that's interesting. And the driving force behind that, it's fascinating to think about that evolution of those early days of the carbon design system where, you know, for a while I think that, like, on the front page of the website for carbon was like, fork this. But I think that, like, that mantra internally at IBM, from what I gather, was like, no, no, no, don't fork this. Like, use this.
Nick Hahn [00:03:57]:
It was fork this. And then two years in, they were like, oh, shit, we created a monster. Now there's all these things living all over the place that aren't carbon anymore, and we have no way to actually create consistency and cohesiveness like we thought we would. Yeah.
Chris Strahl [00:04:09]:
And, I mean, this plays out in a really interesting way, in a more modern take. But at least for the purposes of IBM, you ended up in this place where you had your own specific needs within the cloud team, which were varied and like you said, multifaceted these 150 products or something like that, right? And so you had to take this system that ostensibly was upstream and then implement that. It's no surprise that people think about it in the same way they think about material or they think about all these other different big design systems that are out there, is that this was an adoption of a bunch of content, and then where did it go from there?
Nick Hahn [00:04:41]:
Well, material is a great example. And I think when we looked at things like material, that's for a consumer brand and independent developers taking that and building things that they want to build and experiences that are encapsulated within their own space that just have a similar UI to the other apps on the Android platform. We were trying to build single user journeys that crossed multiple of those 150 apps. You have a shopping cart kind of experience. We'd have five or ten of those. And one user is trying to go through multiple of those just to buy one set of servers. Cloud capacity. The experiences were broken.
They were all using carbon, but the experience was broken putting structure around that. We actually called our team governance at the time. We created a governance team which became now what we know it as the cloud pattern and asset library. What we realized is that was a subsystem of carbon, and we helped establish the model of what a subsystem looks like. And we did it all through people. We kept everything updated through manual efforts. We didn't have any systems to keep that flowing. That initial vision was like, we can build this thing, we can work directly with the carbon team because we sit down the hall from them.
But if you remove any of these people from this equation, it's all going to fall apart. And I think as soon as I realized that, I was like, we need a system. And this was my big, like, of design systems. There was no one that I could find that had figured out how to build the system around this thing. The actual, like, how people interact with it, how we consume it, how we add to it, and how do we all kind of stay in the same lane while also enabling creativity and growth.
Chris Strahl [00:06:14]:
Sometimes people think about that as a service model or as a governance architecture. And, I mean, governance is a dirty word in a lot of design organizations.
Nick Hahn [00:06:22]:
We fought that fight for months and months, and we finally convinced everybody that it was the best word. And people got over there like, I don't want you telling me what to do? And they're like, thank God you're telling me how to make the button so I don't have to build another goddamn button.
Chris Strahl [00:06:33]:
Yeah, exactly. And it's funny, right? Cause, like, nobody likes the enforcers until they show value. So there's the design system police we've talked a lot about on this show. But when you actually think about what those people are doing by talking about things in terms of governance is they're setting up a way of working. And that way of working should be flexible enough that people can do what they want to do, but also provide them value in the form of standard ways of working.
Nick Hahn [00:06:57]:
Yeah, well, okay, so I'll jump to the future conversations happening at work this week. We just rolled out updates to our header component. Like the type size for our header. It's in test right now. We have teams that are looking at that in tests and going, oh, my God, this header's giant. My text got huge. What happened? Why did this get so big? Well, we standardized everything to h one, h three, h six. It used to be random.
It was just like somebody picked small and that was some random type size, right. So we standardized it. We knew that would be a conflict. We had designers coming to us and going, can you please just tell us the standard, what is the appropriate size that things should be so that we can build consistent experiences? And I think the tone has changed in a lot of companies. A lot of designers now I'm seeing, want to be told these are the bounds in which to play in. And, like, design is within constraints. Right? Like, we're not just out there doing art. We're actually building something for a purpose and has constraints.
And so there might be a knee jerk reaction to, like, don't tell me what to do from my art school background. We need to, we need to put structure around it and we're not being jerks about it because we're building it with them. Right. It's like co created with them. Yeah.
Chris Strahl [00:08:01]:
Nobody actually wants to choose one color out of millions. People want to choose one color out of a couple of dozen.
Nick Hahn [00:08:06]:
Yes. Or four, right?
Chris Strahl [00:08:08]:
Yeah. I mean, ideally it's fewer than a couple dozen, but the evolution is really interesting when you think about like, okay, so you have this thing that you did that was ostensibly a content change to your design system. Here's the new header. And in that new header, you know you're going to break a bunch of things, but the service model is there to catch those broken bits and say, like, this is actually how you should be building this the right way. And I think that when people talk about, like, design system ambassadors, when they talk about office hours, when they talk about all these other different things, that's what they're talking about, is the service model that is on top of the design system. And I think that you got to also see this very much firsthand when you were at invision, which I think you had a stint ad meta in between those, but when you were doing that work in design, as a consumer of a design system, you then went over to a company that had a significant portion of it that was about implementing design systems for these big companies. And, you know, you actually hired us at one point, which I think is kind of funny. It was before we were in appsackers, when we were still an agency.
You're basically like, hey, I have all these different big enterprise customers that all know nothing about design systems. Go set them all up. And that was kind of a funny place to be because design systems were still really new, and most of these big organizations were like, oh, cool, Invision has this awesome product for us that I guess we'll adopt. Talk to me about that point of view for a little bit, because you and I were in this really strange moment where design systems, nobody was totally sure this was a thing yet, but at the same time, there were all these big companies that were starting to get on board with these big rollouts of DSM.
Nick Hahn [00:09:39]:
Yeah, this is 2020, and it was the first year I saw design system roles pop up on job boards, like the title design system designer or something like that. And what I saw at Envision was these teams that saw the promise of what a design system could be or what the theory is. And like the articles out there about what it is. And largely the mistake that they made is the same mistake I got to watch happen. Unfurl at IBM, which is build a design library, and they will come centralize some designers and engineers to build out a library, hand it off to people, and they will all use it copacetically and happily ever after. And the majority of my role at Envision was a design team therapist. I spent so much time just talking to design leaders, helping them through the people part of design systems and how not to fall into that trap. Most of them still fell into that trap.
Chris Strahl [00:10:29]:
Yeah, I think pretty much everyone did.
Nick Hahn [00:10:30]:
Yes.
Chris Strahl [00:10:31]:
Right. I mean, I remember doing a very large bank implementation on behalf of invision and going through a ten day workshop process with them. And at the end of that, I think that the person that was the product sponsor got it for the first time, and they were just sort of shell shocked. They're like, oh, we have to change the way we work to be able to use this. And this isn't just something that you just pick up and run with. And I think that's been, honestly, a really hard barrier for a lot of design system adoption. And when we talk about adoption, I rail against the adoption metric because I kind of hate. But the idea of why adoption is so important is because adoption is more about a service model than it is necessarily about the content of the design system.
Nick Hahn [00:11:14]:
I'm glad you brought that up. So in my new role at Bill as the product manager for the design system, I've been there for a year. I came on as the design manager transitioned to product management. We are currently mapping out our okrs for the next fiscal year. One of our key metrics, fortunately, unfortunately, has to do somewhat with adoption. We won't go into that because I know that's a trigger for me, but one of the other big ones is we're doing an internal CSAT score, customer satisfaction score. I know there's a lot of, like, qualitative stuff that happens in the design system world, surveys and things like that, but it's. We.
We ran our first baseline this last quarter, and to be able to get our CSAT score and show our executives, and they go, oh, that's not good. That's really like, we wouldn't allow a product to ship if it was that bad or we'd have major emergencies going on. And it's not like the people hate the design system. There's clear gaps in the system of the design system, and they're pointing out the parts that are gaps. And so when you run and you get those metrics, then executives can go, oh, we got to put some energy into this, and we have to fix the people side of it, the system side of it, not just build more components, not just put more engineers on it.
Chris Strahl [00:12:20]:
It's fascinating because the idea of design systems as a product, this somewhat less in vogue than it was maybe two years ago, but there are still a lot of things that we need to do that represent product like metrics attached to this stuff, because the idea of showing an executive, here's a really bad CSAT and have them be like, oh, man, we need to put energy into this, and we need to put cycles in this because like you said, we wouldn't ever let this ship. Why is that an acceptable quality bar for a design system? And I think that there's a lot of this that is about the funding race and the like, how do we spend money, and how does the organization invest in these sorts of tools and everything like that? It's actually why knapsack as a company exists is because when you think about those sorts of experiences, you don't actually want to focus on the tech. There's this really interesting sort of anecdote where Evan, my co founder, and I, we had just built our first really big design system, like full blown rollout, and it was, you know, eleven month long project, and this was when everything was still bespoke, and it was for a big health insurer. And as we were delivering that project, the launch party happens, and we all hang out, and Evan and I are having a beer afterward, and he just kind of like, wipes his brow and he goes, I never thought that people would be this big of a problem. Yeah, he's like, I think the tech is maybe a third of it. And we wrote a lot of glue code in that project and, like, took a bunch of things that were super bespoke and sort of stitched them together into this Frankenstein monster of a design system. And that's kind of how things were done circa 2017.
Nick Hahn [00:13:52]:
I want to tie in my experience from IBM and envision and what we're trying to do now at Bill, and there's a piece of this that doesn't get talked a lot about, but I think plays into the whole ecosystem, and that's learning and education. As a former consultant myself, a large part of my role was to educate my clients and the people within the client, the company. At IBM, they did such an amazing job at rolling out enterprise design thinking, and they built this massive training program, badging systems. It became a corporate wide goal for every employee on the products teams to become enterprise design thinking practitioner certified. They did pretty good. That was a clear metric. We were rolling that out. But what it did is it got everyone speaking the same language.
They all knew what a hill was, they all knew what these words are, and they knew why. We were running workshops and envisioned there was such a huge training program that was built in. Our mutual friend Richard Banfield was a big part of that mission to build out the education part of it. I was part of the team that helped deploy that and help bring people into it. What we're doing now at Bill is part of our next fiscal year plan, is to build out some sort of internal certification program specifically for the design system. And when I brought that up and brought it to the team, as a possibility, all the light bulbs went off. They were like, this solves like, why don't people listen to us when we make an announcement about the change coming down? Because they don't really understand how that's going to affect them. And then they go into app test, you know, three weeks later and go, what the hell? This all different.
Like, why did this change? Why my headings all messed up? And so that piece is such a huge piece that gets missed. And so the change management aspect, the training and education, the interesting part about this, I've learned so much in the last couple of years around actual learning design and applying proper learning design to enterprises is something that a lot of consultants, a lot of these teams that are running that are trying to do change management, they just completely miss. It's like they're in the back burner. They're like, oh, yeah, we'll get to it. We'll throw up a video, a training video at some point.
Chris Strahl [00:15:38]:
Yeah, we're going to do a, you know, a quick hit, like, here's a highlight reel, sizzle reel for ten minutes about why you should care about your design system.
Nick Hahn [00:15:45]:
Yeah. So if it's 30% tech, it's 70% something else. A big chunk of that other something else is not just getting executives excited and building out the stuff and building out the systems and getting tools like knapsack and just using all these things. It's actually training people to understand this is the new way of working, and this is how you leverage the assets that are here now.
Chris Strahl [00:16:03]:
It's funny, I get a lot of criticism from the venture capital world, et cetera, about having so much of our work that is still attached to services. A big part of the reason why is for people to be successful using knapsack, you have to go through an implementation, and that implementation is essential. We somewhat infamously don't have any sort of self serve program, largely because what we would find is people just weren't successful if they didn't have a model to follow. And so, I mean, we eventually will probably get back to some sort of like, hey, you know, click try me on the website. But the reality of it for right now is that most people don't have the ability to explore a blank canvas, like a design system, and actually be successful on it.
Nick Hahn [00:16:44]:
Let's talk about the future, like, looking 12, 24, 36 months out. What might be the situation when teams have deployed multiple design systems, have had multiple failures, and now have started to learn the language. I use car analogies and manufacturing analogies. A lot. Right? Love it. You know, we're essentially asking people to go from, like, bespoke craftspeople building cars to, like, people that now work on the design and engineering teams at a car company. And then there's a factory that builds, there's different workers that need different skills. Right? We're asking people to change their perspective from, I'm building a car to I'm building the parts and I'm contributing to the parts that will build thousands or hundreds or thousands of cars.
Nick Hahn [00:17:23]:
And like, that transition, once that transition gets further along in the industry, I don't think there's going to be nearly as much time to explain to people and ramp up for products like knapsack.
Chris Strahl [00:17:33]:
It's fascinating because there is a lot of this change from the industrial revolution. There's these weird parallels, maybe with less smog.
Nick Hahn [00:17:41]:
I don't know. AI is really great.
Chris Strahl [00:17:43]:
Well, we'll get to that in a second. I think there's an interesting bit of conversation there, too. But this idea that people are getting used to building the parts, once you start to think about that fabrication of those parts that starts to have some light bulbs click, I think that the place where this goes then is like, okay, what are the business models that are then represented by these parts? And so if you're delivering somebody a bucket of legos, hey, they should have an instruction manual. Hey, maybe there should be an AI that assembles that Lego. Maybe they should just get the Lego bricks they need instead of a giant, empty, unsorted set of legos. All these have these strange sort of metaphorical paradigms to design systems. But what I'm really interested in, from your perspective, especially at bill, is you all are now in this situation where you're culminating all this learning from all the way back at IBM, where you're saying, I have two needs at bill, I have the need for some centralized piece of control and governance that manages a brand, that manages consistency, that enforces that consistency in some codified way across the organization. But then I have a bunch of different products that need to consume that system and a bunch of those different consumers.
That design system needs to iterate at the pace of feedback, at the pace of a product. And then bill also has this really interesting ecosystem that is a partner ecosystem that is a part of it as well. And I want to hold that aside for a second. But at least in that sort of two tiered structure of, hey, we have this brand system, and then we have all this implementation of this at a product level, what does that look like, and how have you kind of taken those learnings from earlier in your career and applied it to the structure and architecture of the system?
Nick Hahn [00:19:14]:
Yeah. So I think there's the systems, the physical things you put in place, the blockers constraints around what components can and can't do, and then there's the people you put in place. One of the big learnings I had at IBM was watching the advocates come out of the woodwork that want to help support and build parts of the design system. They're just random people in the product teams that are like, this is amazing. I'm going to work on this. So when establishing the new kind of paradigm at bill for design systems, the foundational piece was my very first hire was a service designer, and the intent was to build out what we now call our design system librarians group, or Guild. And those are advocates from across the business that are our representatives within their parts of the business, and they're the experts of the design system. So instead of every question from dozens of product teams coming directly to the design system, now those librarians become the first point of contact.
And because they're in that business unit, they're now representing the both needs and kind of direction that the design system wants to go in to their teams. They're the ones saying kind of yes and no to stuff. So they're putting some constraints, and they're the ones on the ground floor in design reviews, in engineering reviews, going, that's not following the system or that's an outlier. We have a need for that. They can bring that back to us. It's six months new, but we've already gotten immediate, instant feedback where librarians have become a de facto part of our conversation, where we have executives going, well, we should ask the librarians what they think.
Chris Strahl [00:20:37]:
Oh, that's exciting. This idea that you have a bunch of people in the organization that have this dedicated role to the service model, and, like, watching that become a part of the way of working, I think that that's one of the superpowers that organizations that are very successful in design systems unlock. And again, this is somewhat me fighting the adoption battle in my head. But the idea about, like, hey, you know, when people actually start to think differently about the problem space and start to refer to ways of working instead of the design system itself, I think that's a really interesting step, because that's represented this mental shift in how people should be doing their job right without.
Nick Hahn [00:21:14]:
Going down the rabbit hole of adoption as a metric. I'm a firm believer in the cultural adoption measuring.
Chris Strahl [00:21:18]:
Totally.
Nick Hahn [00:21:19]:
When are people talking about it? Are they bringing it up in their design reviews? One of the big things at Meta, I was there when it was Facebook, but the Facebook design system is so ingrained into every conversation, it's almost militant. It feels like overly aggressive to the point where you really can't like move a pixel and they're like, that's not in the FDS, is that in the FDA? It's like really aggressive. But I think some semblance of something in between where, where you've got your checkpoints in the design and engineering process, where you're coming back to the system to confirm it as the source of truth. Like look at it as a source of truth is the cultural adoption piece. And measuring that is huge.
Chris Strahl [00:21:52]:
Yeah. And okay, so just being clear, I don't hate adoption, generally speaking. I think that it's a plenty fine way of saying like, hey, like we have something here.
Nick Hahn [00:22:02]:
It's like using NP's as the only metric for your product being great.
Chris Strahl [00:22:05]:
Exactly. Yeah, exactly. And like, adoption is not necessarily the goal. Providing product value is the goal. And so there's all these different organizations that are like, adoption is the only thing I care about in my design system. My response to that is always, well, you should care about how much value you're delivering to your product, people that consume it. But I digress.
Nick Hahn [00:22:22]:
I mean, it's a really valid point. And I've always been more interested in the cultural adoption than how many pixels on the screen are powered by the design system.
Chris Strahl [00:22:31]:
So now I do want to talk about this white label system, this partner ecosystem that you all have built, because I think this represents a big evolution in the way that we think about design systems. And there's also an interesting sort of AI angle to this as well. But when you think about Bill as an ecosystem, there's the stuff you all service directly with your own products, but there's also a lot of times where you actually embed your product in another partners ecosystem. And so in situations like that, you found a pretty interesting way of using the design system as a method for making that partner ecosystem stronger, more robust, and provide a lot of really clear value to bill as a revenue center, not just a cost center.
Nick Hahn [00:23:13]:
Great. Yeah. So we've actually worked on white label systems together, right, where it's just the entirety of the system is a white label system. So the top level design system, the parent system, is completely no brand at all. The brands get consumed at a level or two below or get added at a level or two below, I've always assumed there's a bifurcation, there's white label systems and regular systems. And that's kind of my approach until eight months ago. Yeah, the light bulb went off that I realized we have a primary brand at bill. But my responsibility as the owner of the core centralized kind of parent design system is to create a white label system that then has a subsystem that has the bill brand on it and then has a separate subsystem or subsystems that can apply other brands.
And so for instance, like our partners, one, I see that as a parallel and equal subsystem to the bill brand design system with consuming tokens and consuming all those styles and specific components. But that primary parent system shouldn't change very often. This gets to your earlier question about at the speed of product versus at the speed of the design system, that primary core system with some of those base atomic components, the core building blocks that are unthemed, that doesn't need to change and can be pretty slow, be pretty steady.
Chris Strahl [00:24:26]:
Yeah, I mean that's the foundations, right? And how often do you change your fundamental brand choices?
Nick Hahn [00:24:31]:
It's the same relationship to brand. You're not changing your logo and your base color all the time, like. And so it is like the core conduit for your primary construction of the system. And then other consumers within your company can consume that and then apply themes, have their own components, but those components are based on, they now have bounds because they're not changing basic stuff like the radius on your buttons or really like core simple things that shouldn't change. So now at that top level parent system you can really bake in a lot of the governance and constraints into that and then allow the freedom to play in the subsystems.
Chris Strahl [00:25:06]:
Yeah, and I love the idea of this equality between the systems that you're building for internal products at bill that ultimately then do serve users and then this partner ecosystem. And I think the partner ecosystem in particular is a really interesting way of thinking about it. So like one of your partners is zero. And so when you go to Xero and you're going to the payments part of Xero, there's a lot of that UI that is actually Bill UI or build functionality that has adopted Zero's branding and existence in that ecosystem. And that is incredible because now what you're doing is you're being able to say like hey look, we've built this partnership. You can use all of our capabilities just the way that we design them and all our UX flows that we've tested, and we know that works and have product value, but you can do that with your brand in your product. And this is the first time I've ever actually seen that in play between two separate organizations. You see lots of House of brands, implementations of design systems where you have like some big CPG company or something like that, that has hundreds of different brands that all use the same design system.
But when you actually talk about this as like two completely separate companies that have a partnership, and that partnership is about how I take all of these really amazing things I've done in our experience and put them in their experience, that's insanely powerful.
Nick Hahn [00:26:25]:
It's actually been established for a while. The Xero partnership is fairly new and is kind of an early implementation of a new way of doing things. We have other bank partners that we've had for quite a while that are powered by our tokens. And it's a really interesting dialogue because those bank partners stipulate very specific things in the way the buttons have to be represented and stuff, which the previous architecture of our design system painfully interlinked. The way our product showed up on the bill side, we would literally have conversations like, we can't change that because the bank partners use that. It's like, but it's in our world. What do you mean, we can't change our own stuff? And so building an architecture, which is the system of systems, those parts of it are uncoupled. So the bank partners can do what they need to do, and we can match their brand, but using our components and our functionality, I guess I didn't realize how unique that is.
But, yeah, that's really cool.
Chris Strahl [00:27:12]:
Yeah, I mean, you see similar stuff at Plaid and Servicenow and a few other organizations that have similar ideas, but a lot of that is just about theming, and it's less about the actual ability to design the experience inside of a separate app. You're not just giving people, here's a form or here's a checkout experience or a billing experience, you're actually giving them your components. And that's the specific unique thing, is that there's all sorts of different design systems out there. Like, I mean, Shopify, right? That are sold as consumer products. And like, people actually bind the design system to go build their shopify site. But I haven't seen in such a way where you're basically saying, like, all right, hey, other big enterprise company. Here's our components and here's our token files. Go do the thing you need to do.
Nick Hahn [00:27:55]:
Yeah. So there's the conceptual model of how to do that that we've just talked about in detail. I get really stuck on how we're going to maintain that. We can stand it up, we can build it, we can set up those tokens, but it just becomes a flash in the pan of consistency until one person makes a change in one part of the system. And architecting the inner linkings between the different levels of the system is the part that why I'm so damn excited about knapsack, I sometimes feel like overselling. But when I had the spark of excitement about the system of systems model back in the IBM days, I got really excited. And then I immediately went to, well, this is going to go hog wild as soon as anyone makes any changes, because there's no way to bring those changes back into the core system. There's no way to link all the tokens and whatnot.
So having a tool that lets us manage that from a top down perspective and then give people playgrounds and have those librarians have space to build components and make updates to their space, they want a card with three buttons on it. Go nuts. Do it. Build yourself a variant of that card component, but it still sits within the space. And the constraints that we've set as a design system. And that librarian is part of establishing those constraints. They don't feel constrained by it because they're like, oh, we need these constraints in place.
Chris Strahl [00:29:07]:
And it's interesting, right? The way that the inheritance flows from system to system is the complex part. I think that's one of the things that, like, we've put a lot of time into thinking about. And so being able to do it with you all is really exciting.
Nick Hahn [00:29:20]:
Yeah, it's really exciting.
Chris Strahl [00:29:21]:
The one other thing I wanted to mention, maybe the last thing, but there is this idea, and I talked to this a little bit with Dave Kalija a couple of weeks ago, where when you think about the role of AI, and if we're talking about this again in our metaphor of an assembly line factory, what you're looking at is you're saying, I'm fabbing new parts, and then all those parts go in a warehouse, and those warehouses feed a conveyor belt, and there's a bunch of people on that conveyor belt that are going and assembling cars out of it. What we should be able to do is we should be able to say, I, Chris, or I, Nick, want this very specific car with this very specific package, with this very specific color and all these other things like that, and that car should be able to roll off that assembly line built exactly the way we want it.
Nick Hahn [00:30:03]:
The nuance of that is, I don't think we need to ask. I want the car with these specs. We're asking AI now to say, I want to go up that mountain. Yeah, build me something that enables me to do that on a three day trip and it can shoot that out. And that's similar to, like, these experiences. I want a customer, I want a user to be able to achieve this process on our platform. Build me seven variations of that and I can now look at those and make some choices. And then, guess what? It's already built in code.
I don't have to go work with an engineer for six weeks to get it done.
Chris Strahl [00:30:33]:
So I've been having this conversation over and over and over again lately that is about design systems as a control tower. And there's all this talk about, like, design has this big uncertainty in front of it, which is like, what is AI going to do to the way that we think fundamentally about design? And when we answer that question, one of the core questions in that is, how is AI going to change all this? And there's a lot of people that think about all these design decisions as just kibble. Like, AI is going to go like, eat all the design decisions that are good decisions out there, and then it's going to be able to sort of spit out the thing that we all request of it. But that cedes a ton of control to a robot that ostensibly doesn't have any taste and isn't a part of the bill brand or the zero brand or any of these other brands. And there's so much value tied up in that brand and the control of that brand that, yes, AI should be able to make a bunch of decisions for us, but within a set of constraints. And that set of constraints is governed by a design system that ultimately represents the leash on the dog that's eating all the kibble. And I think that there's this interesting place for design systems that's really emergent right now. And it's kind of like what you all are doing with the systems of systems model, where you're basically saying, like, we want to give iterative freedom at the last mile, that can change really quickly, that can do kind of anything it wants to do, but we also want to be able to have these methods of inheritance that maintain the control over the system that makes sure that we're safeguarding the value of that brand.
Nick Hahn [00:32:00]:
Yeah, there's an interesting analogy that comes up my amazing partner. She was a high school teacher for ten years, English. And we've talked about AI in that space, and there's a lot of, like, hubbub in the education space about especially writing. Like, AI can write stuff, so why do you even teach writing, right? She's shown me articles, and she's done it herself now, where she has AI to write a prompt or gives it the prompt, gets a draft, and then starts from there. And there's new teaching models that are coming out for schools and english teachers specifically to say, start with AI. Give it the prom. Give it the constraints, have it, write some things out, and then you doing the work to add in your flavor, your perspective, your humanity into it is the actual work, as opposed to, I just filled, you know, double lined ten pages, right? Like the metric of success was sort of adoption, right? It's just like, how much have I done? Versus am I adding value?
Chris Strahl [00:32:50]:
Do you remember that? Like, from high school and college, it's got to be like 60 pages, single spaced, and, you know, one inch margins and all that.
Nick Hahn [00:32:58]:
Man, what use wasted time. Yeah, because we were doing more work to try to meet the requirement of how much space to fill versus what are we learning? What's our comprehension? Are we out there reading stuff? Can I write a ten page that delivers a more impactful, powerful thing? That's what I think we can do with AI and design systems, right? Give it the prompt. It's got the constraints, the control tower from the design system. So it's not going insane, right. It doesn't just do everything. And then now. I mean, I've been a design manager for so many years now. How many times have we had engineers teams going, we're just waiting on design.
Why isn't this done yet?
Chris Strahl [00:33:32]:
Blocked on design.
Nick Hahn [00:33:33]:
Blocked on design. Because we're doing concepting, right? If we could take that concepting phase and turn it into a couple of hours or a day or two where we're just knocking out a bunch of concepts with AI, and then we're reviewing it, tweaking it, and going, this is the best possible flow. And now we can hand that off or kill the handoff, but, you know, work more closer than you can click.
Chris Strahl [00:33:50]:
A button, and all of a sudden it's mostly built for you.
Nick Hahn [00:33:52]:
Mostly built for you, right? And it's not taking the humanity out of it. It's letting us use our superpower, which is taking in all the other factors that you can't type into a computer, at least not yet.
Chris Strahl [00:34:02]:
Right? That's awesome. Well, Nick, it's awesome to have you back on the show. Thanks a bunch for sharing your wisdom, the journey, and it's really exciting to see what you're doing to Bill. And of course, thank you for being an appsac customer as well.
Nick Hahn [00:34:11]:
For sure. Excited for the next check in, we'll talk about how we've incorporated AI.
Chris Strahl [00:34:16]:
One last thing I wanted to bring up. I know this is an interesting week for you and just an interesting moment in a lot of folks careers at envision. You know, we're all saying goodbye to a friend, and it's kind of a funny feeling where so many of us were so impacted by envision, by that company. By the time they're being able to see a lot of familiar faces at config is pretty cool. Is there any updates or anything that you've heard about what's going on there?
Nick Hahn [00:34:39]:
Adam vision?
Chris Strahl [00:34:40]:
Yeah.
Nick Hahn [00:34:40]:
I mean, who knows? They might. Maybe they'll come back.
Chris Strahl [00:34:43]:
I saw these stickers around the conference.
Nick Hahn [00:34:44]:
Yeah, me too.
Chris Strahl [00:34:45]:
I don't know. It's a really interesting thing.
Nick Hahn [00:34:46]:
There's like a teaser or something going on.
Chris Strahl [00:34:48]:
All right, well, we'll see what that's about.
Nick Hahn [00:34:50]:
Yeah. Can't wait.
Chris Strahl [00:35:13]:
Awesome. Hey, thanks, Nick. Appreciate you being here. This has been the Design Systems Podcast. I'm your host, Chris Strahl. Have a great day, everyone.
That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter Thedspod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by knapsack. You can check us out at Knapsack.cloud. Have a great day.