Episode 4 - New roles and processes for a thriving design system

Dan Mall: I think design system is a thing that not one discipline could use on their own. 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. So, I think any good design system will need everybody on it to be able to do their best work.

DESIGN SYSTEMS: MASTERING DESIGN AT SCALE

Josh Clark: The very first stage, even almost ahead of or during initial research, is kinda retail politics, of really getting everybody on board whether you're a small organization, maybe a 10 person start-up, 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 really does that 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 it's not gonna work if it is something that it imposed on people. It can, but it's a really 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.

DESIGNING FOR TEAMS

Dan Mall: 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’ss 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.

One thing that generally comes with designers in a lot of organizations, design is at the top of the food chain. Designers make comps and everybody else has to build what those comps say. 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.

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." 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.

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?

Then on top of that, there's all the stuff that designers are already good at. Use this purple, don't use this purple. Don't use these other colors, or use these type bases, don't use these. Use these like that.

I think a good design system has those kinds of rules that ultimately should come from designers who are going, “let me think about what the best experience is gonna look like and 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. Let's limit that palette. 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, that's not too big and not too small, but just the right size for everyone to be able to do their jobs?

TOOLING FOR TEAMS

Dan Mall: One of the things that's really great is that because we're making tooling for each other, a 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. That's something that helps everyone on the team. The more we work closely together, the more we can actually come up with ideas like that.

Josh Clark: 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 token systems, essentially make it so that the design system just arrives in the tool that I use or in the coding environment that I use, so that the Sass variables automatically pick up the design system?

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 two years old and perhaps no longer in sync, because the latest is in my tool set using design tokens distributed through, for example, InVision Design System Manager.

Dan Mall: 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 gonna set up a 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 helping you in your job, you're helping me in my job and that's another example of that collaboration.

EYES ON THE PRIZE

Brad Frost: I think it's really important to understand that everyone's eyes should be on the prize. 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, could actually come together and actually assemble real living breathing product screens, product UIs that are able to serve real product needs. A design system can't just exist as a static UI kit 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 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 building out these components and widgets. 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.

A NEW PROCESS

Josh Clark: 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 was itself its own product that then I would hand over to a designer, who builds a comp, who then details that, often with similar or different annotations, and then hands it over to the developer.

A design system helps to short circuit a lot of that stuff. Now, I don't do wireframes anymore. I just do text. It's a simple text list. It starts with, what is the job of this page? This page has to do four different things for the business and maybe three different things for the customer. These are the jobs this is gonna do. I've got priorities around that and then it's march down the page and say, here's a section that needs to do this. Oh yeah, we've got a component that does this.

So that actually by the end of it, I've just got a simple text list that I can discuss with both of you. This isn't even a handoff. It's like, I'm thinking that we can start with, well, obviously we'll have a header and we'll have a hero element. Then we'll have a set of cards that are specific to do this job. Then this sign-up thing because we need to do this job.

Then it's really a discussion, 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 seems like we can just march down and do this thing, in order to accomplish these goals, and 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?

Dan Mall: It changes it completely because one of the things that we find all the time, and this is both scary and exciting, is that oftentimes I don't even need to be part of the mix.

THE DESIGNER'S NEW ROLE

You can work right with the developer, the interaction designer and the developer working directly to say, “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 because those components are already designed. They've got CSS. They've got JavaScript. They've got the interaction there. In one sense, that's really scary. Well, you just skipped me completely.

Josh Clark: You're out of a job.

Dan Mall: I'm out of a job. 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 or some flavor. Let me art direct this a little bit more. Let me do a photo shoot so that we can go 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 that you've got to build, I don't have to do that stuff anymore.

So, my job is now focused on critiquing the final work. 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 and that's what designers are good at and trained to do, is critique and revise and do that stuff. My job is also, what are the new problems to figure out. A new interaction that we haven't considered. A new type of component we might need. So my job is focused on the new. 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.

WHERE’S THE WORK?

Josh Clark: When we built the design system for Exxon Mobile, an engineer told us, “I was in a whiteboard session. We were figuring out what an application should do. During that session, I used the design system to create a working prototype of the thing.” How exciting is that, to go from idea to prototype in the same meeting that normally would be kicking off a three week process?

Brad Frost: That's right.

Josh Clark: But wait a second, we're talking about 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 changes 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?

Brad Frost: It's important to stress that a design system is not a panacea that we're just going to plug in and just magically like, "oh, wow, everything is just perfect now and no one has to do any thinking anymore."

It's just getting that first draft into the browser allows us to understand what we all respectively have to do in order to bring this design home. 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 this system is an opportunity to bolster and enhance and improve and evolve the system, as well.

Josh Clark: It can sound like, well, wait a second, designers aren't designing anymore. It's all just developers doing cut-and-paste from this. It's like, well, this sounds like a whole bunch of cookie cutter websites. Where is the work anymore?

It's really, no, you get a foundation for free, but then you have lots of opportunity to extend, improve, and 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.

Really there's 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.

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.