Many enterprise organizations face the challenge of scaling their design systems as the scope of product support expands through adoption and acquisition. In this episode of the Design Systems Podcast, host Chris Strahl speaks with Will Rodenbough, Senior UX Designer at Avalara, about the critical role of design systems in enabling scalability and supporting a growth-by-acquisition strategy.
Key Topics Covered:
- Scaling Through Systems Thinking: How Avalara's design system harmonizes diverse products across its growing ecosystem.
- Supporting Growth-by-Acquisition: Strategies for integrating acquired companies into a unified design system.
- Collaboration and Accessibility: Ensuring stakeholder alignment and prioritizing accessibility as a foundation for scalable design.
Listen to discover how Will leverages design systems to drive scalability and growth in a multi-product organization.
Guest
Will Rodenbough is a Senior UX Designer based in Seattle with over a decade of experience working at startups and industry-leading tech companies. He has been the design lead on the Avalara design system since its inception in 2018, collaborating with teams across the company to provide scalable and accessible solutions that emphasize a thoughtful balance between consistency and flexibility.
Transcript
Chris Strahl [00:00:00]:
Hi, welcome to the Design Systems Podcast. This is the place where we explore where design development and product overlap, hear from experts about their experiences and the lessons they've learned along the way, and get insights into the latest trends impacting digital product development and design systems from the people who pioneered the industry.
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 tell us what you think, send us a message over on LinkedIn. You can find a direct link to our page in the show notes. We'd love to hear from you.
Chris Strahl [00:00:28]:
Hey everyone, welcome to the Design Systems Podcast. This is your host, Chris Strahl.
Just a quick housekeeping thing before we get started. One of the things that I want to basically highlight for the new year we're going to be running our design system leadership summits. You can meet folks like Will there. Our next one's in Atlanta, Georgia on January 30th. The one after that's going to be back to San Francisco. We're actually co-hosting it with Figma in their offices on February 27th. Hopefully be able to catch some of you all there.
You can register at Knapsack.cloud/events.
I'm here with Will Rodenbough from Avalara. Will, why don't you talk to us a little bit about what you do for a second?
Will Rodenbough [00:01:00]:
Yeah, sure. So I'm a senior UX designer on the design system team at Avalara. They brought me on board to kick off their design system and I've been kind of leading the design side of that project ever since, for about six years now.
Chris Strahl [00:01:17]:
Tell me a little bit about like first what Avalara does and why. Your position in a design system for this company is interesting and somewhat unique, of course.
Will Rodenbough [00:01:28]:
So Avalara is, you could call it a lot of things, I guess it's a B2B. It's a SaaS to fintech software company and their products are all about tax compliance for businesses. So they have a variety of web-based solutions and a ton of integrations as well that all have to do with from a business perspective, ensuring that you are charging the correct amount of tax on the things that you're buying and selling and then other tax-related features as well.
Chris Strahl [00:02:00]:
So what makes your particular position as you know, standing up, managing the design side of a design system for what is ostensibly like a fintech company that is focused on SaaS. What's kind of unique about this?
Will Rodenbough [00:02:14]:
Yeah, one thing I think might be A little bit unique about Avalara is that they focused a lot on acquisitions as a way to grow the company. So when I was talking to Avalara back in the day when they were hiring me, they were like, hey, we're acquiring all these companies and we're starting to try to think about how they're all going to play together and integrate. And so a design system was something they were starting to get interested in as an important part of that strategy. Something that's been interesting about working on the design system here is thinking about the fact that Avalar has acquired, I think, over 20 companies and how those are all going to be managed in terms of the UI and how that affects the strategy of the design system.
Chris Strahl [00:03:00]:
So I think this is really cool. And for me, this is one of my favorite, like go to hair on fire problems of why you need a design system where when you think about how you take a digital product ecosystem, that is something that you control. In the case of Avalara, you have the design system that powers the homegrown Avalara products, and then you also have these people that from business reasons you want to bring into your ecosystem. How do you do that and how do you do that in this, like, fairly responsible way? Because now what you're doing is you're not just saying, like, we're making something in order for us to design and build our own software, we're making something that has to work with a lot of different kinds of software in a market that could potentially become a part of our ecosystem.
Will Rodenbough [00:03:48]:
Yeah, I think there's even more parts to that conversation too. The part about the main product that we have, you know, not necessarily using the design system. And how do we get that into a place where it is taking advantage of the design system alongside any other products that might remain independent or that might be brought into the main product itself. So there's a lot going on there, right? Yeah.
Chris Strahl [00:04:12]:
I mean, you have to get your own product using your own design system as well as, like that expression into all your new products. And then like, like you said or alluded to, there's some of them that just aren't going to be a fit. And so what does that look like?
Will Rodenbough [00:04:28]:
Yeah, well, I think at Avalara, I mean, it's hard to give a super concise answer to that, but I think at a high level, we've approached it incrementally. So looking at the main Avalara product, it's not like we set aside an independent team and that team, like built A new version of the product that used the design system or anything like that. Right. We've introduced solutions over time. And so you start to see design system solutions being used in the main product and that can help with other products that haven't been integrated yet. Understand how that works, not only from an engineering perspective, but what the outcome is in the front end and all that stuff. So we can start looking at the main product as an example of how the design system can be used and why it's helpful. That's really helpful for sure.
Chris Strahl [00:05:23]:
Peel back the layers there a little bit. When you talk about like we tackle this incrementally, let's talk about that relative to your product. Because when I think about like the implementation of a design system, you think about this planning phase that everybody goes through about like, hey, what is a component? How are we going to define that component? What purpose is that component going to solve? How do we then go about building this component and then implementing a product and that has this design to code pathway that then gets included in the build of an ultimate, like engineering level product?
When you think about then like how that incremental iteration around planning to develop works for products, you have, you have this additional confounding complexity of like products we don't have. And so in that like incremental way that you described, take me through really specifically, when you all are thinking about a pattern or a component in your system, what does that decision process look like? Is that like we build for us first and then we think about everybody else? Is all of that considered up front? How do you structure it knowing that the thing you're building is going to ultimately be used in a product that your company doesn't own Today, the way.
Will Rodenbough [00:06:35]:
We usually handle that is one thing is we do sort of prioritize the main product to some extent in that we want to make sure we are really confident that whatever solution we're adding to the design system is going to work well. And we've talked to those people on those teams to make sure we're in alignment about the solution working for them. But in terms of thinking about how that's going to work for, you know, more products and acquisitions and whatnot, I think the way we handle that is pretty much we just, we talk, like you said, we have a few kind of phases of the design process for the design system. We kind of have like the research and exploration phase. Right. And then what I think of as maybe more of the middle phase is where someone like me will design some proposals and then we have a big feedback meeting, we grab other designers and product stakeholders and we walk through, you know, kind of the research we did, the proposals that we're narrowing in on and basically suggesting we should move forward within the design system. And then we talk and we collect feedback and we iterate. And what we do is we always make sure that those conversations include stakeholders from our main product because oftentimes the long-term goal is for other acquisitions to become a part of that main product eventually.
But we also have like certain times where we'll be working on a design system solution. And we know that it's like a hot topic right now on a certain team or in a certain part of the company. It's getting a lot of attention and it's going to be an important deliverable from a user's perspective. And so all the time we'll pull in other folks too. If we know they're particularly involved in this component or deliverable or if they've already been working on it, we've kind of touched base about it a little bit to make sure that it's going to work really well for them too. And it's, you know, it's a give and take. We learn what they need and we kind of help think more systematically about how this is going to scale across other products and things like that. So we just have meetings, we talk, we make sure that people are feeling good about the things that are getting into the design system that we're asking folks to use.
We just try to have conversations with the people that make the most sense given whatever problem is that we're focusing on.
Chris Strahl [00:08:57]:
So in this case we have like the description of the lifecycle process, right? You have this early upfront UX research and then you get into that kind of middle phase that you were describing where you're sort of drawing the box around the component that you're building. And that's the point that you have this engagement of stakeholders where it sounds like, you know, priority one is the product you have, which makes a lot of sense. But then there's all of these sort of like secondary stakeholders that you invite into the process based on their ability to, you know, have a bigger stake than average in the creation of that particular pattern. And then like when you think about that acquisition side of thing, do you have like somebody from those companies if you know you're going to acquire them, like join that conversation? Do you have like this eye towards, oh, hey, you know, we're building a component, it's a data table Component. And right now that data table component is modeled out to a maximum of like six columns. And oh, shit, we just bought a product that needs 12 columns. Like, how does that gap between that plan and implementation, like, when that hits reality, what happens?
Will Rodenbough [00:10:06]:
Yeah, so there's a couple things that come to mind for me there. So one of them is kind of an essential part of the process that I think is particularly important is that early research stage. And one thing I do there is anytime we're in the early stages of working on something in the design system, I reach out to a broad audience of product team stakeholders and say, hey, we're working on this solution for the design system. Something that's really important for us is to gather a bunch of examples of how that kind of a solution is already being used in the products. Not only the main product, but also other separate products as well.
Chris Strahl [00:10:45]:
Look at, like, competitors and stuff like that too, and how they're thinking about using their products.
Will Rodenbough [00:10:49]:
So that also. So all the different internal Avalara products, we say, hey, like, do you have anything like this going on in your product? Like, send us screenshots. So then we have a catalog of, like, this is how eight of our products are handling, you know, alerts or whatever the component is. Is right. And we can sort of see all the features that people are using and start to analyze, like, is there opportunity to consolidate? Or like, what are all the things we need to account for in the design system? And we can talk to those teams about, you know, coming to some unification there. And then there's another part of that that came to mind too, which is there are some times when an acquired product team is kind of ramping up to make a more concerted effort to merge or migrate their UI to either the Avalara main product or just kind of do a refresh to make it look like the other Avalara products. Right. And the design system team has helped those teams during those processes.
Sometimes, like, kind of, hey, can you speed level me? Like, give me a sense of, like, what I should be focusing on. And sometimes I'll. We'll knock up, like, examples. We'll workshop through things together and say, like, here's what you have right now, and here's maybe a rough idea of how I imagine translating that into using the design system might end up looking like. Of course it's not. Doesn't have to be exactly like this, but here's some translation ideas.
Chris Strahl [00:12:12]:
Yeah, And I can imagine that works really well when that's well received, when that's like the intention. Right. Do you ever get it where you, you end up with people that are just like, no, I don't want this or I'm not interested in this. And like, you know, what happens in the case where there's, I guess, a more reluctant adoption of a design system?
Will Rodenbough [00:12:30]:
I don't think I've had too many experiences like that. I think usually by the time I'm involved, there's already been sort of a higher level strategic conversation around the fact that, hey, like this is an important initiative and, you know, there's already momentum behind it. And I'm just there to kind of help with the more specific nitty gritty details of like, okay, we're doing this thing. Is there somebody that can sort of help guide us through this process? Just since I'm familiar with the system, it makes sense for me to jump in and help those folks and make sure everything goes smoothly.
Chris Strahl [00:13:01]:
This immediately makes me think, what happens if that product has a design system? Is that easier or harder if they already have something that they've implemented?
Will Rodenbough [00:13:09]:
Oh, that's really interesting. I'm not sure that's come up or at least hasn't been brought to my attention yet. It's also interesting too because like when a company says we have a design system, what does that mean? Right.
Chris Strahl [00:13:19]:
Right. All sorts of different shapes and sizes of that.
Will Rodenbough [00:13:22]:
Yeah. So I guess I have heard similar things along those lines. But I think a lot of the acquisitions that I've been involved in have been slightly smaller companies where if they do have a design system, it's not something that's as robust or at the scale of the Avalar design system that I work on. So just kind of given that it's like the umbrella company that acquired this company, I haven't really experienced too much pushback or friction with that. I think usually people are pretty understanding.
Chris Strahl [00:13:53]:
Hey everyone, I'd like to take a quick break and tell you about Knapsack's leadership summits. Every month we host an exclusive in-person event in different cities all around the country, bringing together design, engineering, and product leaders.
These summits are all about sharing our learning with tailored discussions to address the challenges you're facing. Head over to Knapsack.cloud/events to find an upcoming summit near you and apply to join us. We'd love to see you there.
Chris Strahl [00:14:26]:
So you have all these different things that you've planned. You go through that process. When you're thinking about that, you also look at like other implementations and other products.
Presumably you take a moment to Think about like the potential harmonization of those things. But then when you acquire a product, you have a really solid basis of a system that is highly emphasizes flexibility. And in that high emphasis of flexibility, you look at that acquired product and you say, we want to roll this into say our main application. And in rolling it into your main application, you try to implement this highly flexible design system onto that product. How long does that take and what sort of planning versus reality conversation often happens there? I imagine being like, hey, we're gonna get 80% of this newly acquired company using the design system and fully integrated into our product. I imagine that takes time and I think most organizations think about that on a scale of like multiple years. How do you all think about that?
Will Rodenbough [00:15:18]:
Yeah, it definitely isn't something that's super quick. In my experience, sometime on the design system team, we jump in and we help out with these conversations, but we're rarely kind of along for the entire journey from the decision to start migrating the UI to the point where that's live to customers. Right. We usually hop in and help for a couple meetings for a few weeks here and there. And then it's kind of like you're on your whatever timeline you're on over there. But in my experience, it is typically kind of piecemeal. Right. Like in the main product and another product, it's not like, here's the new version, it's like, what can we tackle? You know, maybe this quarter that's like the high priority items either that are really misaligned or that are just really prominent workflows for our users that we want to be looking crisp and matching and using the design system and all that.
And then what are some lower priority items that either maybe aren't covered by the design system yet, in which case it's like, well, of course, you know, do what you can, or that maybe just aren't going to have as much impact translating to the design system and maybe that we can follow up with those later over time as we have capacity, or we can just do it advantageously in whatever other way.
Chris Strahl [00:16:34]:
So have you ever run into the situation where when you're acquiring another company and you're taking a spin through that product, that you're like, man, that's a really good idea. We should adopt that and make that a component in our design system, like has that acquisition pipeline every ever just enhance the foundational part of the design system?
Will Rodenbough [00:16:54]:
I'm sure there are things, yeah, looking at all different kinds of products that are in a similar space is helpful to see how different folks are handling similar potential design system solutions.
I mean, I can think of like one from a long time ago which was we acquired this product and they were using a side nav and at that time Avalaire had a top navigation and it was just helpful because I was trying to encourage us to migrate to a side nav to see like, hey, look at this company we acquired. They have this like pretty cool side nav and has all these features and advantages. And to see that somebody that's in such a similar space that we acquired them already kind of had that thinking in place, I think was a helpful motivator to get us to get more interested in side nav, in the design system and in the main Appleware product.
Chris Strahl [00:17:41]:
That's awesome. That's a great example of a story where you get this moment of feedback in kind of an unexpected way. When people think about feedback, they think about it as somebody had a complaint or a comment or something to contribute. The idea of an acquisition being feedback into design is pretty interesting.
Will Rodenbough [00:17:59]:
I think it's one of the most helpful examples that you can present in those design feedback types of conversations. Because in my experience, people love to talk about examples. They're like, oh, I don't, I've never seen that before. I see that all the time. Or it's common or it's uncommon. Right? And especially with design systems, we want to focus on things that people feel familiar with that we can use consistently. Right? And if you just pull a random example of like, oh, this product, maybe the person you're talking to knows it, maybe they don't, maybe they feel like it's relevant to our company, maybe they feel like it's not.
But when you pull up an example of, hey, this is the company that we just acquired, that somehow or another we're going to be integrating this set of functionality and they're doing it this way. Like it can be done, it can make sense, it can be done. Well, I think that can be a strong argument to put forward.
Chris Strahl [00:18:49]:
Sometimes when you think about the constraints this might place on you, is there anything that you as a designer or your team, as a design systems team, like, is there any territory that is constrained by thinking about this, this way or likewise, are there anything that are product constraints? And look, I know you're a designer, but I can imagine you're going and you're acquiring a company and their UI is written in archaic PHP or something like that, and then you have to go and adopt that into a modern JavaScript stack and some of the challenges that presents from an engineering perspective, are there similar ones from a design perspective where you find yourself thinking about constraints differently in the definition of your own system and then what constraints come up when adopting that system in a new product?
Will Rodenbough [00:19:35]:
Yeah, in a general sense. I mean, we do have some constraining factors. Sure. Right. Like again, back to nav. You know, we have like a nav service that kind of drives the page hierarchy of everything going on in the product and that's a part of the design system and that's built into the design system SDK. So in order to, for example, go from being an independent Avalara product to integrating into the main product, you're going to have to sync up your nav sort of approach with how it's structured in the main product, not only on the front-end, but on the back end as well. So things on the front end, like we have a certain approach to navigation where you have an icon for like high-level pages, not for secondary pages, things like that.
We often kind of sync up on how that's all going to work on the front end and the back end. There's other things, like accessibility is a big one that we always talk a lot about. Right. Like, regardless of which Avalar product it is, oftentimes we'll have conversations about things that we might like to do or that we're exploring. And then there's an accessibility limitation there. I don't know if limitation is the right way to think about that, but we have strict constraints that we want to meet and we feel passionately about that. So that ends up being something that comes up a lot and that we have to come up with new ways to do things sometimes than just the original idea.
Chris Strahl [00:20:48]:
So does that land on your all's plate as a design system team or is that something that is ultimately like the engineering team that is incorporating and acquired products? Like say you buy something that is not accessible, like at a fairly foundational level. Is it then your responsibility to say like this is how this could become more accessible, at least from a guiding standpoint, or is it something that, like.
Will Rodenbough [00:21:11]:
That's pretty much independent sometimes in like an indirect way. So the way that works is accessibility was one of the early things that I had identified that we could really lean into in the design system as a way to get it into the product. Right. So we've been really strict about accessibility and we had like a third party accessibility consultant come in and help us do like an audit and make sure everything was like really done. Well, and so what happens is anytime somebody has a question about accessibility, oftentimes the best answer is use the design system, because that's already like, basically guaranteed to be super accessible. If there's any solution that meets your need there, that's already going to be taken care of, not only on the design side, but on the engineering side as well. Those are kind of the conversations that come up during an acquired product migrating into an Avalara product. We can say, hey, you don't have to worry so much about accessibility for everything that's in the design system that's already taken care of.
So that's kind of the quickest and easiest route probably. Rather than trying to solve accessibility on its own on a case-by-case basis.
Chris Strahl [00:22:17]:
Do you ever have moments where you wish that you were free of some of the constraints that you face in your system where basically say, like, I could make this better if only if I didn't have to think about all these other potential products that we would bring into our ecosystem. And I mean, I know you're a systems guy, so, like, fundamentally, systems people tend to think about and prioritize the idea of constraints as an enabler of better design. Did you ever have those moments where you're like, man, if only it wasn't this way?
Will Rodenbough [00:22:46]:
I tend to like the system thinking, and I think it's so helpful and important that it's not often a mindset I find myself in at my job. However, when I think about other projects, like, if I was just designing something for fun or like it didn't have anything to do with my role at Avalara, then yeah, definitely, right. Like, it's fun and it's creatively exciting to be able to just do whatever you think makes the most sense or looks the best or meets whatever criteria you're trying to make it meet. Right. Without having to be like, oh, what's the rule? What's the guideline? What's the design system thing here? Sure, I can totally understand that. But yeah, when you're thinking about this conglomerate fintech web ecosystem of things, it's hard to have that mindset. Right. Because it just doesn't really make sense when you look at the company overall to just go off and do something completely independent.
Rarely is that something that hopefully very many people would get behind. Right. You want it to look and feel like it's a part of the overall Avalar ecosystem to some extent at least.
Chris Strahl [00:23:50]:
So I kind of want to wrap this up with thinking about a really cool success story here. Right. And I think that we talked a lot about, like, the planning and the implementation side of this, but, like, what does this look like when it clicks and when it works? And also, like, what does it look like when it doesn't? How do you all accept that feedback and bring it back around again?
Will Rodenbough [00:24:12]:
Sure, yeah. I think I can think of an example that maybe touches a little bit on both the success and not so much kind of at the same time. So we've been working on a strategy in the design system for how to migrate our product from top nav to side navigation, and we've kind of had a solution available for some time, but actually getting that to be integrated into the product has taken a lot longer than we initially anticipated. And that's been like a learning experience in terms of, like, we had all these plans and all this stuff, and it all kind of gets pushed back. But it's been a good thing too, because during that time, we've continued to collect additional feedback on what we think is working well and what is not with the side nav component in the design system. Everything from user research to just internal feedback. We've also discovered additional engineering complexities around the solution we designed that we've been able to really optimize during this time. And so we're hoping to launch that sometime soon in the product.
But having that extra time to really focus in on the details, I think has ensured that it's going to be even better than it would have been had we launched it on the original timeline. So that's been a cool experience.
Chris Strahl [00:25:30]:
Well, awesome. Will, thank you so much for being on the show today. I really appreciate your time. Your thoughts, really great to get kind of a unique take on the value of systems and how they work. So I just want to say I really appreciate you being here.
Will Rodenbough [00:25:41]:
Thanks, Chris.
Chris Strahl [00:25:42]:
Hey, everyone. This has been the Design Systems Podcast. I'm your host, Chris Strahl. Check us out if you're interested at Knapsack.cloud and wherever you can find your podcasts. Have a great day.
Hey, everyone, thanks for listening to another episode of the Design Systems podcast. If you have any questions, topic suggestions, or want to share feedback, go ahead and reach out to us on LinkedIn. Our profile is linked in the show Notes.
As always, the podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. Have a great day, everyone.
