Design Systems at Scale // Episode 4: New Roles & Processes for Design Systems

I think a design system is a thing that not one discipline could use on their own. You know, if a, if a developer can only use a design system by themselves, they don't need anybody else, perhaps it's not as collaborative as it should be. If a designer can use a design system on their own, maybe it's not as collaborative as it should be. And so I think any good design system will need everybody on it to be able to do their best work.

The very first stage, even almost ahead of or during initial research, is a kind of retail politics of really getting everybody on board, whether you're a small from a small organization, maybe a 10-person startup, to a sprawling enterprise of thousands. In order to make this thing a success, you really have to get allies and champions throughout the organization to carry this through and carry the message through so that it, it really does take root. There's also this, the enormous research effort that goes into this of understanding how will it be used, how should it be used, how can the design system help. There's a real level of humility that goes into building a great design system because you're not— it's not going to work if it is something that is imposed on people. It can, but it's a really sort of slow-going thing. The way that a design system works best and takes root best is when you build it in a way that the right thing to do is also the easiest thing to do. Really what I'm talking about from a product owner point of view, and this is true of any product, is let's make sure we're building the right thing for this organization.

As designers, one thing that we're supposed to do on every project and every product that we make is to have empathy for the customers and the users using it. What's really great about a design system and what I see that's so exciting when I work with design teams is that the empathy for the users that they're supposed to have is for actually developers, product people, UX people, all the other people on the team. And one thing that generally comes with designers in a lot of organizations, design is at the top of the food chain, right? Designers make comps, and everybody else has to build what those comps say. And this process of creating a design system is really about thinking about, well, what is everyone else's experience? What do they need in the tooling? And we have to design those things as designers. And so part of what I love seeing is when designers go, oh, that's how you build stuff, developer? I didn't even know that. You actually put things in tokens? Well, actually, I could take those tokens over and free up your job. And so there's this interesting thing that happens with design systems and designers where in the process of designing the thing, it actually builds more empathy for the whole team. And I think that's part of the role and the responsibility of the designer in thinking about and creating design systems is, what is everybody else's job on this team to make products, and how do I design a system that makes it easier for them to do that? And then on top of that, there's all the stuff that designers are already good at. Use this purple, don't use this purple. You know, you don't use these other colors, or use these typefaces, don't use these, use these like that. And I think a good design system has those kinds of rules that ultimately should come from designers who are going, all right, let me, let me think about what the best experience is going to look like. And let me, like you said, let me make the right thing to do the easiest thing to do by making it hard for people to do the wrong thing. If they shouldn't be using red, let's just not even have red in the design system at all. Right? Well, let's limit that palette. And so I think one of the things for a designer to be thinking about is what's that small palette that everybody else can use? What are the components? What are the colors? What are the typefaces? How do we create a system that scales? It's not too big and not too small, but just the right size for everyone to be able to do their jobs. One of the things that's really great is that because we're making tooling for each other, the design system is tooling for each other, we can actually innovate in the kind of tooling that we make for each other as part of the system that we use and deploy for our own organization. And that's something that helps everyone on the team, and the more we work closely together, the more we can actually come up with ideas like that.

I think an important theme there is that effectively there are a bunch of different interfaces through a design system. The most public one is the style guide or reference site. Here's the website that brings it all together and puts it in one place. But then there's the individual tool. It's like, great, if I am a designer who's working in InVision Studio or in Sketch or in whatever tool I want, how does the design system, through design tokens, perhaps using InVision Design System Manager or other sort of token systems, essentially make it so that design system just arrives in the tool that I use or in the coding environment that I use so that the Sass class variables automatically pick up the design system. So again, the right thing to do is the easy thing to do. It's part of my workflow. I don't have to go someplace separate. I don't have to go out and download a PDF that is 2 years old and perhaps no longer in sync because the latest is in my toolset using design tokens distributed through, for example, Envision Design System Manager. Yeah.

One of the things that we often do when we're working together, Brad, as designer and developer, is that you're often like, I'm going to set up the placeholder for you, but I don't really need to care about what this hex code actually is. That's something that me as a designer, it's important to me, and it's also something that I should be able to tweak to my heart's content. So the thing that I shouldn't be doing with you is sitting over your shoulder, hovering art director, hey, can we change that hex color? Or I'll send you a bunch of red lines. It's just a pain in the butt for me to make and a pain in the butt for you to receive and implement. Instead, if you can set up some placeholders and then I can go and tweak, say tokens, for example, in my own way. Now we can work in parallel, and it's something that I'm, I'm helping you in your job, you're helping me in my job, and that's another example of that collaboration.

I think it's really important to understand that everyone's eyes should be on the prize. And what is that prize? The prize is a suite of living, breathing components that could then be deployed to other software applications to build other products. We need to make sure that this design system, the actual living, breathing button component and the card component and data table and header and footer and all of that can actually sort of come together and actually assemble real living, breathing product screens, product UIs, and that are able to serve real product needs, right? So a design system can't just sort of exist as a static UI kit. Sort of hanging out in Sketch. It's not to say that that's never valuable, but at the same time you can't build products out of that. So one of the things that we do very often in our workflow is make sure that we're focusing the effort on building working software. I want more eyes on my code, right? Because you as a UX designer and product designer, and you as a visual designer, have way better perspective than me as the person actually sort of building out these components and widgets.

