In this episode of the Design Systems Podcast, we discuss the evolution of design systems with special guest Matt Weinberg, Senior Product Designer at Angi. Matt has a passion for empathy-driven design solutions and shares his unconventional career path that led him to tackle the challenge of refining and improving the design systems at Angi. He reveals how he approached the initial state of the design system, identified user needs, and implemented incremental improvements. Matt also shares the importance of gathering user feedback, conducting usability tests, and embracing a collaborative approach between designers and engineers. His insights provide a valuable roadmap for anyone navigating the complex world of design systems.
Check out our upcoming events.
Guest
Matt Weinberg is a systems-specialized product designer from Brooklyn, NY, currently working on design systems for Angi. He is largely focused on design system ergonomics, designer-engineer collaboration, tooling + workflows, accessibility, and keeping systematic UI creative + fun.
Host
Chris Strahl is co-founder and CEO of Knapsack, host of @TheDSPod, DnD DM, and occasional river guide. You can find Chris on Twitter as @chrisstrahl and on LinkedIn.
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.
Chris Strahl [00:00:21]:
Hey everyone, welcome to the design System podcast. I'm your host, Chris Strahl. Today I'm here with Matt Weinberg. Matt is a product designer. Over to Angi. He's got an interesting story for us, kind of about how you think about changing your design system incrementally in the right way. Matt, stoked to have you. Thank you for coming.
Matt Weinberg [00:00:40]:
Hey, thank you so much for having me. I'm stoked too.
Chris Strahl [00:00:42]:
So you have kind of an interesting career path that got you here. Maybe we should start with that. Let the folks get to know you a little bit and why you're sitting in the chair you're sitting sure sounds good.
Matt Weinberg [00:00:53]:
So I guess my path, interestingly enough, started when I worked at the Apple store. There were some areas of the store that were giving people anxiety, and I worked on some training plans with my managers, and it turns out there was a whole career that was similar to the service design that I was doing. So in my first UX design job, I was asked to do an accessibility audit on our products with no experience of accessibility prior, and I was asked to do a little bit of front end work without any experience prior. And so the way that I got into design system was because as I was correcting the things I found in my accessibility audit over and over again, I basically had a local notepad of code changes that I had made. And from there I realized there has to be a way to store these. It's better than just my notepad. And it turned out there's a whole industry behind it. So here I am.
Chris Strahl [00:01:39]:
That's great. I love the idea of like, hey, sink or swim, and then that kind of led you to discover this entirely new way of working.
Matt Weinberg [00:01:49]:
Exactly. Yeah. I mean, I come from General assembly, which is always very empathy first, very know the people you're working for, and accessibility gives you an entirely new perspective on that, which is, I think, helpful for every single UX practitioner to have.
Chris Strahl [00:02:04]:
Yeah, agreed. It is interesting, because funny enough, this isn't really a conversation about accessibility, where you're at Angi now is this place where a lot of your focus is on ux, and a lot of your focus is on how you actually continually improve the systems that you're using. Give us a kind of understanding of what Angi looked like when you came in and some of the complexity that you're trying to manage.
Matt Weinberg [00:02:29]:
When I started at Angi, we had a fairly robust web based library in Figma and an app library that was being built in Figma. We had a few code repositories, as it always is with design. You know, a lot of products with a lot of different technologies baked into them. So one of the first things I did was try and parse through that, and I was really trying to, just not so much by interviewing my coworkers, but just sort of sitting in on projects, talking to people, see how people were designing and what issues they were running into with the system that existed, and sort of tried to take it from there. One of the things, and this has been like a pattern in my career, is discoverability was sort of an issue in terms of discoverability of system function, getting just sort of like a shared understanding of how systems work and then how this system should work, and also just discovering what communication was like between designers and engineers. And there was no bad relationship or anything like that, but there was more understanding that could be had. So that was sort of the first thing I took, too, was to make the system aspects easier to find. I think my first thing I did was try to create a documentation website and then just sort of go from there, see how people reacted to things, and adjust accordingly.
Chris Strahl [00:03:50]:
Got you. So you came into a semblance of an existing system, but one that wasn't necessarily that mature. And so when you came in, a big part of your initial task was like, let me get my arms around this problem, or let me fully understand what's going on. And you did that with that same sort of skill in empathy, where you wanted to actually just observe what was happening. And through that observation, you found out that, hey, we have a system, but people can't find things, or they don't know how to use it, or they're not exactly sure how it applies to them. And so the intention with the documentation and the intention with that initial setup was like, let's create a baseline of knowledge that people can understand how to use and sort through. Or was it something that was deeper than that?
Matt Weinberg [00:04:35]:
A little bit of both. There were a few things. The first was, I wanted to gauge how people use new things that were introduced. So I made this site while I was still, again, kind of wrapping my arms around the system, which I will say was pretty robust, but I would say not totally synthesized, if that makes sense. But the things I was trying to do with zero height was give basic information for, okay, we use this in this way, we use this in that way. The way I put it out and was directing it to people was sort of seeing how people respond to new stimuli and new resources. But also, at the same time, I was using it as a record of decisions to be made or questions that people had over and over again, and I still use it that way. So a lot of it was also finding the gaps in knowledge about each individual element of the system, mostly in the context of components here.
Matt Weinberg [00:05:23]:
But what I would do is, because my whole career, I've been basically like Lone Ranger, sole proprietor of design systems, and just sort of doing a lot of outreach, it's impossible for me to know every question that needs to be asked about every single component. So I let people come to me with those questions, record them, and then just keep pointing them to our doc site to see what it sticks. And eventually, that made its way to engineers. I had originally intended it for mostly a design tool and then figure out engineers later, but then designers just naturally started showing it to engineers, and we started making it engineering friendly as well. Engineers were referencing zero height for designers, and that started a lot of cool conversations.
Chris Strahl [00:06:02]:
What made that change? Was it just through the natural course of working, or was there something that was a broader driving change to getting engineering more involved?
Matt Weinberg [00:06:11]:
I think it was just kind of the natural course of working. Our engineering organization is very large. It's a lot of people to meet. There's a lot of people to keep track of and know. And I found that as zero height was being referenced more and more, one designer would show it to one engineer, that engineer would hear about me, connections would be made. But then eventually, once zero height started to be more robust, that's when I started really actively showing it to engineers I'd made relationships with and their teams. Sorry, the doc site. And the way I started phrasing it was usage guidelines for everybody.
Matt Weinberg [00:06:44]:
There were a lot of ways there that I started unearthing, like, okay, so now that the zero height is kind of design centric, we're finding gaps in code, and then we're finding things in code that didn't exist in design, but maybe should. This just kind of drove more of a global awareness of what existed in our design system and what information people had versus didn't I don't think the doc site is entirely responsible for this, but at least the same sort of force that put it into our hands was the same force that ended up. I say this like it's a big mystical thing, but I think it's just more of a generation of knowledge and information, is that we ended up getting a swarm of designers and engineers to start filling those gaps towards the beginning of this year in a concerted way. After that is also, there's a lift in adoption on the design side, too, because I had, like four or five designers with me who were working on components in the system for the first time. That gave them an understanding of how it worked. They were all on different teams and were able to start talking to each other. And that was, I think, when our culture of design systems really kicked off.
Chris Strahl [00:07:50]:
And so you have this point where you've reached sort of like a next level, and when you have that step change that's happened in the way you're thinking about building those products, what is it that really then drives incremental improvement from there, right? You have this baseline, you have this understanding that, hey, we have a system, and that system is working. Now, how do I improve that system? Or rather, how do you improve that system in a way that represents the needs of the people that are consuming it?
Matt Weinberg [00:08:20]:
Like I said, I approach everything like big empathy first, people first. And I think that the best way to know what's needed for a system and what's missing from a system is to gather that information from the people using it. I will say, yowling into my grave that design systems are products, and engineers, designers, PMS, and brand folks are its users. So what do you do with a product? With users? You run research. So since I want to say, I think the first one was either the end of last year or the beginning of this year, I've been sending out surveys to our team to gauge not just satisfaction with our design system. It's easy enough to ask for, would you recommend Angi's design system to your friends, family, and colleagues? But I've specifically asked, how easy is it for you to find information on a Likert scale for the design system? How comfortable do you feel contributing? How helpful or otherwise? Has it been to your work? And then I go for some qualitative responses, too, like, where do you think we should focus next? Have there been any blockers? Has anything been working especially well for you? And that in itself is a huge wealth of information. I know the old Henry Ford quote where it's like, if you ask people what they wanted, they'd say faster horses. In this case, a lot of the responses will tell us not just what people's desire is, but it'll also show discoverability issues, where people will ask for things that sometimes that may already exist.
Matt Weinberg [00:09:48]:
And to me, that means we may need to improve this thing, but we may also need to improve how it's classified, we may need to improve its functionality or flexibility. We may need to just change in nomenclature. There are some conversations about when we were having the issue with designing code parity after we did the swarms, based on feedback that I actually got from the survey, largely I ended up going into making a process, an actual build process, from design to engineering. That's about as, I don't want to say automated. It's still very conversational, but it's consistent and it's trackable and it's measurable in a lot of different ways. The other thing that I do, I was inspired by, I think it was a talk at clarity a few years ago, I want to say from Atlassian, where they stopped production entirely for a few months just to observe how the system was working. I can't stop production for three months. But what I did have the idea to do from that conversation was to start running usability tests.
Matt Weinberg [00:10:43]:
Before I was at Angi, I was at another organization called Understood, and we had similar issues with our design system with regards to discoverability, nomenclature, people's access to elements within the system. So what I ended up doing was, in order to make a case, I ran usability tests with three or four other designers and all of our front end engineers. It's a very small team, and basically asked people to find certain components within the library based on what we already had. And I did time to task and qualitative, like, how'd that go? And then I, a few days later, ran a follow up test with just a basic file tree and asked them to find the same components. And I believe the time to task decreased by 75%. And I got a 4.8 out of five satisfaction. And the only reason it was a 4.8 is because one person said that a few things were out of alphabetical order and they had to dig me for it.
Chris Strahl [00:11:39]:
So.
Matt Weinberg [00:11:42]:
It ended up really helping open up the eyes of design leadership and say, like, hey, we need to make a few changes, need to invest a little bit in our design system, because as we've seen from the myriad of studies that are out there right now, it helps. And people here clearly want to use the system, we just want to open it up to them. So I've been doing some things like that here as well, mostly on smaller issue items like how certain components work. But aside from the data that we get from it, it really helps make people feel involved. They're invested in the results. And in this case, I do a pretty cool design system update at the end of it. So I'm happy to.
Chris Strahl [00:12:22]:
That's awesome. Yeah, I love the idea of how do I gather some numbers about how people perform their jobs inside of the design system. So much of the focus that we have is like, how do I build the system or how do I get the right content to the system? But we oftentimes don't think necessarily about the usability of that system. And I think that likewise the ability to involve people across disciplines early, that's a really challenging thing to do. I think that in particular, like you said, it tends to be a lot of people, right. Engineering teams tend to be dramatically larger than design teams at organizations. And getting people on board is oftentimes a big challenge just simply because of the scale. You can't be everywhere at once.
Chris Strahl [00:13:03]:
I love this idea of like, let me experiment, let me measure, let me experiment, let me measure. And that framework seems to be doing a good job of advancing the quality of the system.
Matt Weinberg [00:13:14]:
Exactly.
Chris Strahl [00:13:15]:
So when you think about these incremental advancements in this experiments pipeline, have you done stuff that also hasn't worked?
Matt Weinberg [00:13:22]:
Yes. This is, I would actually say, the instance that got me started on actually test on really doing formal, rigorous tests, an organization I was at previously, the same one where I did my first usability test. We had in a directive from above to add dark mode, which was a lead into maybe we should have design tokens as well. We didn't know where our branding was going to go because there were some product updates coming down the line that were maybe not tied into a visual redesign. We thought that we could use the flexibility. So initially I talked to the team about it and there was a lot of just like conversation and there was consent, like, yes, this is fine, I get it. I had to change the way that our colors were listed in figma that matched up with our design token system. We ended up making our own tool for applying the themes we like forked, I want to say themer so that updates would get added to our.
Matt Weinberg [00:14:17]:
I think it was a monorepo at the time and it was going, it was working, but a few dark mode designs came out looking wonky. We added a new designer in this time and even though people weren't saying things, I ended up having to be like, hey, keep an eye on the name of the colors that you're using. Keep an eye on how you're putting this together. And it just wasn't landing with people. I was the most technical designer on the team, and while I was prepared to think like engineers, the designers weren't. And this was a system that really skewed maybe a little engineering heavy. And so our new designer came in, and I was talking to her about the colors, and what she basically said was, because we had sort of a. I forget the exact naming, but she said, why is it the case that one color has two names, and why is it the case that all these colors have two different names? And my answer was, well, that's to account for dark mode and light mode.
Matt Weinberg [00:15:07]:
I was told, I don't get it. I then got a call from the lead front end engineer, who said, hey, there's not a lot of documentation for this. Can we talk through how this works? And after a conversation with him and a few of the other frontline engineers, it turned out that, yeah, it turns out this actually adds time, and there's a few sort of kinks we have to work through. So what I ended up doing was with the designers. I just did a workshop. I had two focus groups. The first thing I did was basically like, all right, get it out. I know you don't like this.
Matt Weinberg [00:15:39]:
I know it's not working for you.
Chris Strahl [00:15:40]:
A little group therapy.
Matt Weinberg [00:15:42]:
Exactly. That's what it was. I was like, you know what? What isn't working? And, of course, there were the ground rules. Like, let's not make this personal. We tried to do a thing. Let's be respectful. Let's keep it to the color naming system. I got the lay of the land.
Matt Weinberg [00:15:54]:
A lot of it was like, the actual names that we picked didn't make sense for colors, and engineers basically said the same thing that I heard on the call. This is actually adding time. I don't have a full understanding of how it works. So what I did was I took the complaints on my side and used it as basically a set of requirements. Like, the color names have to make sense for the final implementation and also for what the color actually is, because the way I designed the dark mode to back up a few minutes was to just design it first and then from there to just sort of make a system out of that, which is how it came to be in the first place. And so I ended up saying, like, all right, come back to the next event sesh, which won't be event Sesh, will be a generative sesh, an anti event sesh. And I want to see what ideas you have for how you would like this to work.
Chris Strahl [00:16:40]:
Let's tear it down before we build it all back up.
Matt Weinberg [00:16:43]:
That is exactly how it went. And what we did was everyone had the same idea, pretty much including me. And basically, the way that it worked was the way that I had initially designed it. I noticed a pattern, and we ultimately referred to this as altitude, where as things got nested further and further in, in dark mode, the colors got lighter and lighter and lighter. So we made four different altitude layers. We had, like, base, low, high, and foreground. And each color, it created a lot of colors in figma, but we had a few base colors, a bunch of foreground versions of all of our color palette, a bunch of high and low surfaces. And each of the full palette would go to a different color based on whether it was low, high, foreground, or base.
Matt Weinberg [00:17:26]:
And then on the engineering end, what we said was, okay, we tried this thing and it was a really good idea, but we also don't want to reinvent the wheel. We were making an app at the same time as well, and tokens are great for apps, and you have style dictionaries. So we decided to go into that because we had hired an outside service, I believe, to build the app, but we wanted to have control in case we had to make a component change. So we did a huge push to make tokens based on everyone's feedback. Everyone loved it. We worked fast, and then I ended up switching companies. But that token system is still in place, and it's cool to see whenever I visit the website.
Chris Strahl [00:17:59]:
That's a fun story about how you took something that was initially loathe and changed into something that people loved. So I think that's cool. And it speaks to this commitment that you have to trying to understand exactly what the problem is and figure out what you can do to make common solutions go, and also what to do to make it so that you're not rebuilding something just to have it be the solution that you want it to be or that you envisioned in your head. Exactly.
Matt Weinberg [00:18:24]:
Yeah. With design systems, there's so much cool tech coming out. There's a ton of tooling. And I have conversations with people frequently that's like, hey, should we use tokens? Hey, container queries are coming out. How can you make use of those? And I have seen organizations who have all of that. They have this very stacked out system, but they don't talk about how it's been responded to. So whenever someone asks me that, my first question is, why do you like this? What problem do you think it can solve? And I'll usually have the conversation with a few people and see where they go with it. Sometimes just hearing about a tool brings up a problem you didn't know about.
Matt Weinberg [00:19:00]:
But just defaulting to the newest, coolest sometimes requires a little bit of thought first.
Chris Strahl [00:19:06]:
So one of the things that I love about your approach to all this is you solve two of the core things about design systems that are hard simultaneously. When big organizations take on a design system, usually they're doing it for two major reasons. The first is that they can't just scale with people. There's too many folks that need to be involved in the digital production process of a product to really be able to hold that consistency, hold that capability inside of the organization. Just getting those people to work together becomes like a challenge in and of itself. And then the second side of it is there's a proliferation of tools inside of the product production process. There's tools everywhere. And so you have stuff that is like GitHub vs.
Chris Strahl [00:19:47]:
Code. You have stuff that's like Figma and Framer. You have a bunch of stuff that's in confluence. You have a bunch of stuff that's in things like zero height or storybook or wherever it is. All of that creates a level of kind of background noise and chaos. And that signal to noise ratio is something that's really difficult to sift through. And I think one of the things I've loved about your approach is you've figured out ways that you can work with people to solve that people problem while simultaneously cutting through a lot of the noise to really understand what is signal. That means an advancement to the product.
Chris Strahl [00:20:21]:
And I think that is really cool. And you and I differ a little bit on whether or not this is product or infrastructure, yada yada. But at the same time, I love the way that you think about like, this is how I solve a people problem with empathy. And I solve a tooling problem by being able to measure what really matters to the people that I'm serving. And that's cool.
Matt Weinberg [00:20:43]:
Thank you.
Chris Strahl [00:20:44]:
What's next then? How do you continue to evolve this? What are the things that continue to lead you down this pathway of being able to really understand what people want, and then also to not let people get in their own way in order.
Matt Weinberg [00:20:56]:
To have that empathy myself. One thing that helps is for the consumers of my design system to also have empathy for each other. I think that design systems are always new to people. They're maybe scary if you're someone who's like a very compositional designer. And one thing that has been really helping me lately that I've been working on a lot is getting designers and engineers to understand each other. So if you think about the story with the tokens, I think designers and engineers understood their own tools. But maybe I could have even gone a step further had I explained to designers how tokens work. Why is this required for dark mode? So, getting out of nostalgia, what's happening right now is, again, we're still coming back from that design system, the swarm we're still talking about, how can we most fully and effectively leverage our design system into our products.
Matt Weinberg [00:21:52]:
So one thing that I'm really trying to get people to do is talk to their counterparts, which sounds like such a simple thing, but I feel like until people maybe not see, but understand the framework of what the other is doing, that's when you start being able to build for each other and really participate in a process instead of just like, dropping off a ticket. One thing that I've been doing in our tools is I've been linking design tools and engineering tools to each other as robustly as I can. So I have Figma linked up to storybook. I have it linked up to our documentation site. There's a three way link between all things, so that no matter what, one person should only have to look in one place to get the information that not only do they need, but that designer's engineer might need doing that and also really pulling the curtain back on process, which is, again, not just saying like, oh, I'm going to drop a ticket off in a box. And then magically there's code. Really almost like facilitating, essentially being a project manager when a component request is made, opening up a conversation that includes the designer and the developer so people can speak freely about, like, hey, here are the challenges I face. Well, I understand that, but here's the needs I have.
Matt Weinberg [00:23:02]:
What can we find in the middle? And really just acting like a steward or an information source to make sure that those needs are met. And I feel like after every time something like that happens, of course there are times when I can just be like, hey, we need to update the pixel ratio here. But also there have been some things where we've said, how can we make this combo box more accessible? I've had engineers in the conversation as well to be like, well, here are options. Here's how long it'll take to make. And this is why that's been really eye opening. That's been the case for a few other components as well. And I'm also doing as much as I can with my process for allowing designers to build what they need to get the job done. And seeing that contribution scale where again, I'll say, here's a form.
Matt Weinberg [00:23:47]:
I know it's basically dropping a ticket off in a box, but form with the conversation that basically says, okay, what do you need? Who are the stakeholders that need to approve it? And I'll be here to see if this is something that we can scale to the rest of the design system that teaches people about what goes into upholding the design system, and that also makes people want to contribute more because a lot of people that have done it with no process is perfect. But I've heard a few times like, hey, that makes a lot of sense. And that's my favorite thing that I can know. You can make the most beautiful hero image in the world, but if nobody uses it because they don't fully understand it, then it's not the most beautiful hero image in the world.
Chris Strahl [00:24:22]:
It's kind of like a good analogy for a design system. Matt, I love the passion. I think it's so exciting to see somebody just so enthusiastic about this work. And it's obvious that you care really deeply about the success of the system and the success of your team. And I love that you have a focus on the people and also just trying to figure out how you improve their lives. So thank you for being on here. Thanks for sharing your wisdom with us. It's been a great conversation.
Matt Weinberg [00:24:48]:
Hey, thank you so much for having me. This has really been a blast.
Chris Strahl [00:24:51]:
This has been the design system podcast. I'm your host, Chris Strahl. Have a great day, everyone.
Chris Strahl [00:24:55]:
That's all for today. This has been another episode of the Design Systems podcast. Thanks for listening. Mean, 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. Have a great day.
