Building Design Systems that Work for Design and Dev

Parisa Bazl at UXDX USA. Video: https://youtu.be/JsFAYMo7Yyc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction: redesigning a large B2B application

[00:00:00] Parisa: Hey, everyone. I'm so excited to be here. I hope you've been having as much fun as I have in my home city, although the weather has been really strange for May. I had the same thought when I got on the subway that I've had this past week, which is that it's unnecessarily disgusting and I'm not sure why it's wet, but we're making do. Today I'm going to talk to you about building design systems that work for design and development. I work for Commvault Systems. We do data protection, cybersecurity, cyber resiliency. I've had a long career, for however many years, in B2B and a lot of SaaS apps. So really what we're looking at is what has been our design methodology that we've infused into our design systems in order to have the biggest impact possible.

[00:00:53] When they hired me in 2019, I walked into a situation like this, and I was like, I think it's great. No. I was like, okay, there's a lot of work to do. I'm going to talk to you a little bit about how we went from this to something like this across the entire application, and hopefully there are some takeaways that you can also bring back to your own organizations.

[00:01:19] There were a few things that we covered, and we'll go through all these in the presentation: getting the right buy-in from the right stakeholders, as well as establishing some key partners. Then from there, how do we derive patterns that really inform our design system? And of course some of the challenges, the very real things that we've had to overcome, or are still working to overcome, honestly. And then some benefits that we've gotten as well.

Getting buy-in from business stakeholders

[00:01:51] First things first, in terms of getting buy-in. What I say about UX is that everybody loves to weigh in on UX. I think everybody sees it as an opportunity. But when it comes to actually doing something about the experience, it is really mostly our problem. And it's not even just our problem in terms of the design solutions; we're going to make what we make. It's also managing all of the different voices that are coming into this, because everybody loves to be a designer, and it's easy for them to give their feedback to us in a way that isn't the same with the more invisible things like product management or development.

[00:02:37] In terms of these stakeholders, I think of them as different types. For our business stakeholders, these are folks where I try to ground the conversation around these four cornerstones. There's been a lot of really good discussion at this conference, I think, about how you actually quantify the value of UX, and I do think as an industry we're still really figuring that out. But I find that putting the benefits of UX into this sort of language, even if we don't necessarily have all the data in the world that we need, really helps people imagine the numbers behind it, so to speak.

[00:03:21] When I talk about the benefits of UX, I talk about how it can improve efficiency for our customers, meaning decreasing the time they spend on the task. How it can improve efficacy, meaning decreasing the error rate that the users of our customer base might be making. Improving learnability, which has a real business benefit in terms of cutting down on training costs and things like that. As well as improving likability, which really helps with brand trust. Talking about things in this way is really helpful for stakeholders who are not going to be in the day-to-day trenches with you, typically not the development teams, more the leadership on those teams, or product management. They don't necessarily care as much about how the sausage is made and everything that has to go into it. They just want to understand what the vision is and why they should be investing resources into this.

Developers, scale and the paradox of design systems

[00:04:19] But when it comes to the developers and the people who are in the trenches with you, the number one thing that I've found really resonates with them is the idea of scale. Engineers are always trying to do more with less, and the concepts of scale govern a lot of the tools that they work with as well, which we'll get into a little bit later.

[00:04:40] But here is really where the paradox of design systems is introduced. On the one hand, we want to generate as much consistency as possible, but on the other hand, we also need to optimize for very specific use cases. So there is this tension there, because you can't make things so small that you end up getting a lot of different combinations, but you also can't make them so big that people have to consistently break them. That's what I mean when I talk about this concept of modularity with a design system. What really matters is that you hit the right note in terms of modularity. Again, if things are too small, people are going to be able to mix them in too many different ways, and even though they might be using the same component set, you're going to get stuff all over the place. And if things are too big, it means they're constantly going to have to break things.

[00:05:38] I think the hallmark of a very healthy design system is that it generates consistency. Consistency is not something that should be enforced. If your team is spending a lot of their time enforcing consistency because people are putting things together wrong, what that indicates to you is that something is a little bit off with the way you've set up your system. It should be a naturally occurring byproduct of a healthy system.

Finding key partners in a large organization

