Episode 6 - Maintaining and Evolving Your Design System

Episode 6 - Maintaining and Evolving Your Design System

Josh Clark: It's important for a design system, and really any product, to have a set of guiding principles that will govern the decisions that the team is gonna make. Why is this product the way that it is? Why are we gonna make the decisions that we're gonna make? A big way that we do that is by creating design principles for the project. Design principles are things that emerge from a combination of the business goals, the user promises that we make—what do we need to do for users, what do we need to do for the business? You kinda marry those into principles that say something about what the product is or does.

DESIGN SYSTEMS: MASTERING DESIGN AT SCALE

Josh Clark: The importance of design principles is to actually help people make a decision when there are two viable paths. A design principle like “clean and simple” is probably not gonna be very useful, because no one wants messy and complicated as their by-word. Instead, we wanna have some principles that help to make decisions when you're at a fork in the road, where a reasonable person could go in one direction or another. So, design principles become these things that are rallying cries in a sense, reminders of what is in our path and help us to make decisions when there are competing directions that we might go in.

GOVERNANCE

Brad Frost: We put all of this work into this thoughtful component driven system and there's all this great thinking baked into this thing, and nobody uses it or it becomes outdated. The whole thing, all of that effort, just gets thrown in the trash can. Because, as soon as all of that knowledge locked up in that style guide website ceases to reflect the reality of how your products actually get things done, it ceases to be useful.

We've encountered many organizations that have a graveyard of design systems littered throughout their history, sometimes going back almost a decade. Oh yeah, here's this first pattern library effort and here's where we tried it again and here's where we tried it again. So, governing a system is probably the most critical piece to get right.

Josh Clark: When we talk about governing a system and what is design system governance, really what we're talking about is - how do we make sure that it keeps up with the needs of product and likewise, as the design system improves, how do we roll those changes into product? I guess then, let's get down to brass tacks. How do you, after you've built a system with a few pilot projects, start to build additional projects with it and roll those changes back into the design system and vice versa?

Dan Mall: I think maybe one of the obvious things that needs to be said is that if pilot projects are what got you to a design system, maybe pilot projects will keep that design system running. I think that, again, the design system serves products and it's supposed to be a product that helps you make products. So, keep making products. But, don't keep making products in isolation. Keep making products with an eye toward - how does this affect our design system? Does it change it? Does it edit it? Does it modify it? Do we need to remove things from it that we don't need to support? Do we need to add things to it that we now do need to support?

One thing that's a really actionable step is keep making products, but maybe build into your process one or two checkpoints, maybe in the middle of your project, to go - are we using all the things we need to use from the design system? And then, at the end of that process, going okay, what can we actually take out of this product, harvest back into the design system either by adding it or by changing something that's already there?

Josh Clark: Who's doing that work of auditing products and harvesting them for design system improvements or additions?

Dan Mall: There's a couple of models for that, and there's lots of good writing on this. Gina-Anne has written some really great stuff. Nathan Curtis has written some really great stuff about this.

I'll start with the first one and then maybe you guys can fill out. Maybe the most obvious one is your design system might not get a lot of love when it's first at your company. Maybe you've gotten buy-in from everybody but then everybody's forgotten about it while you're building it. Typically what happens is there's one person and it's just that person's baby. That could be a product director or it could just be one fledgling designer or developer that's just really passionate about this stuff. And, that's cool. That's great. At least somebody's passionate about it.

What we find is very rarely is that person actually able to sustain a design system, one person having oversight of the design system, because if all things go well, if you've done all these things, they will go well, you very quickly get inundated with lots of emails. People going - how do I use this or how do I maintain it or how do I update it? So, one person is a good start, but it's not a sustainable model for one person to have oversight of the design system. What else? What are some other ways to do it?

Brad Frost: I think that another team model that can work well at an organization is the “centralized” team model. You have a dedicated product team that is responsible for making, grooming, maintaining, and evolving the system. That kind of team structure has the “systems” view. All of those people are thinking about the entirety of their product ecosystem at the organization.

The risk with that model though is that it can lose that “on the ground” perspective, that individual “product need” perspective.

There's another team model, which is the “federated” team model. This is where you don't have a centralized team doing all of that production work but rather representatives that work on different products scattered across the whole organization. You might have a front-end developer working on this product and a designer working on this other product, and all of those people are representatives that are maintaining the system.

The risk with that though is that product roadmaps always take priority. So, those people's attention are split between serving real product needs. As a result, the actual system, in that bird's eye perspective, is lost and the whole thing just gets swept away.

Another model, and Gina talks about this, this is the model that they put in place at Salesforce whenever she was working on the Lightning design system. It's called the “cyclical” model, or the Salesforce model, which is basically a combination of a centralized team and federated members. There's close pairing that happens between those teams. You have a centralized team that's doing a lot of work, but then there's also federated members that are able to feed that “in the weeds” perspective to the design system.

Dan Mall: It is a diverse model, where there's representation from all around the organization. You’ve got some bird's eye view people, you’ve got some “on the ground” view of people that are making products with the design system, both makers and users.

I think it's worthwhile to populate that with other people from the organization. Maybe you have people that are executives on that team and you have people that are makers doing the work as well, so you get different views of the organization too. I don't know that we've particularly seen this model, but I think it scales well too, where potentially you could even have some people who don't even work in your organization as part of an advisory board for that.

