Design Systems of Change
Checking session availability…
Hang tight while we load the latest updates.
The way we approach digital software design creates huge barriers for entry, requiring advanced learning and expensive supplies to qualify someone for the position. To expand opportunity, we have to make it easier to learn how to design. By simplifying and externalizing design logic within our design systems we are able to scale and operationalize DE&I initiatives by quickly and effectively training unskilled workers from underrepresented communities. This helps us meet critical business needs for asset production while providing an entry point to design in a cost-effective, inclusive, and mutually beneficial way. We discuss a use case where such an initiative brought demonstrated value to one company’s product development cycle.
Design Systems of Change
Parisa Bazl at UXDX Community: Innovation and Change. Video: https://youtu.be/s_b5Fff-mWc
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.
Opening clip
[00:00:00] Hence the extensive training and experience that's required in order to actually qualify someone for a role. The implications of this are twofold. The first is that there's talent scarcity, so design services can be very expensive. From the business side of things, this results in corporations unable to meet their business needs, and startups or smaller organizations incurring design debt because they can't afford to prioritize the expertise. But the second, and arguably more important, impact of this is that there's a severe lack of diversity and representation, which then results in non-inclusive products that are often of lower quality as a result.
Design as a language
[00:02:15] As mentioned, my name is Parisa Bazl, and I'm head of user experience design at Commvault Systems, which is an IT software company, a large, publicly traded B2B enterprise software corporation. Today I'm going to be giving a talk called Design Systems of Change, and it's about how we can utilize design methodologies to create equitable employment opportunities within the design world.
[00:02:41] I've been working in the field of user experience design for about 12 years now. The primary focus has been on B2B SaaS apps, and my expertise is in integrating design into the overall product development cycle as a fundamental part of it. But I never really planned on working in technology. I found my way into it by way of medieval and early modern literature. I studied a lot of Shakespeare, Dante and Chaucer in undergrad, and I had a very related interest in the evolution of language. So I'd like to get back to my roots today and start this talk by exploring some of the parallels between written language and design.
[00:03:32] Language, at its most obvious, is the thing that helps us express ourselves. But more accurately, language is a framework by which we organize and process our experiences as we take them in, and we utilize that same framework to communicate our thoughts outwardly, so that we can create connections. So there's this very reciprocal arrangement between the language that we use and how we perceive the world. For example, if our language only has two words for gender, he and she, then we subconsciously cultivate a viewpoint of the world in that same binary.
[00:04:14] If you were to describe to me an application that you want to build, there are a couple of different ways that I could document these requirements. Most obviously, I could write them down. But being a designer, the other option I have is to draw them. I could map out user flows for scope, and I could create screens that reflect content and functions. These tactics also crystallize requirements, but instead of words, I'm using pictures. The former method, the written one, translates the spoken word into a written language, and the latter translates the spoken word into a visual language.
[00:04:53] Like all languages, only a subset of the population is fluent in visual design, like many of us here. I'm talking specifically about visual design that's used for digital experiences. Being fluent in this language is valuable in several ways. For one, we can charge money for it. But even more importantly, we can play an active part in the evolution of the technologies that shape our collective human experiences, similar to how the spoken language shapes our mindsets.
Barriers to entry and their consequences
[00:05:30] The visual language is generally inaccessible without a certain level of affluence. In order to become fluent in this language, we not only need access to a computer and expensive software, but we also need experiences that bring us into the world of software development. These typically take the form of higher education, and if said higher education is only indirectly related to design, then we usually require additional and costly formal training as well. These are significant barriers to entry, and that means that design is often confined to a homogeneous group of people, and this tends to have very unfortunate effects.
[00:06:11] Wealth gaps that are based on race, gender and other social factors are exacerbated by technology that's designed without appropriate representation. We end up with facial recognition software that incorrectly identifies Black people, financial experiences that don't account for the unbanked, search algorithms that reinforce racism, and face filters that often promote stereotypes. None of these things are necessarily intentional, but they also aren't accidents.
Components are letters, but the grammar is missing
[00:06:46] Building on what I spoke about before, these parallels between written and design language, we can go back to written language a little bit and look at letters. They're the basis of our written language, and we put different letters together to make words. Words are then assigned meaning based on what they represent, and words also become much more meaningful when they're arranged with other words into sentences.
[00:07:19] Like letters, front-end components such as checkboxes, dropdowns, grids and things like that are the basis of our visual software language. We put the most granular components together to make more complex ones, like how a checkbox and a dropdown can be combined to make a multi-select dropdown. And similar to words, components are also assigned meaning based on what they represent. For example, a multi-select dropdown is empty until we fill it with a list of countries that the user can select if they're specifying their origin for a profile or something like that.
[00:07:56] But because the written language has been around a lot longer than the digital design one, we have established methods for formatting it. Spelling rules and grammar rules are often what help us ensure that we're putting letters and words together in ways that make sense. We learn the different sounds that different symbols make, that adjectives go before nouns, we learn about present and past tense, and knowing these things means that we can create increasingly complex words and sentences to make paragraphs, stories, whatever, from there. But by contrast, the language of digital design lacks these clear spelling and grammar rules.
[00:08:37] You can see here that the fact that there are so many iterations on what is essentially the same thing is indicative of the idea that, while we may have general agreement on high-level best practices as an industry, we don't have an established set of specific rules that govern component arrangement into patterns. The lack of explicit rules for our visual design language is one of the key things that makes it that much more difficult to learn, hence the extensive training and experience that's required in order to actually qualify someone for a role.
[00:09:12] The implications of this are twofold. The first is that there's talent scarcity, so design services can be very expensive. From the business side of things, this results in corporations unable to meet their business needs, and startups or smaller organizations incurring design debt because they can't afford to prioritize the expertise. But the second, and arguably more important, impact of this is that there's a severe lack of diversity and representation, which then results in non-inclusive products that are often of lower quality as a result.
Simplify the rules to scale literacy
[00:09:46] So how do we really meet this challenge of design literacy? Again, let's say that we're given the directive to make as many people literate in the written language as possible, and we are able to do it by any means necessary. It's carte blanche [?]. If our aim is scale, then you really have to think about what our biggest leverage point is. Should we only consider tactics that promote teaching the rules? Then we'd be focused on getting more funding for learning centers or educational initiatives and things like that. But if we shift our focus to simplifying how written language is constructed, so that it becomes easier to learn, we'd be able to be effective for many more people. In short, if we want to make as many people literate in the shortest amount of time possible, we should change the way that we spell, or rather, simplify the rules that govern our language.
[00:10:46] For example, while we do have spelling rules that dictate which letters represent which sounds, those rules can change or get confusing. There are so many examples of this convolution; once I point it out to you, you'll probably never be able to stop seeing it. But many of them are demonstrated in this word, technology, where the K and the J sounds are indicated using different combinations of letters. The context of the surrounding letters often changes the sounds into something totally different. If we're exceptionally fluent in the English written language, then we understand this and we recognize it without actually thinking about it. But if we're unfamiliar and we're trying to learn it, we would possibly sound out all of these words totally differently.
[00:11:35] The same notion applies to our visual language as well. While our components, our letters, are pretty established, our rules for putting them together are not. But if we can create a simple, replicable set of rules that generate predictable outcomes, we can make visual design that much easier to learn, therefore reducing costs and creating opportunities. This is how we might think about design in a way that we would incorporate into our design systems, and essentially into our overall framework of design.
[00:12:14] We've reached a point in the technical age where redundancy is actually a very key part of digital design. The reason that many digital experiences resemble each other is because it's important to leverage learned behavior in order to make a more usable experience. That's not to say that these things can't be evolved, in terms of what Google initially did to search, and honestly what TikTok is doing to it now. It only means that once something has proven to work really well, it should be used, so that we can focus on other areas that are worth innovating on. It's basically the digital equivalent of not reinventing the wheel. We might make improvements to adapt to changing conditions, but evolving our modes of transportation has been much more dependent on other aspects of the transportation experience, such as the engine, or the actual container that you're moving in.
[00:13:11] Common patterns like these are things that designers tend to know because of their experience. It's like we can read the words, but we don't necessarily think about how they're spelled so that we can teach other people. So we need to shift our focus from writing the words, or creating the designs, to writing the rules for writing the words. The next frontier of UX design in general is less about what we design, and much more about how we design.
An object-oriented design system
[00:13:42] A quick scan of different design systems, like Material or Polaris, shows us that our means of putting components together are inconsistently documented. So while we might have general agreement on high-level best practices as an industry, we don't necessarily have an established set of specific rules that govern component arrangements. My team and I have been very conscientious about how we design, and about recording that within our own design system. We wanted to better integrate design into the overall development process and externalize the logical framework that we use, so that in doing so we make our design decisions explicit.
[00:14:25] We took concepts from object-oriented programming and applied them to our patterns. Our templates, our common page patterns, are organized according to CRUD principles, as well as data context. When I say CRUD, it's an acronym that stands for the possibilities of what the user can be doing. They can be creating an object, which means adding it. They can be retrieving it, so searching or filtering it. They can be updating it, or editing it. Or they can be deleting it, or removing it. So that's the concept, the acronym, of CRUD.
[00:15:04] Then we cross-reference that with the data context, which means the level in the data hierarchy where this action is taking place. Is it taking place on a main object? Is it taking place on a group of objects? Or is it taking place on a reference, or a child object that has a parent? Answering these things helped us determine the arrangement of different components that we needed, and helps us drill down to the correct pattern using the systematic, logical framework: what is the CRUD action, and where is that action taking place? That is a high-level overview of it. There are a lot of nuances that go into it, but for the purposes of demonstrating this within the talk, at its simplest, that's really the state that we're starting in.
Scaling the team through a training partnership
[00:16:02] When it comes to my duty as a UX leader, I have two big things. The first is that it is my responsibility to achieve scale across an organization. That means that I need to make the design team as effective as possible while also keeping costs as low as possible. I prefer to think of this as: you have to pay people the right amount, what they deserve, but you also need to pay the right number of people, especially as it relates to the roles that you need. The second thing that I really take on is that I need to help diversify the field as much as possible, in order to protect us against a dystopian future where technology just exacerbates inequality as opposed to minimizing it.
[00:16:48] At my current organization, to scale my team in order to meet internal demand, I was looking at an additional four headcount, which according to certain job reference sites would run me anywhere from 240 to 320 annually. I'm in the New York City metro area, so I could potentially outsource this overseas for cheaper costs, but the quality would often suffer, with me juggling multiple time zones, and more importantly, I would also be taking opportunities away from the local economy. So I wanted an alternative resourcing option that would be a cost-effective investment for the company and for our surrounding community.
[00:17:35] We saw our design system as a key means to scale our abilities as a UX org. The purpose of any design system is really to generate consistency while also optimizing the UX for very specific use cases. When we infuse it with these object-oriented principles, it means that we can create a clear picture of the logical framework by which we design: again, that decision-making process for how you ultimately spell a word or write a sentence.
[00:18:08] In doing so, we were able to open up the opportunity to join our team to people who had zero user experience design skills. We partnered with a nonprofit that provides professional readiness skills to youth who have non-traditional educational backgrounds and who come from households of a certain income within the New York City metro area, and we source our candidates through them. Through them, we were also able to utilize money that came through government funding, so we could pay these UX students to train with us for 175 hours at zero cost to the company that I work for.
[00:18:52] Of course, we did have to provide a senior-level person to train them, but if you time that right within the development cycle, you can typically pull it off. On top of that, it also gave people the management experience that they were looking for and hadn't had an opportunity to have yet. This really reduced our onboarding time, and it also made new headcount a lot less intimidating to me, should we need to expand the team even further. After they were done with training, we brought them on for 40 hours a week for six months, which has since been extended. So that's been really effective for us in general.
[00:19:38] Not only do we strengthen our organization by employing from a diverse candidate pool, but from a business side we also save ourselves lots of money in salaries, with candidates that we've actually been able to vet for several weeks prior to taking them on. We vetted them throughout the training, and they also had additional support from the nonprofit they came from, a steady backbone in terms of integrating into this new environment, especially with it being remote.
[00:20:13] Multiple studies will show too that this has long-term benefits on cost as well, because when we provide training for people, it also helps to cultivate loyalty and often results in lower attrition rates. But I think most importantly, we were able to create access to opportunities to work in software design. Maybe not all of these newly minted designers will stay with us forever. Maybe other companies will interest them, or other aspects of product development. But the point is that by making it easier to learn how to design, we're not only able to alleviate our own concerns about resourcing, but we can help all kinds of people contribute to the evolving digital ecosystem.
[00:20:55] I'm really excited to share that with you. It's been a very fun journey, I would say, for all of us, and it's been very impactful, from both a business standpoint and a personal one, for myself and for the interns and the other designers that were involved with it.
Q&A
[00:21:32] Catherine: Thank you so much, Parisa. That was fantastic, really interesting. For me it breaks into multiple different parts. I wanted to go back to the program that you had for hiring people, because I've never actually heard of it. In Ireland they do something similar, but I've never seen a tech company actually utilize it, and actually go to the effort of training people and building it out. Where is the project now? How many months in is it? How long has this been going on for within the company?
[00:22:23] Parisa: We're almost at the year mark, actually. We're looking at possibly opening up full-time positions, depending on budget and things like that, but either way, portfolio preparation for some of these folks. So it's been going on for quite a while, and they're all fully operational. Even by the end of training, we actually had them working under the direction of a senior designer acting as manager. They were all pretty fully operational, working a little bit more as groups towards the beginning, but now they're pretty independent on projects, and they're also able to leverage a lot of the knowledge that they've built up over the past several months. They know our product pretty well at this point, and have some working relationships and things like that.
[00:23:17] Catherine: A year is phenomenal, and this might be too early a question, but have you looked at stats on the retention rate for employment? Is it higher or lower? Do you have a gut feel on that yet, compared to, say, a traditional, high-paying, standard UX route?
[00:23:36] Parisa: They're all very committed at this point. From a business perspective, you could really keep these people on for quite a long time, and it's really impactful and helpful to the business. Our cost per project has gone down 75%, and our output has gone up over 67%. So as a team, we've been able to generate these outputs and iterate much more quickly. From a human perspective, I'm not interested in stringing people along if there wouldn't be a legitimate full-time role for them. I think after a year's worth of intern work in this field, you can stand up; you've got some projects that you can really count on. So we're looking at possibilities of full-time employment here, or just giving them some training, like I said, in putting a portfolio together, speaking to work, that kind of thing.
[00:24:35] So, a huge impact on the business. It's also a diversity win. It was a small recruitment pool; we brought four people on. But we have 50% Hispanic, which is so much higher than your average Hispanic or Latino representation in the tech industry as a whole. And I think the big thing for us has also been the age component, because especially in enterprise software there's a huge percentage of people that are 45-plus. That's great in a lot of ways, but especially at the types of companies that I work for, they do need to be very conscientious of how they're cultivating that next generation of talent. So I think that's been very important for us as well.
[00:25:28] Catherine: It's really phenomenal, and it's something I think a lot of companies could learn from. When I asked the question about longevity and turnover, I probably meant it more from the organization's side: would they be let go, or not utilized? As you said, you're doing them a service by training them up. They're now qualified; it's a stepping stone. I was just curious how tough and rigid you would be on maintaining them into a full-time position.
[00:26:08] Parisa: There are a couple of factors that are less in my control there, but that is something that's being pushed for, not just by me. DE&I and a lot of aspects of the business have a vested interest in this, so we're quite hopeful.
[00:26:30] Catherine: And from a company-wide perspective, have you seen anything in terms of profitability? You mentioned numbers there, a 75% reduction. Do you see that directly as a result of this, or are there any other factors?
[00:26:46] Parisa: Oh no, that's pretty much a direct result of this. Like I said, we grew our headcount in this way, and so it was really impactful. We have a senior designer helping manage all their work and getting the projects off the ground. Not only are we able to take on a higher quantity of projects, but we're also able to complete them more quickly, because what was a more senior-heavy team previous to this doesn't have to do as much context switching now. They're not juggling as many projects. So we've been able to be super focused, in lockstep with the PMs and the engineers that are involved with each project, and as a whole it's just helped us push things out that much more efficiently and effectively.
[00:27:38] So it's really been a direct result of that, because even if people aren't working directly with these folks, some of the other senior designers on the team are still getting the tangential benefits of not having to juggle so many things and take on so many things at once. So that's great for everybody.
[00:27:57] Catherine: It's phenomenal. Are there any opportunities to scope it outside? Has the wider organization looked at it in terms of going beyond UX and design?
[00:28:06] Parisa: They have. They're seeing this as a really significant success story. I know that in product management, for example, there's a lot of need there, and the same in development. Where the challenge is, is that the key to this was really that we were able to externalize a framework for people to follow. That framework doesn't capture every single nuance; there are things that you can only learn on the job. But it is a really critical starting point; it gets you there. So I think the challenges and the opportunities with the other roles are to really look at what we can distill into a framework that would actually prove very effective for training and onboarding within the 175-hour budget.
[00:29:02] That's something I would love to collaborate with those teams on. On a day-to-day basis it's sometimes a little challenging to do that, but there's definitely interest in it, and I think it would just require a little bit more partnership. Being a designer and working with my team, for us that part of it came very naturally.
[00:29:25] Catherine: Phenomenal from start to finish. Thank you very much for sharing that, and for your insight on changing the ways that you work. But as with all things product development related, there is no one-size-fits-all, so please do share your thoughts in the comment section below and let's keep the conversation going. Finally, if this video resonated with you, please do us a favor and hit that like button and subscribe to our channel. This not only keeps you up to date with all of our latest content, but it also helps us with the YouTube algorithm. Lastly, if you want to keep learning, we have a couple of videos suggested here, but otherwise, until next time, take care and enjoy the rest of your day.