[00:06:06] After the stakeholder buy-in, one of the biggest things that we did was find our key partners. Commvault is a fairly large organization. It's not the biggest one I've ever worked at, but it is pretty big. We have about 700 developers, maybe. And of course, like probably everyone in this room, we are disproportionately small in terms of function compared to the rest of the organization. This is par for the course with everywhere I've worked and with all of the folks that I talk to. So we are tiny and they are big, and we have to navigate the org in a way that's very deliberate.

[00:06:50] We cannot hold everybody's hand when it comes to actually delivering the right designs for them. It's completely unfeasible for us. So what we really need to do is figure out how we can lift all boats by giving people tools that help them get there on their own as much as possible. But in order to do that, we first have to design the stuff. So what we did was, across this huge organization, we looked at what the key teams are that we should be partnering with. From a development and implementation standpoint, what's the team that has the bandwidth for it in terms of resourcing, that has the right top-down pressure on it in terms of motivation, and that also, maybe just from a cultural standpoint, is going to be more open or excited about these things? This was not exclusively my decision; there were a lot of other folks that weighed in on it. But finding the right partners within the organization was very important for us when we were first thinking about redesigning this entire application.

[00:08:02] And within that team, within the landscape of everything that they're managing, what are the key pages or the key user flows that we should be focused on? Again, not entirely determined by me. It might be the thing that has the biggest impact on our customers, or the thing that we're getting the most pressure on from the market. So we looked at a few key user flows that encapsulate specific pages, as well as the sequence of those pages, and we honed in on that very specific area of the application.

Deriving patterns: object-oriented design

[00:08:43] Now I really want to get into the meat of this, which is designing, or really deriving, our patterns. We're doing the designs for those very specific use cases, like configuring a Kubernetes application for backup. You don't have to know what that means; I barely do. But we honed in on that very specific area, and so now we need to think about how we abstract that into a reusable pattern.

[00:09:13] The thing I want to point out for consideration is that with all of the design systems that have been published, if you go through and look at them, whatever it is, Material, Polaris, I don't know, what you'll notice is that everybody for the most part has the same components. Sometimes we have unique business components. But nobody organizes their patterns in the same way. It's kind of funny when you think about it, because technically, across all of your digital experiences there are a lot of similarities, whether you're shopping for an airplane flight or you're shopping for groceries or whatever. There are a lot of similarities across our digital experiences, and yet we do not have very clear instructions or guidelines around the patterns that dictate how those components have been put together. What that tells us is that as an industry, I think, we haven't yet figured out how to make explicit a lot of what we inherently know about designing things.

[00:10:19] So what we did was really think about how we were going to organize our patterns, and this is where we introduced a concept that I call object-oriented design. It's based off what is called object-oriented development. Object-oriented development is essentially a framework that governs a lot of our major programming languages, like Python, Java, whatever. This is also why developers are very familiar with these concepts: object-oriented development is a thing that they know and that they leverage every day. What it does is break down an application into reusable chunks, because remember, developers scale, doing more with less.

[00:11:09] When you think about something like, let's say, an HR application, what they do is have a concept called an employee. That's a data object. The data object is this concept that is the employee. Now, that object has what are called attributes, and the attributes are essentially the things that help to define what an employee is. Every employee is going to have an email, a first name, a last name, a role, whatever else, a salary range, location, et cetera. And every time you switch out the values of those attributes, you create a unique instance of that object. So instead of coding a chunk very specifically for every single employee, they have this backend template that they then repopulate to create several different instances. What this helps us understand is that there are these nouns, these chunks, operating in the back end, and those are ultimately the things that we actually design. These are the things that we're actually visualizing.

CRUD workflows as patterns

[00:12:22] The other aspect of object-oriented development is what are called CRUD workflows. CRUD is an acronym that contains every possible action that a user can do in any application. They can create things, which means they're adding a unique instance to the system: oh, we have a new hire, and so now I'm going to fill in all of Miranda's data. They can retrieve things, meaning they're searching, filtering or viewing a specific instance of that object: let me click on Miranda, and now that I'm her new manager, let me see where she lives, when her birthday is, whatever those kinds of things are. They can update things, meaning they can edit the values: Miranda moved, so now we need to update her address. Or they can delete things: she decided to move on and go to another company.