Brad Frost: That's exactly what the team at Etsy did. They established a design system committee that met regularly. I think it was once a month, or continues to meet, hopefully, once a month, where they have representatives from a bunch of different areas that get together. There's a committee leader, but then they also bring in different owners from different products, so you have different products represented as stakeholders in the system.

And then they have different platform representatives, people working on their web properties, their iOS properties, their Android properties, their email properties, all with a seat at the table.

But then also, they brought in, I think this was especially clever, bringing in subject matter experts that might be working on specific products, but if you have an accessibility guru and a performance guru and a responsive design guru, each scattered across the organization, they come in as an expert and lend themselves to this committee.

What you end up with is this really nice cross-section of stakeholders and experts all dedicated to growing and maintaining the system and making sure that it continues to serve all the different products and platforms successfully.

CULTURE

Josh Clark: I think one of the changes too, as we think about governance, is that there is a cultural shift of - how do we encourage people to think about we're creating together this common body of design, philosophy, and standards and interactions that we can all commonly use from which individual applications will spring.

Dan Mall: But, we have have seen organizations that go - that's opposite of our culture. It's not that they're opposed to it, but they're just, like, we couldn't flip a switch and then all of a sudden we've got this open-source model and culture here. So, I think it's important to say that there are steps to get to that too. We've seen all different permutations of that, where some organizations go - yeah, we can do that because we have something like that already existing here and so that folds in naturally.

We've also seen - let's just first set up an email address so that people can email us if they have questions about this. That's a good first step too. We've seen groups set up Yammer Communities or intranet groups or private Facebook groups or Slack channels dedicated to the design system as a way of going - we can't really go full open-source yet because of the politics of our organization, which are very real, but we can do some semblance of that.

I think that's okay, because that's a way to build up to that point, where we're starting to create that culture. You don't create culture overnight. Maybe in a year we'll get to that point, and in the meantime, we'll have open contributions via email or a forum or something like that. So, it's not all or nothing. It's definitely stages to be able to get there.

Josh Clark: I think one of the things that we want from a design system as we make these is for people to be enthusiastic about it. To be like, yes, I wanna use this. I recognize myself and the way that I want to do design and development in this system. The biggest way that you can get people to feel invested is to let them invest in it and to signal we are open to improvements on this.

Again, humility is such an important part of creating a design system. This is not something of us telling you the best way to do something. It is we are here to support you. What do you need to do your job the way that you want to do it?

Brad Frost: That's right. And, I think that there are, as Dan said, a number of different communication channels. Having a Slack channel that's dedicated to it and the team that is invested in making and maintaining the system, that hangs out there and is eager to answer any questions is good customer support.

But also, regular state of the union meetings. Updates on the roadmap whenever you do a release. We've seen regular email campaigns, where every month the team says here's what's new to the design system and here's the MVP person that just really killed it on this product. Look at this really cool contribution that they made, or look at how they used the design system in a novel way. All of that helps foster this sense of shared ownership and contribution and encourages this culture.

DESIGNING FOR WHAT’S NEXT

Josh Clark: The amazing thing is, once you have a design system in place, you have a common set of components that everyone understands. Designers, developers, UX designers. And, a common set of names.

What that means is that when we're all working together, I can just call it by name. We need a carousel here. We need a slideshow here. We need a card list there. Whatever names we've come up with, we can just refer to them.

I think an interesting thing is, is that we're actually now talking about creating a shorthand for visual design systems, where I can write it down and we've got the names there, but it's like - what if we could actually speak this out loud? Or, what if we could take our wireframe and take a picture of it and know those symbols and actually even the machines could start to translate it? We're starting to see that happen with companies like Airbnb experimenting with taking wireframe drawings and using machine learning to map those to design components that you can actually put into a page.

I think that that shows the importance of being fluent in multiple platforms when you're designing for design systems, but also multiple inputs. I think it's important to remember that we're designing not just for the screen now, but we design for keyboard-only experiences or voice-only experiences.

At the same time, there's also a lot of excitement about emerging channels and emerging interactions, about speech and about augmented reality and all these different new ways that we're able to talk to the machines. A design system can capture those conventions too, as companies start to build those out.

For a speech interface, you may have a bot or an interface that has a certain personality, and that's something that should be recorded with common phrases. For example, how you do confirmations, and different language around that. You could even have some things like Alexa has, which are called speechicons. “Badabing,” believe it or not, Alexa knows how to say.

You can build in these flourishes as a library. In the same way that we have icons that we have in a system, you can have things like speechicons as a collection. All this is to say that for every different channel that you use, there are likely to be guidelines and conventions that you want your designers and developers to use, and as much as possible, get that close to the code. So, here is actually the code snippet that you use for that speechicon in your speech interface, for example.

A design system consists of more than just a UI kit and a pattern library and a code library. It's also all of the different ways that you communicate and interact with customers.

So, it can include things like a writing style guide or voice and tone. You think about voice and tone, that's also especially important, as we have this emerging future of speech assistance and bots. What is the tone of your bot? How does it talk? Should it have a big personality or should it be a neutral assistant?

All these things are things that as an industry we're starting to figure out, but your company needs a point of view, and the design system should have that point of view too.