Right?

So I need to make sure that UX best practices and visual best practices make their way into the actual living, breathing component, because that is the thing that those product teams are going to grab and plug into their respective code bases.

As an interaction designer, And a product designer, my work has changed a lot in that it used to be I would, for every screen, every page, or every view of an application, I would build a really detailed wireframe with lots of annotations that, you know, that was itself its own sort of product that then I would hand over to a designer who builds a comp, who then, you know, details that, often with similar or different annotations, and then hands it over to the developer. Design system helps to short-circuit a lot of that stuff. And now I don't do wireframes anymore. I just do text. It's a simple text list. And it starts with, what is the job of this page? This page has to do 4 different things for the business and maybe 3 different things for the customer. These are the jobs that this is going to do. And I've got priorities around that and just march down the page and sort of say, all right, here's a section that needs to do this. And oh yeah, we've got a component that does this. And so that actually by the end of it, I've just sort of got a simple text list that I can discuss with both of you. This isn't even a handoff. It's sort of like, boy, I'm thinking that we can start with a— obviously we'll have a header and we'll have a hero element and then we'll have a set of cards that are specific to do this job and then this sort of sign-up thing because we need to do this job. And that it's really sort of a discussion that I don't need to do all this stuff because it's already documented in the design system. We have a common set of vocabulary, and it's just sort of like a, it seems like we can just march down and do this thing in order to accomplish these goals. What do you guys think? What's new that we need to build in addition to that existing set? How does that change your work?

It changes it completely, because so one of the things that we find all the time, right, and this is both scary and exciting, is that oftentimes I don't even need to be part of the mix. And you can work right with the developer, the interaction designer and the developer working directly to say, all right, I can build that and scaffold that out with the design system components that we've already got in the can. You don't even need the designer for that, right? Because those components are already designed. They've got CSS, they've got JavaScript, they've got the interaction there. So in one sense, that's really scary. Well, you just skipped me completely.

You're out of a job.

I'm out of a job.

All right. So, but wait, but wait.

What I can do now is apply for a new job, and that new job is all the stuff that I wanted to do that I never get time to do. Let me make a motion comp for how that component should animate better. Let me make some custom illustrations that will go on the top of this page to give it some character, some flavor. Let me art direct this a little bit more. Let me do a photo shoot so that we can go and, and, and plug in really great custom photos. All that stuff that I never got to do because I had to make every comp that you diagrammed and you gotta build I don't have to do that stuff anymore. So my job is now focused on critiquing the final work, right? You guys put it together, you come up with the first draft, we'll look at it all together in the browser and I go, "Well, it'd be nice to have a little bit more space here," or "It'd be nice to combine these two," or maybe swap out this component for this component. So my job becomes an oversight job, you know, and that's what designers are good at and trained to do is critique and revise and do that stuff. And my job is also what are the new problems to figure out, you know? A new interaction that we haven't considered, a new type of component we might need. So my job is focused on the new. And isn't that exciting for designers? Isn't that what designers want to do all the time? Is just do the new stuff. All the old stuff? You guys can take care of that. I actually got the better job.

When we built the design system for ExxonMobil, an engineer told us, you know, I was in a whiteboard session. We were figuring out what an application should do. And during that session, I use the design system to create a working prototype of the thing. You know, how exciting is that? To go from idea to prototype in the same meeting that normally would be kicking off a 3-week process. And wait a second, we're talking about— so no more wireframes, no more comps, all of the production, or at least the production of the components that we've already created, is suddenly in the browser and working software. This has changed our process a lot, but it also is like all of a sudden we have stuff happening. But now doesn't that mean that all of this is on your shoulders?

It's important to stress that a design system is not a panacea that we're just going to sort of plug in and just magically like, oh wow, everything is just perfect now and like no one has to do any thinking anymore. It's just getting that sort of first draft into the browser allows us to sort of understand what we all, you know, respectively have to do in order to bring this to design home. And the cool thing is, is that the byproduct of all of that thinking can then get fed back into the system. So every time you use the system is an opportunity to sort of bolster and enhance and improve and evolve the system as well.

It can sound like, wait a second, designers aren't designing anymore, it's all just developers doing cut and paste from this. But it's sort of like, well, this sounds like a whole bunch of cookie-cutter websites. Where is the work anymore? And it's really, it's sort of like, no, it's like you get a foundation for free. But then you have lots of opportunity to extend, improve, customize individual components to make it tuned perfectly for the job that needs to be done. The risk is that you can look at this kit of parts and think, "I am only allowed to use this kit of parts," which can sometimes mean square peg, round hole. I'm using the wrong thing because it's the thing that I've got available. And really there's sort of a thing of— and it takes time to get used to— I'm gonna use these pieces to design my webpage, my application, what have you. I'm gonna use these pieces, but I also understand that I have freedom to create new ones. And then I think there is a little bit more of a traditional role where it's like, I am doing some whiteboard sketching and wireframing with the designer or with the developer to create something new.