[00:13:26] So when we were thinking about our patterns, and about those key pages that we designed, what we did was abstract as much as we could. Okay, they were configuring something for backup; what that really meant was they were creating something. You have to do a little bit of work as a designer, because our language doesn't always directly map to this stuff. It's like, "Are you going to post that?" What you're really saying is, "Are you going to create a post?" So when you're thinking about deriving your patterns, what you have to think about is, in the work that you've done, where am I seeing create flows, where am I seeing retrieve ones, update ones and delete ones? And then specifically, what is the data object to which those actions are being applied?

[00:14:15] What you can see here, then, is how we looked at our key pages and bucketed them into those general categories so that they could be reused as patterns. Configuring something for backup meant they were creating something. They were viewing something, retrieving it, editing, deleting it. So instead of us thinking very specifically, "they are configuring a Kubernetes application," what we realized was that they are creating a new workload. And so now if somebody needs to protect, say, their Salesforce application, we can look at Kubernetes and say, well, in this case they're both creating things, so is this a create pattern that can be carried over to the same use case?

[00:15:04] This was extremely helpful for us because, as I said, we have a massive application, we have a ton of developers, and I cannot have a team member that's dedicated to every single area of the application. Instead it's, hey, we know that you guys have a lot of similarities, and this is how we're dealing with create workflows. And the developers are like, oh, of course, creating a new object means that we can follow these things. My attributes for a Salesforce application are different from the attributes for a Kubernetes one. Maybe they both have names, locations, whatever, but there are specific things about Salesforce. But all I have to do is switch out some of those attributes in that form field, or in that wizard.

Organizing components by purpose

[00:15:49] The other thing I want to talk about, from a component standpoint, is how we also use those object-oriented development principles in our design system to categorize our components. I think that Atomic Design has taken us pretty far, but I think it also possibly falls a little bit short in terms of our needs. And I also think it's a little bit strange that oftentimes we organize the components just alphabetically. So what we did was look at what the components do, what their purpose is.

[00:16:26] We have what are called layout components. These are invisible to the eye, and they essentially help format the things on the page. One of the main things they help format are what we call container components. These are things that you can see, like tiles or grids or lists. And what container components do is help to arrange what we call attribute components. If you think back to that data object, this is an attribute of that data object. We're looking at a specific workload. Every workload has a region. This region is something that is predefined. It's not a form field you can enter; it's a dropdown. So our dropdown component is an attribute component, because what it does is display the value of an attribute, and it allows users to edit those values.

[00:17:16] So we arrange these components around purpose. We also have action components, which trigger a workflow. And not pictured, we have system feedback components, which are things that are generated by the system based on some inputs from the user, like an alert that a threshold has been reached, a toast, whatever.

[00:17:37] If you look at our design system now, and this is a screenshot of it, what you see is that across the top we have our components organized according to their purpose. Every component has a link out to the development version of it, the actual code that the developers can pull, but we also have internal pages that detail what the components do, and dos and don'ts around them. You cannot nest certain types of container components within each other, for example. So we could put these guidelines around it.

[00:18:11] Similarly, within our design system we have a couple of things, like example pages and a couple of workflow patterns that are a little more specific to our app, but we have this general area of our CRUD workflows. If you have a new feature request coming in, and they're going to have to perform a restore of missing data, for example, then we do that work in the back of our heads. Okay, when they're performing a restore, what they're actually doing is creating a restore job. So we go into our create pattern archive, that section of the library, and we see whether these are things that can be pulled and applied to this specific use case.

The realities: time, lost battles and uneven adoption

[00:19:00] Quickly, I want to talk about the realities of this cold, cruel world. It's really nice to get up on stage and say, look, we have a shiny design system. But of course, as anyone in this room knows, it's not that easy. The first thing, and you don't have to read all this, but the main thing to notice is just the timeline. I've been at Commvault for five years, and to transform the entire application, we're looking at four years. I had to come in, I had to do a lot of observation, figure out the organization, connect with all the different folks, build all that trust. And then of course we worked on those specific design pages, and we abstracted the patterns. The design system is something we're always adding to. It will help get a lot of our projects 60, 70, 80% of the way there when we're first starting, but it doesn't have everything covered, so we are constantly uncovering new things and adding to the design system. But in terms of actually uplifting the entire application, I think it's a helpful reminder. We're often told that everything is an overnight success and things like that, and it's just not. Real change is going to take time.

