Tony Pantello and Chris Henke, Senior UI/UX Designer and Developer
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 the pod. We'd love to hear from you.
00:00:21 - Chris Strahl
Hey, everybody. I'm your host, Chris Strahl with the Design System podcast. Today I'm here with Tony Pantello and Chris Henke. Tony is a Senior UI UX designer and the product team lead over at AccuTec and Chris is his developer counterpart. A senior UI UX developer. Welcome to the program everybody. You guys have the distinction of being a Knapsack customer. We don't talk to customers all that often on this show because it is really about the stories in the community. But in this case your guys use of Knapsack is fairly integral to the story and so we are going to talk about that a little bit. We're trying not to make this about a sales pitch but want to definitely recognize up front that you all are customers and really appreciate your investment and.
00:00:59 - Tony Pantello
Work with us 100%. Yeah. Outside of the platform, the onboarding and helping us thinking through as we were so new to Design Systems, kKnapsack was a critical component in that. And so again, outside of just providing the tech, the education and guidance that you guys provide, we wouldn't be here where we're at right now if we didn't have that. So thank you upfront for that. Awesome.
00:01:25 - Chris Strahl
Well thank you. I think that this is an interesting conversation because we talk to a lot of really big companies on this. We tend to be really about large enterprise use cases. You all are definitely a sizable business, but I wouldn't put you in the same category as Meta or something like that. And so I think that it's interesting to kind of talk about what adoption of a design system looks like when you don't have a company of 25,000 people and a huge amount of resources behind you. And so I think that this is an interesting sort of callback to a time both when you all were in a little bit different place in terms of a design system and your company was in a bit of a different place in terms of its size and its growth. So maybe tell me about how all this got started.
00:02:10 - Tony Pantello
For sure, yeah, I was hired about three years ago and at that point AccuTec did not have a designer, we didn't have a designer in our history. And so outside of integrating that discipline into our product workflow, what I realized really quickly, just given the volume of designs and the volume of apps that we had was like, if we don't somehow systemize design, I didn't know how we were going to keep up. And so that was honestly probably the first conversation around design systems that we had was how do we extend my impact so that I'm not redesigning buttons and grids and form fields over and over again for folks? What does that look like to systemize it?
00:03:02 - Chris Strahl
So you were really experiencing that pain of having to build and then rebuild over and over and over again really acutely. And you felt like there was basically no way you could keep up if you had to continue with a more traditional non system space process for this.
00:03:19 - Tony Pantello
Correct. I think the thing that we realized early on, we're in the fintech space, a lot of our applications are operationally driven. And kind of what I was mentioning before, our applications, at least from a UI perspective, aren't terribly diverse. It's heavy on the form fields, it's heavy on graphs and charts, it's heavy on grids and data display. And so the conversation started about like every team were segmented into different product teams. Each product has its own set of developers, QA, A, PM. And every team just was building their own components. They were building their own UI. Some are using bootstrap, others were using other libraries. But we quickly learned that we're solving the same sort of UI patterns over and over and over and there has to be a better way, so to speak, to do this.
00:04:23 - Chris Strahl
Gotcha. So the way that the sort of core product was segmented is it's a lot of data, it's very data heavy. But then there's also multiple different products that all at the time had their own implementations of different data componentry on sort of like a per product basis.
00:04:43 - Tony Pantello
Correct? Yeah, I'd say that's fair.
00:04:45 - Chris Strahl
And so you were there trying to harmonize this from the design side and that focus on the design side of things. Ultimately, where did that lead you?
00:04:56 - Tony Pantello
Ultimately, I knew if we were going to have any success in implementing a design system, that couldn't only be about design, it couldn't only be about we need to make sure things are consistent. We had to understand and work with our development team to also talk about how would a design system affect their work, what benefits in this new way of working, putting together UI, would they experience? Because again, we knew that if it was just a design thing and not a collaboration between design and development, it just wasn't going to go anywhere. And that's essentially what a design system is. It's a place where design and development can get a little bit closer in terms of what they do and the languages and the patterns that they use. And so that's why a couple of years in, maybe a year and a half in at AccuTec, we knew that we had to hire somebody that would be full time on the development side. Because while I was leading the design charge, and folks on our development team were Excited about where the design System was going. When we hired Chris Henke, the acceleration that we had in terms Of Actually using the design system and not Just building it really took off from there.
00:06:17 - Chris Strahl
So, Chris, this is where you come in. What did you see when you first joined the organization and what were you really hired to do? Was the job role like, you're going to go work on the design system, or was it broader than that?
00:06:27 - Chris Henke
I think initially it was to come build and help create this design system. My background is all front end development. And so I think a big thing was let's build out these components in ways that make it possible for our product teams to use them and to facilitate building the products in a more unified way, but also quicker, because they don't have to worry about building some of these components from the ground up, over and over again. So that was the main thing of why I was hired. Initially coming in, I think my initial impression was just there was a lot going on. There was a lot to figure out. When you're hopping in multiple products, multiple teams are using different things, trying to understand who's, where and what. So there was just a lot to kind of digest and understand where people's skill sets were, what was actually needed. And also it was a bit of a language change for me, going from react to view not like crazy different, but it made a little bit of a difference. So there's a lot to digest. But Tony had a lot of good things set up already for us.
00:07:28 - Chris Strahl
I love the focus on sort of the fundamental aspects of design systems here, where you all had a scalability challenge of being a solo designer, a solo engineer on the design system side of things, trying to figure out how to scale across products. You were also trying to look at how do you make this more maintainable, more consistent, and ultimately a more efficient process for building software? So when you first sat down to take on this challenge, you had Tony that had sort of laid the groundwork, got buy in, got a hire done, and now you all are sitting there looking at a lot, and I imagine it was a little bit messy. How did you go about breaking that down to actually make a manageable process for building this stuff?
00:08:15 - Tony Pantello
I think the first place that we got started was doing a component audit. We looked at all of our applications, we looked at their individual pages, and we identified I remember having a graphic, and this is a typical graphic that's associated with design systems, but I remember pulling up a visual of all of our buttons, right? And all these different shapes and sizes, all these different colors and the visual inconsistency was one thing, but the way that we talked about it, I think that really grabbed people's attention was that each one of these buttons represented design, time represented development time represented QA time. And so while, yes, they all looked a little bit different, the time savings of looking at that is really what hit people from A, this is not just a thing to make things look more consistent, although that's an added benefit. This is a thing that's going to save us time. And that really was, I guess, the concept that I think truly got our leadership on board. My boss was very supportive of the idea the entire way, but it wasn't until, how is this going to change our process? That leadership, I think, really started to understand, okay, we're not just making things look better, we're building an infrastructure that's going to serve us in the long run.
00:09:46 - Chris Strahl
Yeah. And that idea of ROI based on efficiency, based on cost savings, the added benefits of better software, less QA, fewer defects, those sorts of things, that represents a pretty compelling case that ultimately lets you get resourced. And I love the idea of you all sitting down and looking at the interface inventory cluster of a button. I think that that's one of those infamous AHA moments for most organizations, especially in the design side of things, where they're trying to understand for the first time, like, oh, all this stuff that gets built out there in this really unconstrained way, all of it has a cost. And being able to see that presented in front of you, that tends to create a lot of light bulbs. And also it's fun because you get to discuss how hard naming things is.
00:10:33 - Tony Pantello
Yes. I think just from a color inventory, I remember we had something to the effect of 70 blacks or grays. And so, again, while color isn't going to be something that's like, oh, this is going to drastically change our process, that's 70 different palettes of somebody when they're changing the color of a paragraph or whatever, it's just like that was another indicator of like, okay, maybe we do have an issue.
00:11:04 - Chris Strahl
Yeah. You guys remember that show Archer, where he's like, he tore his turtleneck and it's the black one or the slightly darker black one? That's what I always think about. Definitely our prop culture references on the show definitely date me. But anyway, so you guys go from this initial sort of setup. You get a baseline for this in what represents an inventory, what represents a set of components, what represents a clear ROI story for management, and then what you get to work. Was there another part of this?
00:11:35 - Tony Pantello
Yeah, the technical part was a challenge at that time because myself, I've never worked on design systems previously. Our developers at the time didn't work on design systems. And so it was a bit of trial and error with these different platforms. Out there like, we tried Storybook, had some success there, but realized quickly that this is a whole nother language that we're building within Storybook, and it's not necessarily an actual rendering of a component from a repo. And so I don't remember exactly when I heard of KKnapsack to begin with. It could have been through this podcast. I don't know. That would be very meta.
00:12:24 - Chris Strahl
Where did you all go learn about this stuff, right? I mean, this is now three years gone, but where were you looking for information about these sorts of things?
00:12:34 - Tony Pantello
Yeah. Again, I'm not sure. The first time I heard about a design system, I think one of the first early videos that I watched was the Brad Frost Atomic Design and the way that he broke down components. And I think he was the one that first really introduced the concept of a design system to me. And from there I was sold immediately. It was like, how do we build this? I think, you know, ultimately when we heard of KKnapsack and got connected with you guys, outside of explaining or providing the platform to facilitate sort of the NDN provision of components, I think the number one thing that we learned from you guys in that process was that the goal here is not just to build the thing, build the design system. High five and say, we did it. The goal here is to change behavior, to change the way that we build things. And so while making progress on the system is great and having all these components, if nobody's using it and nobody's finding value in it, what did we know? Spend our time on it's, just getting dusty on the bookshelf. And so when Chris came along, I think that's when, again, the momentum of not just building the system, but his working with the developers to see, okay, this is how I use a component, this is how design tokens work. That's when I think the behavior change really started to gather some steam.
00:14:24 - Chris Strahl
So talk to me about that a little bit, Chris. What did that early collaboration look like? Because you were both sort of newbies at this effort, I don't think either of you had actually built a design system before you'd found some software. You kind of liked it. Hopefully you really liked it. And then beyond that, you started collaborating around how you create something that's actually usable. I think that's a really hard problem because you haven't built this sort of thing before. You're using new software that also happened to be from a startup company, and you're trying to build something that ultimately was going to be used by every engineer in your company. What did you start with on that? How did you tackle that?
00:15:04 - Chris Henke
Yeah, I think we tried to start with some stuff that was a little bit basic, like more core stuff, like a button, and really understand, okay, what do we need to do on the simplest piece of a component that we can think of. How do we just communicate how this gets used, what are the functions, how do we make this so that it has the props or whatever data attributes it needs so that it can be used by all the product teams, make it themable so that all the functionality is the same. Because we talk about costs of design, but there's also user experience costs that we want to make sure that we're impacting as well with the design system and so making sure that we are doing that well, there was a lot of just kind of working back and forth. To start with. We were working mainly with a single product team and getting feedback from them. It was some of the developers that were working on the design system initially. They were on that front end committee before I was hired and so we were able to work with them quite a bit and just get an understanding of what was needed for the component, how it should interact and do those type of things. So it was a lot of back and forth really of just iterating through implementation, testing it, seeing how it worked for them and going from there and making enhancements.
00:16:24 - Chris Strahl
So what did that process look like? With KKnapsack, you all were relatively early adopters of the platform and so you guys have been using it longer than the majority of companies that are out there. And so when you first got started with like, how did you introduce a new tool to a team even just within that first product?
00:16:43 - Chris Henke
Honestly, I came in and Knapsack was a thing already so I was somewhat introduced but as we went through it was just how much documentation did we need because with what we were building, Knapsack offers a ton of development documentation. You can change props in different data and see what it's going to look like. So it was mainly just making sure that we had a process and a way to make sure that development teams, product teams knew what components were available per release. Because at that point we had multiple product teams pretty quickly wanting to use components from the design system, but we only had very few components. So we were in this chicken and egg thing of like we have to build a design system so that the product teams can use it, but we also can't slow the product teams down from developing to build components. So we were doing our best to make sure we got components in. Yeah, our sprints were two weeks down to one week and we were literally releasing components as quickly as we possibly could and trying to get as good as documentation as possible that allowed product teams to work. And then as we got bug or enhancement tickets, we'd work and try to work those in. But mainly we're trying to get new components out for the first little while.
00:17:57 - Chris Strahl
So it seemed like adoption was actually pretty straightforward for you all. People were stoked on this.
00:18:02 - Tony Pantello
Yeah, I would add that the portion that Chris just talked about, how we introduced it really just to one product first, I think that was an interesting idea. I'm not sure who suggested that one, but it was sort of a non pressured environment where this team essentially was just our guinea pig and we got to show off the results. And then the other teams, it wasn't like we were forcing something on them saying, hey, you have to implement this. They were seeing this and was like, oh, that makes a lot of sense, or a developer was sharing maybe their experience and other developers are like, Kev, that's cool, maybe we should work on that on our product. And so I wouldn't underestimate that rollout because again, I think people would be much more receptive to it if they're wanting to try it, versus the product design team coming up on high and saying, this is the design system, you must use this, so to speak. So I think that was a huge component of it.
00:19:04 - Chris Strahl
It's pretty cool to be able to not really have a ton of design systems experience, to not really know exactly what you're building, to be wondering if you're going to be able to get the adoption that you're hoping for, but to have this visionary idea of where that value lies, right? You knew there was value out there, now go get it. I think it's pretty amazing that you all basically jumped in with both feet and said, we're going to go build a system that does all this stuff, that fulfills all these promises. And it seems like it worked.
00:19:39 - Tony Pantello
Yeah, it's definitely picking up steam. As Chris mentioned, there are still some challenges with keeping pace in terms know our product teams are working on crafting these new experiences and new products. And with that we say, hey, we have this component library we'd love for you guys to use, but we don't want you to retrofit something if it's not the best experience. And so folks are always coming back with folks on our product teams with different so, you know, when we talk about success of the design system, I don't think it's something I personally take all credit for. I don't think it's something that Chris takes all credit for. The credit really goes to everybody involved because again, this is about changing a collective behavior. And so like for example, in our daily huddles, we have a daily design system huddle and we have a representative from every product team that joins that. And so we're talking daily about the component updates that we're making, but they also have the opportunity and the voice to contribute. Hey, we're really thinking about this. What do you guys think about this use case and things like that? So it's almost the more people that we got involved, the faster I think the adoption went, so to speak. And I guess that's obvious, but the more people that they had felt like they had empowerment and a say in what we were doing and not, again just being told to use this thing, I think the more positive environment was created around it.
00:21:26 - Chris Strahl
It's one of the sort of tenets behind what we think about with our software is this idea that contribution matters. And the reason why contribution matters is it means that you've democratized a part of your process. You've made it so that people that aren't the core design systems team feel comfortable making a contribution. Now, whatever form that takes, right? It can literally be like a feature request that's a contribution of sorts. It can be a support request even like, hey, I use this thing and I couldn't figure out how to do this. And then the ability to take that support request and make a doc out of it or improve something about your system. One of the things I love about your story is it sounds like the more people that got involved, the more the system evolved to meet the needs of your user group more broadly. And those needs obviously were around how do I adopt this thing and how do you guys move fast enough to keep up with the sort of pace of adoption that exists inside your organization?
00:22:23 - Tony Pantello
Yeah, I would definitely agree with that.
00:22:26 - Chris Henke
I think it's something that for the first little while, we weren't even sure if we had it. I mean, that initial product and them kind of building the design system as they build the product worked really well. But that was a lot of like the smaller core components. When we got to more big complex components, that the second product that was starting to use the design system got into. I think there was definitely times where we felt a little bit behind it and we did everything we could to not get to that point, but we were able to modify our team a little bit and make it work. I do think with people having the mentality of being able to contribute, there was people willing to jump in and help and do things like that because there were components and even not even just like helping build components, but help with maybe some sort of research to help us figure out, okay, this is a really complex component. Are we going to build it ourselves? We have maybe one developer currently working on the design system. Is there another library that we could wrap and make it look like it fits our things? And so once we kind of had that mindset of we're not going to build every little detail right now, we don't have capacity for that. What do our teams currently using for these more complex components and what can we do to do that? I think that helped us really move forward pretty quickly in certain areas.
00:23:42 - Tony Pantello
I think from a designer's perspective, designers generally like to build the entire experience. And we generally have trouble showing work and progress.
00:23:56 - Chris Strahl
Yes.
00:23:59 - Tony Pantello
I have been known or accused by some to be a perfectionist. And I'm a recovering perfectionist. I'm working on it. But I think one of the things that I had to get over really quickly was that just given the volume of components and the different needs out there, there was no way we were going to build this complete system and then roll it out. We had to do a little bit at a time, a couple of components at a time, and try that. And so now looking back on it, that feels like the only way to do things. But if you would try to build out your entire system before rolling it out and before trying to influence behavior change, you're going to be building forever. And so you just have to start at some point, even if it is a button and a menu, you have to start at some point. Because again, it's all about the behavior. It's not about building this great library that nobody uses, so to speak.
00:25:00 - Chris Strahl
It is interesting. There is a lot of mindset, and I do see it more commonly in designers. And maybe it's the nature of design, where most things that you're going to go design as a feature, you can fit in a couple of weeks of work. There are some fairly complex designs that obviously take much longer than that. But for the most part you can get to a finished state in a couple of weeks. A finished state is potentially years out, if ever. Right? And the idea of how do I get value out of a system before a year expires, nobody has a year or two to wait before they are able to see value out of something like this. And so how do you prioritize shipping ahead of perfection? Funny enough, that's a core value at Knapsack is that particular thing. Maybe that shows up in our software.
00:25:43 - Speaker A
Maybe it doesn't, I don't know.
00:25:44 - Chris Strahl
But anyway, the idea of how do I get value out of the work that's being done, instead of only getting value when you reach an end state, I think that's an interesting concept to hold close while you're building these sorts of things.
00:25:59 - Tony Pantello
We have talked a lot about developers, but the other role in this that has been supportive are product managers. And so while they aren't building their software, our product managers tend to do just some basic wireframing and things. And now that they have a platform where they can go on to Knapsack, they can preview all the different components, they can see what they do now in their wireframes and early, early mockups. They're not just putting random ideas on a piece of paper. They're saying, okay, this is the grid from the design system. And this is the footer that we've been using. And so, for designers, that makes it a little easier in our world because we're not responsible for every single wireframe. But at the same time, when we get these wireframes, and they have sketches on there saying, this is this component that speeds a lot of things, at least from a process standpoint up in that, again, it's that shared language. When they say, this is the grid, or this is the underlying menu, designers and developers alike, we know exactly what they're talking about. And so it's that speed of communication, too, on the product manager side, that I think is another benefit that may not get talked about a ton.
00:27:18 - Chris Strahl
That's a great contrast to what you talked about at the start of the episode, where you were talking about every different product team having its own set of componentry that was trying to go build 70 different buttons and maintain 70 different buttons. I love that juxtaposition of here's, this thing that is very product centric, a little bit of a mess now. It's definitely something that people start to think about more centrally and how they can leverage that central system and the work that's come before. So it isn't Ms, it isn't their own system for their own product. It's something that is managed centrally and then can be leveraged to build stuff faster.
00:27:56 - Tony Pantello
Yeah, definitely, for sure.
00:27:58 - Chris Strahl
So now that you all have this system that is up and running, it's functioning well. You've got good adoption, you're actually struggling to keep up with the amount of requests that you have for new stuff in your system. What are some of the learnings that you would take away from this that seem really interesting because you talked about, for example, the idea of, like, we use components now to create prototypes, components to create experiences. That's a big change to a workflow. What other stuff has really changed the.
00:28:25 - Tony Pantello
Thing that we're learning? I think design systems can be definitely promoted as the saving grace of design at software companies. And while it moves things forward in a huge way in terms of collaboration, one thing that we're learning is just having components. Just having this library that everybody can conceptualize from doesn't necessarily guarantee that the end experience is going to be a solid one that users find easy to use and intuitive. And so design and designers on our team, yes, we're constantly designing components, but the other part of this is educating folks throughout the company on the design discipline in general. What makes a good design, what usability patterns do, we try to encourage and try to avoid. And so the interesting metaphor that I use a lot is I can go to the store and I can buy all the same ingredients like a five star chef could buy. But if you've had any of my meals, you would quickly learn that I am not. A five star chef. And so I don't mean to tear design systems down a little bit. I think it's just keeping the right expectation of this solves more of an infrastructure sort of challenge. It doesn't automatically mean all of our designs are going to be pixel perfect and the experiences are going to be awesome. So that's just what I would add to that.
00:30:06 - Chris Strahl
That's funny. It's also it's a three star chef.
00:30:11 - Tony Pantello
I don't know. I thought they had five stars.
00:30:16 - Chris Henke
Amazing.
00:30:17 - Chris Strahl
Yeah. No, it's funny. So a part of this is also like, teaching people how to cook, right? Like teaching people how to be more thoughtful about the work that they're doing. And so I love that. And I think a big part of this, too, is that there is some movement in our disciplines.
00:30:35 - Speaker A
Right.
00:30:36 - Chris Strahl
I think know, Chris, you probably think about design more now than you did three years ago. And I bet, Tony, you think about what engineering is going to do with your designs a lot more now than you did three years ago. And even if it's not necessarily like we're going to entrust Tony to go code a bunch of components in view to do something new as a feature, at least understanding how that process works and having respect for it is, I think, something that is still fairly new in our industry. And we tend to gloss over that a lot on the podcast and elsewhere about just how magical that is. To have a designer think about the design decisions that happen on the code side and a coder to think about the effort and the thought process that went into that design, that's collaboration, that's democratization, and that's doing it at scale with systems. And that's sort of the magic of all this.
00:31:32 - Chris Henke
I think it's a huge thing as a front end developer. For a long time, you work with designers and they don't think about performance or anything like that until you build out what their design shows. You built it and it looks nice, but the performance is just not there. Maybe the accessibility is not there. Lots of different things. But in this process, we figured out so many of those things. And it is it's just so nice, the collaboration, to have a designer that can think through it from a development side. Not that they're going to write the code for it, but that they have an understanding of. There could be performance impacts, there could be accessibility things here and there. Those things are already thought through, or we've already had a conversation about it before I ever have to do any development. That's massive saves us so much time.
00:32:14 - Tony Pantello
And just earlier today, me and one of our designers on our team, we were reviewing a component that she was working on. And a lot of the discussion was about she had one way she was building it, and there was a different way that we could build it. And the discussion was about which is going to make a lot more sense from a development side, which is going to mirror sort of how they think about things. And so the conversation, I guess this goes both ways in terms of trying to understand each other's discipline. I recently read a book, I think it's by Jeff Gott Health. It's called Lean UX. One of the chapters that I found interesting, he was talking about phases. We're so used to phases when we're building know, we have the discovery phase and research phase, and then we have the design phase and then we have the development phase. And part of the concept that Design Systems has helped teach me a little bit is like the less phases that you can have, the better. So the more that people are working on the same thing at the same time versus throwing something over the wall and saying have at it, that's another benefit. Doesn't necessarily relate to the design system in general, but relates to how we build products as a team. And so I think the design system has in a subtle way, helped people think about, okay, we can work on the same thing at the same time. It doesn't have to be so phased and separate and siloed in our work.
00:33:52 - Chris Strahl
Fewer handoffs.
00:33:54 - Tony Pantello
Correct.
00:33:54 - Chris Strahl
So much gets lost every time you talk about a handoff. Yes, and I think that it's so powerful to use systems to solve that problem.
00:34:03 - Tony Pantello
I would agree.
00:34:05 - Chris Strahl
Thank you both so much for being on the program. This has been great. Also, thank you for being customers. Love having you all as a part of our growing group of kKnapsackers. So I do appreciate you all so much. Thanks for sharing your experiences and your thoughts. And let's have you guys back on again another time.
00:34:19 - Tony Pantello
Let's go out for a five star Chef meal.
00:34:23 - Chris Henke
Absolutely. Thanks for having us, Chris. It was really good.
00:34:27 - Chris Strahl
Hey, this has been the Design System podcast. I'm your host, Chris Strahl.
00:34:30 - Tony Pantello
Have a great day, everybody.
00:34:32 - Chris Strahl
That's all for today.
This has been another episode of the Design Line Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter at 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.
00:34:48 - Chris Strahl
Have a great day.
