t’s all just opinions, man! In this episode of the Design Systems Podcast, Mark Shuster talks about the shift away from enforcing strict guidelines through design systems towards enabling good design and production practices in a more transparent and collaborative way. Chris and Mark discuss different sources of truth within a design system, flexibility and iteration, and why composability is so important to the future of the product engineering process.
Guest
Mark Shuster is an Engineering Manager at Dropbox, leading a team responsible for building DIG, Dropbox’s design system. With previous design systems experience at Twitch and BuzzFeed, Mark has a rich background spanning UX design and front-end development. He holds a Master’s degree in Human-Computer Interaction from Carnegie Mellon University and is based in the Bay Area.
Transcript
Chris Strahl [00:00:00]:
Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at thedspod. We'd love to hear from you.
Hey, everybody. Welcome to the design Systems podcast. We're still here at Figma. I'm here with Mark Shuster. Mark is the engineering manager for the design system at Dropbox. Welcome to the show.
Mark Shuster [00:00:30]:
Thank you. Thank you for having me.
Chris Strahl [00:00:32]:
So, to start it off, is it config or config?
Mark Shuster [00:00:35]:
I do config, but maybe that's like a midwestern thing. I'm originally from Michigan, so it's funny.
Chris Strahl [00:00:40]:
It's been almost exactly split 50 50 from the guests today and the people I've talked to. And I was mentioning earlier that there were a bunch of people from figma across the bar from me last night, and I almost asked, but I didn't want to have a preconceived notion coming in today's recording. So we'll see. I'll put out there as a part of each of these episodes what it actually is. When I get to talk to somebody.
Mark Shuster [00:01:00]:
I imagine my answer will be canonical, since I have the most neutral accent, maybe, of anyone that you're going to interview today.
Chris Strahl [00:01:07]:
So we're going to talk about a really interesting topic. And it's great because we touched on this earlier in the day with Nick's episode about the idea of how you think about divergence and the management of a design system. And so this is like a pretty deeply philosophical topic where you have all of the stuff that goes into a design system or tokens or components or themes, all this other stuff like that. But that's not really what we're here to chat about. We're here to talk about, like, okay, so you have to go enforce a design system, quote unquote, inside of your organization. What does that look like?
Mark Shuster [00:01:41]:
Yeah, well, you know, I think enforce, quote unquote is the issue, because I think we're really moving away from enforcement and policing, or at least I'd like to advocate that we should. And that's kind of been what my career arc has dictated over time. I started in design systems eight years ago, coming into a new position, being asked to fix all the things. Everything's off brand, everything's off system. Go in and fix all the CSS so it works perfectly. And there were systems in place to enforce all that. All of the CSS was separate from the rest of the code so that a single individual or group of individuals could see every change that comes in. And the process for actually getting those changes into code was more complex because it was separate
And I spent maybe six months trying to fix all of the buttons, but for every ten buttons I fixed, I broke one. And, you know, if you're the one button that was broken, you probably care a lot about that one and not the ten that were fixed. In the meantime, I was engendering a lot of anger with other designers and developers because I'd be jumping into all of their pull requests asking, why are you doing this? Why are you doing that? This is wrong, you shouldn't do this. And scaling this process and scaling this opinion and philosophy, I think has made less and less sense over time that a design system can't be an enforcement mechanism. It has to enable good practice, enable good design.
Chris Strahl [00:03:01]:
So when you were playing design systems police, and you were probably one of the least liked engineers on your team, like, describe to me the collapse of that, because I think that, like, there was a breaking point. And that breaking point, I mean, you came by it very honestly. I think that you tried very, very hard to make it go. And ultimately, when you reach that limit, a big change happened. Talk to me about that.
Mark Shuster [00:03:27]:
Yeah, CSS is just opinions. People can change those opinions. And I think I realized that early on I tried to implement better structures, atomic CSS, this kinds of stuff, but people were able still to override these opinions. And at the time I was very fortunate because we were at a moment in our company where we were transitioning to a new react framework, and we were able to better encapsulate these opinions into components. So we started to get a true kind of component library representation of the design system. And for once we started getting able to think in terms of APIs and how to construct UI, rather than just how should CSS and design and token opinion travel through the system. And that was really a changing point, because now we got to think about what components were necessary, which ones could best represent the artifacts of the design system. And I think that was really the turning point.
We got to think about things a bit differently. However, that created a second order of problems then. Now you're at the point where, okay, you have components, but now people want to do things with components that weren't part of the system, and that's a whole new set of problems, which also has a new set of challenges
Chris Strahl [00:04:34]:
But I think that's interesting where you looked at something that was a technological advancement for your organization vis a vis new react, and then that technological advancement kind of changed the way of working. In that changing the way of working, you had better encapsulation. Presumably, there was another iteration over there of tokens where all these different transitions had you reevaluating all of the constructs and all the service models that you'd put in place to understand how that actually makes it into a product.
Mark Shuster [00:05:06]:
Absolutely. I think what you start to see is that if there isn't sufficient design process to kind of control for divergence, or at least bring awareness of divergence into your design and engineering process, and then there isn't good enough tools for engineering to use to address divergence within the system, then you get this collapse again and you have all this friction, and then you're back to kind of having to police. And I think that's kind of where the aha moments were. At that phase, you have this set of design processes and solutions that is really centered around transparency and visibility into the design process. And then on the engineering side, you have, I think composability is the most important aspect for enabling good divergence, because if a design comes through and it's not seen by the design system, or if there's not the right feedback at the right time, then whatever gets designed really gets built into the product, and that's a good thing. Like, that's kind of what you want to happen. You don't want there to be increased friction. You want to eliminate friction through the design system.
But if these things come in and then engineers can't build them, then they have themselves friction where they can't build as quickly or efficiently as they want, and they're incentivized to deliver the product. So you really have to work, I think, from both ends at understanding and controlling divergence in that way.
Chris Strahl [00:06:29]:
It's interesting you brought up composability as a kind of core tenet of that engineering process, because I see it that way, too. Right?
Like, you know, you don't want to have a bunch of components in your design system that represent fully baked patterns. You want to be able to assemble and compose those components into those patterns with that sort of structure in place. That's a very different paradigm than what the main thing is of design. Right. And that design wants to be able to iterate, they want to be able to ruminate, they want to be able to see lots of different variations and test a bunch of things. And in that baking process, having those fully functional patterns actually makes a lot of sense. And that point that all of these things meet, I tend to think about that as a spec. And when I think about that, that spec is represented usually as a JSON file
That's a schema, and that represents the structures, and it also represents the allowable divergence. And you've gone through exactly the waves I went through where I was like, okay, well, this is all just css, and it's all just opinions, man. And there's a Jeff bridges shirt of that probably somewhere. But when you look at that, then in the next iteration of like, okay, now we have components that have props and slots, and those all things have opinions as well. What I started to look at is like, okay, you have this workflow that has traditionally been, everything starts in design in Figma, and then it gets handed off to a bunch of engineers. And those engineers like, go lay the bricks and build the thing. What's starting to change about that is there's this desire for things that are happening at that engineering level tend to back in Figma, and that upstream downstream information flowing bi directionally is ten times harder than it flowing unidirectionally. And in this case, schemas have played a major role in the evolution of my thinking around how we manage this particular problem.
And that everything is a spec, and that spec has all of our definitions and also our allowable deviations. When I talk about allowable deviations, for example, there's no accelerometer in Figma. You're not going to be able to basically say there's accelerometer data that's passed in here that causes some effect to happen. Now, you can model or emulate that inside of Figma, but ultimately that accelerometer data prop will never exist inside of that tool. And likewise, there's things that deviate between web and Android and iOS and all this other different stuff that is there. Everything then is represented as a consumer of this specification, this single schema file that represents all the things you must have and then all the things you could have. And I'm kind of curious, like, has that mirrored your evolution of thinking when you think about this in terms of a very truly modern take on design systems?
Mark Shuster [00:09:16]:
I think it brings home the point around sources of truth and this higher levels of abstraction around truth, because I think traditionally we thought of source of truth as this thread that weave together between tools. And we haven't had really good abstractions historically. We've had converters and plugins and things that are supposed to convert design into code or code back into design. And I think those are all band aids. And we're really getting into the world now where we have pure representations and mapping and topics. I think the schema that you're talking about is a similar kind of mapping on top of that. I think that makes a lot of sense. And I think the ultimate goal or endpoint of these will be designers and engineers being able to work closer together at higher Fidelis, or closer to the tools that they care about.
I think that's really the trick and the missing part. I think design systems has always been about a nexus of design and engineering, and I think that's been the biggest challenge because we use such disparate tools. And this is kind of an amazing age right now, config and all of these new tools coming out that allow us to think about it more abstractly and be able to map and have our truth more purely represented. However, as you were saying, the truth is part of it, and then being able to figure out what is fungible and what isn't, what's acceptable and what's not, and how we encapsulate truth from the lowest primitive levels, which should be the strongest kind of bonds to the brand and the product and the design system versus things at the higher level, which I think you just have to kind of let go of. Of a little bit and like, just kind of be okay with, like, things floating out there and being their best selves so that you can use that knowledge and that information from the product to improve the design system itself. I think, like, if you have a result that's like 80%, there has an extra button somewhere, because some team needed to conduct an A B test, I think that's okay. You know, if that button's color is wildly different, maybe you wanted to catch that somewhere earlier in the design process. But, like, ideally, with, like, increased collaboration and visibility, that's what you would get.
Chris Strahl [00:11:22]:
It's very mindfulness take on design systems. I love it. I love it. I love the idea of the thread, too, right where we did have this idea that truth was this threaded thing through a process. And now as we get these more codified representations of it, it's starting to change the way we think about that collaboration. And I think in particular, your point about there's just some things that need to iterate at a different pace of feedback. And those end up at the product, and then there's other things that are more codified and those end up at that systems level. I think that the wonderful kind of conglomerate of this conversation in aggregate is we're talking about things like how do we structure systems and inheritance
How do we have models that represent contractual models for how we think about the decisions that we're making in design and engineering, and then also how we think about composability as a factor in the way that we create. And so those three things together, that to me is the state of design systems that I want our entire industry to move towards. I want us to think about things in terms of schemas, composability, and then ultimately systems of inheritance that can move at different paces. And if we have those three things working in tandem, and maybe tokens and theming is a fourth, if we have those three things working in tandem, we should be able to describe and delineate the structures for our products and have a high degree of centralized control, but also a high degree of flexibility that happens at those product endpoints. And that flexibility comes from composability and patterns, and that structure comes from those systems of inheritance. And if we can do all that, and that can all be governed by schemas, like, think about what a cool world that is. Right?
Mark Shuster [00:13:00]:
Yeah, easy, right? Yes, it will stop.
Chris Strahl [00:13:02]:
Let's just change the way that we think about digital production. Like, apparently I just decided to start a company that is now the mission of.
Mark Shuster [00:13:09]:
But I think you're getting there. But I think there's also, there's a lot of people involved with a lot of opinions. And I think it really goes back to the beginning of the process and how to create design transparency that can enable, on the other end, diverse product outcomes that are really on brand. And I think one of the ways that I've seen this done at my old company was Figma, which we talk about as a source of truth, is really transient. You have these designs that kind of ebb and flow with feedback. You don't get a good idea. I think, of how things have evolved over time, and I think that's really key for being able to give feedback, feedback at the right points and have engineers come in and be able to give feedback, understand the evolution and be able to drive kind of the collaboration. And that's something I think is kind of missing right now.
And at that company, what we tried to do was build a tool just based on like a forum app where designers would post chronologically kind of updates about their design process with just screenshots of where they're at and summaries of feedback they've gotten. And we've called this product design narrative. And that would kind of increase the visibility into the design process in a way that I think just like viewing Figma files didn't really allow. And I allowed async feedback to kind of take hold and the design system have better visibility into the ecosystem of product development. So early divergence could be seen and questions could be asked in a way that could kind of control on that end. And then as that collaboration worked between engineering and design and you know, it wasn't always perfect, but you get to the engineering end and people would understand what decisions were being made and how approximately they could go and solve those problems using the tools they already had.
Chris Strahl [00:14:57]:
It's actually really interesting. It's one of the big features that was highly requested of knapsack for a really long time was the ability to go and have a bunch of save points in prior iterations of your design system, so you could see how things change and evolve. I want to be able to see what one dot, two dot, one of my button looked like now that I'm on three, 5.2. The ability to move back and forth between those save points is something that kind of helps you understand the decision stack to get there. I think that this vision for digital production that's been laid out there, one of the things that it comes with is no small amount of organizational change. When you think about those organizational changes, I think about this is very much inverting the way we think about our approach to new features. Very rarely do we actually have greenfield products. The vast majority of the time we're always building on top of something that's been built before, Dropbox being a clear example of that.
And so when you think about a new feature, the typical workflow of that feature tends to be like, okay, a bunch of people go into a tank that are describing that user need, they're doing a bunch of modeling for it. And there's a bunch of like ux exploration that happens. Ultimately that results in a design output. And that design output is built into a Figma file, ideally using component models, et cetera. And then at some point they're like, okay, look at this. And they hold that up to an engineering team and they say, can we build this? And then it goes through the machinations, there's probably some BQA, then there's a release process that happens after that when you think about that as a pretty traditional process for how you go deliver a new feature. How does that change in a new production model that looks at a system and a codified set of decision making? First?
Mark Shuster [00:16:37]:
Yeah, I think what we've really keyed in on at Dropbox is how do we enable kind of better design systems thinking at the new product level? How do we enable systems of systems to take hold and, like, give new product development the kind of benefits that we get from the design system where you know that they're going to be trying new things and thinking outside the box and having to move quickly and flexibly. And I think, as you were saying before, like, core design systems need to be codified, they need to move slowly. And I remember a great article about this who I can't remember the author of, but design systems move slow, and you have these shells of abstraction that have to move a little bit faster. And when you're talking about new products, they have to move very fast. I think the challenge is how do you establish good practices around systems and systems? How do you scale design systems resources? Because there's usually only one design systems team, if you're lucky, or maybe a person if you're not so lucky, or a group of people that just care a lot into really good best practices that work at all levels of your company. And sometimes especially what we're finding out is you really have to jump in there as a design system team and help teams get on their feet and help create good reusable component libraries, even if there's not enough proof or it's not going to turn out in the end. And I think that's also part of owning the divergence as a design system is like, you know, you might be creating something new that might not make it into the system, but you're doing it at a level of extraction where experimentation is okay, and then you can evaluate in the future whether that's things that you bring back in. And you're doing that for the sake of enabling faster product development and good UI practice.
Maybe your team doesn't have the right skill set to invest in component libraries. Maybe your team is not incentivized your product team to be thinking about that right there, but you can help fill that gap. And I think that's really where this practice comes out most strongly.
Chris Strahl [00:18:32]:
Yeah, it's awesome. The idea of like, okay, so you have a very slow moving design system, but the intention of that slow moving design system is largely about continuing to clearly represent that brand value and that codification of those brand decisions. But then a lot of iteration has to happen to that product level that's at the pace of feedback. It's my favorite tagline for that because product teams don't want to wait on some upstream change to be able to solve a problem that they have in front of them right now. So if they're iterating and solving that, that divergence is good. Actually, in the case where that divergence ultimately represents a change to the fundamentals, like the brand or the components, that's where the work happens, in my opinion. And that's where we've kind of like, I don't know if we were to take our model of design systems and expand our worldview above it and say, like, there's brand systems above it and product systems below the interstitial layer, that is like how we think about that design system right now. That's where things flow down from brand and flow up from product
And it's our work as design system practitioners to be able to be the flow control for that. What's really, really important about that is mostly from the top you're getting componentry, and mostly from the bottom you're getting composed patterns. And those decisions, we have to carefully evaluate how useful they are across the entire organization. That is where so much value gets created for a company. And I think that also represents a new way of thinking about these systems concepts, not just as platforms and infrastructure and maybe products that serve other products, but as actual profit centers for a business. Because what you can then do is you can say, all right, what if Dropbox wanted to have some ability to more deeply integrate into an operating system or into a mobile framework? You could conceivably deliver that with a design system in a way that would be so much faster and so much more capable than building that as a new product or as an enhancement to an existing product.
Mark Shuster [00:20:32]:
Right. I think you're like, getting to the pinnacle of, like, what these kind of shared concerns can be, right. You have kind of these cross platform, cross product patterns that need to be, as you said, like profit centers, like run by a product team that is concerned about how this user journey works or how this major UX feature works. And that's really how to do. If you extend design systems all the way up at scale, that's where you kind of get to. And that's really hard. It's even hard for a mature design systems team because it's muscles that we're kind of familiar with but aren't necessarily proven. And I think there's generally, and I think correctly, a lack of desire to do speculative work from a design systems perspective.
Things that you don't know if it'll get adopted, or things that you've maybe only seen in one or two places, and you really have to hold the difference between those at the right length. But I think that if you invest in these scalable abstraction layer models where you can protect your design system, but you can also have spaces to build more experimental things, reusable things, you start to get at the type of scale that can affect new products as well as your legacy products. And I'm sure other people are also dealing with this expansion issue.
Chris Strahl [00:21:45]:
Yeah, the idea of the speculative work is a really interesting thing, right? It's not like our current digital production process is simple. There's nothing simple about the way a big company ships a product today. And so I agree that there's a lot of complexity in that change and a lot of deeply ingrained behaviors circa 30 years of digital production work that exists in most of these companies. And asking them to change that, even overnight, for something that is broadly unproven, is still a big challenge. But there is so much value created in this process, I feel it is almost inevitable. And of course, I'm biased, right? I own a company that literally is banking on that. But that was one of the reasons why Evan, my co founder, ultimately convinced me to start this business with him. We were sitting together talking about design systems, and he's like, this is the future, the way that product gets built.
And largely because these systems of abstraction create so much efficiency and so much value, that in a place where at scale, we're chasing small single digit efficiencies everywhere we can get them. This represents a big double digit efficiency change to an organization that is ultimately incredibly valuable. It's about getting the people to trust it and to then also be willing to take that somewhat speculative step. You've been pretty successful with getting people to take that step. What has been the thing that has led them to decide to invest in this sort of system?
Mark Shuster [00:23:21]:
I think it all comes from the power of design systems. I think we're at a point in the industry where people can see the value. And if you can create a functional design system with a competent team, people look to that as a bastion for stability. Especially because if you're in a product, you're in a company that's trying new things, trying to gain users, or trying to generate revenue, you're taking risks and you're reorging, and you're pivoting a lot, and it feels very chaotic. And I think design systems tends to be a sea of calm and stability within all that. And people look to design systems to create these patterns so that. But there's less uncertainty out there. So what I want to do is, and try to do on a daily basis is scale this kind of practice, so that people can be confident in those layers and be able to be less afraid of taking those risks. Cause they know that there's kind of more solid foundation, more solid base to build upon.
Chris Strahl [00:24:16]:
I mean, back to mindfulness again. That was. That was awesome. I love this.
Like, you're very, like, Zen mantra about the way you think about these design systems is like the calm pool. I think that's really cool.
Mark Shuster [00:24:25]:
I think most design systems professionals have probably been through a lot, and it's kind of expanded and contracted in ways that are probably very familiar. You see weird things happening and you get frustrated, and then you have to go out and have difficult conversations with people. And I think once you start to really think of design systems and its associated layers and expansions as enablement, it becomes a lot easier to justify your thinking and just kind of be empathetic to the difficult choices that product has to make and approach those peers as allies and friends. Knowing that you come from a position of experience and a position where you are actually trying to help them do their jobs. You can't be a position of guardian of the brand and slayer of purple buttons or yellow buttons or whatever. I don't think that's a good posture. I think design systems is ultimately a service team, and if you take a real customer service posture to it, I think you'll have more success.
Chris Strahl [00:25:25]:
That's great. No, I love that. I think that it's oftentimes really intimidating, especially for people that haven't spent a lot of time in the trenches of design systems, which there's dozens of us design system practitioners. So the vast majority of people have not spent a bunch of time building a design system. And so when you think about that empathetic idea of, hey, we need to walk people into this and sort of hold their hand as they find a place of comfort, I think that's a really great way of thinking about that adoption curve. And, you know, I tend to rail against adoption, but I think that today's conversation has been really interesting for me because Nick was talking about, like, yeah, adoption is not necessarily a great metric for the value of a design system, but it is a great metric for the value of the service model. Attached to the design system. And I think that there is this sort of, like, tranquility about what you said about being okay with the fact that, like, not everybody's gonna know everything and giving them small steps that they can take to go in the right direction without necessarily demanding that they get there.
Mark Shuster [00:26:27]:
Exactly. And it's not even just about holding somebody's hand, but, like, creating an atmosphere where they will just come to you naturally. You know, it's intimidating in a slack channel of, you know, 100, 500, a thousand people to be vulnerable. Nobody wants to be wrong and, yeah, and ask questions like, why can't I do this with my button? Why can't I make this menu do something? It's difficult to be vulnerable in that case. But, like, if you cultivate this kind of design systems experience where people are okay asking you for difficult things or okay not understanding everything from the ground up, you get really good engagement. You get it early because you get it from designers who are trying new things, and then you can, you know, escalate quietly or efficiently or kindly in a way that does lead to better outcomes. And that's really hard to measure. It's hard to measure from adoption, and it's hard to measure from product quality because you can't see the things that don't happen, but you can feel it. I really believe that.
Chris Strahl [00:27:19]:
I think that there's so much of it that's about friction. I mean, you talked about friction early on, right? And I think the design systems is a friction reduction mechanism. And John Coulter, in his product rants talks about the cost of friction inside of organizations a lot, and how there's just a general malaise or amount of waste associated with every time somebody has to go pick up a new task or a new thing. And the design system giving people a place to go where all of those things are codified and well laid out for them. That is the calm pool in the storm. And the idea of the ROI of a design system being so multifaceted is true. But one of the things I want us to get to measure soon, and I don't know if this is even possible, but how much friction are we reducing by having that calm pool?
Mark Shuster [00:28:06]:
From a product developers product designer's perspective, they don't want to have to feel that. Right? But I think the design system itself should be a source of good friction. So you want to have the most important conversations about the things that represent the most divergence at the right times with the right people.
Chris Strahl [00:28:24]:
I think that's tension, not friction, though.
Mark Shuster [00:28:26]:
Good point.
Chris Strahl [00:28:26]:
Yep. And so when you think about that, like, yeah, there's a place that those conversations have to have the collaborative side of it. I mean, it's really interesting. Like when I was out seeking vc investment the first time around, one of the things that we talked about a lot is like, we are a collaboration tool. Now ultimately, that was really tough to describe in the context of venture capital, but I fundamentally believe that a design system space should be one that is innately very collaborative and very multidisciplinary.
Mark Shuster [00:28:52]:
Yeah, absolutely. I think theres this idea reducing the bad friction, having good tension, and I think thats the balance that you want to achieve here.
Chris Strahl [00:29:02]:
Awesome. Well mark, this has been a wonderful chat. Thanks a bunch for taking the time to be here today and join me live. This has been great.
Mark Shuster [00:29:09]:
Absolutely. Thanks so much for having me.
Chris Strahl [00:29:10]:
Of course, and I'd love to follow up in a couple of months, see how things are going, chat again, but otherwise, just really appreciate your vulnerability, your opportunity to chat. It's been great.
Mark Shuster [00:29:18]:
My pleasure. Yeah, let's get together again soon.
Chris Strahl [00:29:20]:
Awesome. This has been the design Systems podcast. I'm your host, Chris Strahl. Have a great day, everyone. That's all for today.
This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter Thedspod. We'd love to hear from you. 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.