[00:20:28] The other thing I want to point out: this is an older version of one of our landing pages, and you might ask, where is my page title? This page does not have a page title. This was a battle that I lost early on when we were designing those pages. I had a couple of other higher-level stakeholders who said it's another row that pushes all the content people care about down. And I was like, no, we need page titles. And then I figured, in the interest of building trust, in the interest of how early on we were in this endeavor, and the fact that I was trying to gain inroads, this is not going to make or break us from a customer experience standpoint, so I acquiesced. And of course, a couple of years later, when we were doing a full accessibility audit, we found that we had a failure because we didn't have a page title. And those same stakeholders were like, we should have a page title. And I was like, that's a really good idea. So you just lose some. It's fine. Pick your battles.

[00:21:32] And then finally, because this is something that scales out, it takes time. Not every team is going to be able to move at the same pace, so there will be breaks where they haven't been able to adopt your components. They're doing the best they can, and the entire application isn't shiny and new all at once, but it's fine. Don't let perfect be the enemy of the good.

Benefits: a single point of change and an easier way into design

[00:21:56] And then just really quickly, because I'm at time: leveraging benefits. We are continuing to evolve the UI. It's relatively easy to do so now that we have this single point of change. If we want to update the way that we're creating things, we can give everyone those guidelines around it. If we want to update the UI to match branding, that's really easy for us to do on a technical component basis.

[00:22:23] And secondly, in the past couple of years we were able to partner with a nonprofit organization in the New York City area to offer internship opportunities to folks who wouldn't normally work in design and didn't have any pathways towards this career. That's because, if you think about it, this kind of framework ultimately makes design that much easier to learn. There's a high barrier of entry a lot of the time into this field, and we were able to open up the opportunity because it was a very easy starting point for them: think about data objects, think about CRUD workflows. And we could ramp them up really quickly. That's all I have for you. I will be around if there are any other questions or things like that. But thank you. Should I go over here?

Q&A

[00:23:15] Host: Incredible. All right, let's see what we have. Thank you so much. Questions. All right, they're not coming up on here. Sure. Parisa, did you take a phased approach in implementing the new design system?

[00:23:33] Parisa: Yes, it has to be phased. We actually didn't have a design system when we were working on those example pages. We had best practices, but, as we were just talking about backstage [?], you have to write the book before you put it in the library. So that's really something that has to happen. We have to do a phased approach, both with all of the different patterns that we're uncovering, as well as with people's adoption of them.

[00:24:00] Host: That's awesome. What roles should be involved in creating a design system?

[00:24:05] Parisa: That's a great question. Obviously you have designers. We also have what I call UX developers. They're a little bit more technical when it comes to how these components can actually interplay with each other, and what we can codify versus what we don't actually want to write in code, in terms of getting people to follow it. Some things you can minimize their ability to change; other things you don't want to lock with the code, because they'll have to break it. So developers who have that front-end knowledge are very helpful. And then the backend developers as well. They're folks who understand a lot of the deeper technical constraints that we have to deal with for some of our patterns and things like that. So we had a couple of folks who, I wouldn't even say they're on my team; they're the people that work with my designers, who actually have to implement the components that we create, who actually have to implement our designs.

[00:25:05] Host: Great. That's good, to include everyone. I think we have time for one more question, real quick. What would you recommend when trying to manage an outdated design system distributed across existing pages that are actively being updated with a new system?

[00:25:23] Parisa: If I'm understanding this question correctly, you have to have a unifying framework. That's what I'm saying: when you take those object-oriented principles, it's very helpful. In terms of patterns, I would look at how users are creating new things. What are our major workflows? And if I want to change that, take an example of that and show how you would redesign it, and say, now this is how we're going to be creating new objects. We're not using a wizard for this multi-step process; we're going to use something else, I don't know.

[00:26:07] And I would say, if you are changing out your actual front-end components, we did that too. We moved from Angular to React in the same time frame. What we did was work with the front-end developers to get as much parity as we could in terms of the actual functions of those components, and then we infused the UI that we wanted into the new component set. But I would say, don't lose any functions, because that'll cause people to freak out. Sometimes there's interesting stuff built into your existing component set. Carry all that over, if you're now doing React, and build out your React tile or grid. But redesign it the way that you want, so that you can have that one-to-one mapping without freaking anyone out.

[00:26:58] Host: That's great advice. Thank you very much, Parisa. Let's give Parisa a big round of applause. Well done.

[00:27:02] Parisa: Thank you. Thank you so much.