Season 1 / Episode 3
What is a Design System?
Season 1 / Episode 3
What is a Design System?
Featuring
Varun Vachhar, Catherine Maritan, Jennifer Shannon
Date published
April 18, 2019
Tags
User Experience, Design, Development
Also available on:
In this episode, Jennifer Shannon chats with Varun Vachhar, Director of Technical Strategy, UI Architecture at Rangle, and Catherine Maritan, a Senior Experience Designer at Rangle. Listen as they dive into defining what a Design System is and why it should matter to your organization.
"We always use the analogy with kind of Lego blocks. Being able to, if you design a button once, why do you ever need to design a button again? You've already thought about those interactions and if you build that piece, you don't really have to think about that interaction anymore. Every time you are just coming up with a new design, you take that button and you slot it into the design."
In this episode, Jennifer Shannon chats with Varun Vachhar, Director of Technical Strategy, UI Architecture at Rangle, and Catherine Maritan, a Senior Experience Designer at Rangle. Listen as they dive into defining what a Design System is and why it should matter to your organization.
"We always use the analogy with kind of Lego blocks. Being able to, if you design a button once, why do you ever need to design a button again? You've already thought about those interactions and if you build that piece, you don't really have to think about that interaction anymore. Every time you are just coming up with a new design, you take that button and you slot it into the design."
00:04
Hi, everyone. My name is Jennifer Shannon and I'm your host. Welcome to What's Your (R)angle? On today's episode, we're looking at a fairly new idea in the digital transformation landscape, that of the design system.
00:14
With me today are Varun Vachhar, Director of Technical Strategy, UI Architecture at Rangle, and Catherine Maritan, a Senior Experience Designer at Rangle. Welcome everybody.
00:23
Catherine M.: Hi.
00:23
Varun Vachhar: Hey.
00:24
Jennifer: I think, probably, the way we start most of these podcasts is just to really get an idea of what it is that you're doing at Rangle. I know that seems like a silly question, but I think it's important to understand about how you're working with clients, and how you're working with your colleagues, and what your role entails here.
00:38
Catherine M.: Yeah, for sure. Yes, as you mentioned, I am a Senior Experience Designer at Rangle. What that means is I'm kind of at the ground level, working with other designers, working with developers to kind of sit with clients and figure out whatever problems they have and whatever projects they want to bring to life, where we're doing that with them.
00:59
A lot of my day-to-day role does involve a bit, design systems and what we'll do is help that come to life.
01:08
Jennifer: It's a pretty great job.
01:10
Catherine M.: Yeah. I mean, I like it.
01:14
Varun Vachhar: My role is to lead the UI Architecture team, which is sort of an interesting team that sits in-between technology and design. It's a team of developers, which have some kind of background in design. What we found was that as we were doing more interesting things at a larger scale, building out things like design systems, we couldn't really work in a traditional model where you had a design and tech kind of working in isolation.
01:39
We needed to facilitate more conversation between those two groups and sort of break down those silos and find ways of working together. That's been sort of one of the main focuses for me at Rangle and for my team.
01:51
Jennifer: Wow. Really cool. I think I'm going to start with the big question. What is a design system? Varun, why don't we start with you this time?
01:59
Varun Vachhar: Sure. That's a, kind of a hard question to answer because different people define design systems in different ways. Quite often, I find that people have a brand guideline or a style guide that they've built out for their product, and they call that a design system. Or engineering teams will build out a component library and they'll call that a design system.
02:25
What we've discovered over time is that a design system is really just a clearly defined way of how you're going to go from an idea, to something in the hands of a user in a way where designers can spend most of their time designing and developers can spend most of their time developing, and there is very little need for a handoff.
02:43
Now, how that happens is you invest in all of those things. There is probably going to be some sort of a style guide. There is going to be a component library, and there's going to be a whole bunch of other things that kind of support this whole infrastructure and allow you to come up with the most streamlined process for delivering products.
02:57
Catherine M.: I definitely agree with everything Varun said. It kind of, I mean, traditionally, from the design side, like we've really focused on the what we're designing, spending a lot of time like thinking about the nitty gritty or, "What should this UX interaction be? What should this UI color be?"
03:14
With a design system, it kind of shifts that focus and allows us to think a lot more about the "how," or it kind of, the design system does a lot of the heavy lifting about the "how." When I mean, "how," what I'm thinking about is kind of, "How can we design more consistently?"
03:30
We always use the analogy with kind of Lego blocks. Being able to, if you design a button once, why do you ever need to design a button again? Like you've already thought about those interactions and if you build that piece, you don't really have to think about that interaction anymore. Every time you are just coming up with a new design, you take that button and you slot it into the design, so-
03:52
Jennifer: As a component.
03:53
Catherine M.: Yeah, exactly.
03:53
Jennifer: Yeah, interesting.
03:54
Catherine M.: As a component. There's the "how" in that sense, which is really the consistency for designers. As Varun was mentioning, that's really only one part of it because if you're still looking at just that part, you aren't really thinking about the hand-offs, like that knowledge transfer to other teams. You have all these components but, typically, how we may have designed it or documented it in the past is you have a million hand-off documents.
04:19
You have a document for writing down all the interaction notes. You might have another document that shows the page of the designs. You have all the business requirements in another document, and trying to find the source of truth is really, really difficult.
04:32
Jennifer.: Not WordPress.
04:33
Catherine M.: Not WordPress.
04:35
Jennifer: That brings up an interesting conversation though because in my sort of realm of understanding to date, it was a website is a website is a website, as long as it enables me, as a marketing professional, to go from point A to point B, so do all of the things that I want to do. What's the difference?
04:51
Catherine M.: The difference is that it kind of systemizes it, and allows to like make it way more efficient than it would have been in the past.
05:00
Jennifer: In what ways?
05:01
Catherine M.: First of all, again, as I said, you're only designing things once, but then the hand-offs, the way that you kind of create the design system is now designers and developers, and really whoever else is on the team, everyone's speaking the same language now.
05:17
We aren't spending all this time designing a full page and then handing it over to the developers. They look at how they had coded the last thing that they did and go, "This isn't going to work at all." Like, "How are we supposed to do this translation?"
05:31
If now we're all using a single set of components, if we're looking at things in that systematic way, now we already know what's going to work and what isn't because we're kind of pulling in what we've already learned in the past and using it to kind of push forward in the future.
05:48
Jennifer: I've heard Nick, the CEO of Rangle, describe design systems as, "The supply chain of the innovation framework." Talk to me, Varun, a little bit about what that means. Like in what way do design systems enable this sort of, this frequency or this constant iteration that we're hungry for?
06:04
Varun Vachhar: We're now building products at a much larger scale than we ever were in the past, and also at a much more rapid pace than we ever were in the past. Which means there's not just one team that's building the entire product, there's multiple teams that are working in parallel.
06:18
The sort of decisions you make on one team or the learnings from that team, somehow you need to share them across all the other teams and make sure that you're not trying to do the same work over and over again.
06:27
For example, if one team solved a problem by building a dropdown, another team might solve the same problem by building a model. You're kind of working in parallel in approaching, solving the same problem in two different ways, and not really talking to each other.
06:40
What design system forces you to do is share those learnings back into a global context, and then share that across with the rest of the organization so you're duplicating the work you've done already. You're learning once, and then applying that knowledge to all of the other different parts of your organization.
06:59
Ultimately, it just allows you to go from sort of designing a button 25 different times, and every single time you build a new feature doing the same work you've done in the past, to actually trying to understand, "What is the true problem that the user has here, and how do we solve that?" Going from sort of more UI focused design work to more experience design work, and then ultimately a customer experience design work.
07:24
Jennifer: Catherine, as someone who is working directly with clients, and they're building out their design systems and you're working with them side-by-side, what do you think, or who do you think is currently doing ...
07:33
Jennifer.: Maybe outside of the people that you're working directly with, but who do you think is doing this best-in-class that makes them pioneers? People that we should be watching in terms of, "Yeah. They're definitely going after it and they're getting it right."
07:43
Catherine M.: Yeah, definitely. I think there's a lot of different companies who are doing it, and each one has a little bit different take, and there's things you can take from each of them.
07:52
Airbnb, for example, their Design Op practice is ... Probably, they're pioneering that, the way that they're looking at ... When you talk about that transfer of knowledge, how they are looking at what designers are doing, and how they're going to make sure that the rest of the organization does that, and how they transfer that to development.
08:13
If you ever have a chance to go to the Airbnb.Design, like that blog space, there's a lot of really interesting articles about Design Op. Essentially, think like Dev Ops, how to make things more efficient, but for design, like that concept.
08:27
Jennifer: That's really interesting is not only are they pioneers in the space, but they're wanting to transfer and share that knowledge, which is kind of incredible, right?
08:33
Catherine M.: Yes.
08:34
Jennifer: Yes, they're doing it, but they're also really proud of it.
08:36
Catherine M.: Yeah.
08:37
Jennifer: Which is pretty great.
08:37
Catherine M.: Which is amazing.
08:38
Jennifer: It is amazing, yeah.
08:39
Catherine M.: Another is material design, of course. Like they, when you talk about kind of being able to take something that you've learned from one spot and put it into different places. Of course, something like Google, where they have so many different products.
08:53
What the nice thing is that you have there is if you come up with a solution with one product, you can take that and put that back into material design and see it go across so many different products and kind of make that really efficient, so there's a lot to be learning there as well.
09:08
Jennifer: Varun, interested to hear from you, in what role strategy or strategic alignment plays in sort of mapping out a design system for a client?
09:17
Varun Vachhar: One of the really cool things about design systems is that all of these companies are building out their design systems, and then actually sharing that with the world. You can go and see, for example, Shopify's design system, or Airbnb's design system or GitHub's design system, and see how they approached it and how they built it.
09:35
One thing you'll notice is that they're all slightly different. There isn't sort of one recipe to building a design system. That's sort of something really important to realize here is that it's not just a component library that you're building, and you can sort of create a pattern and then just adopt that across all of the different organizations. It's you're trying to solve a business need that is particular to your organization.
09:57
That's where strategy comes in, where they help sort of surface, "What is that business need? What is the particular context that this design system is going to be built in?" Then sort of tailor your design system to that particular scenario.
10:10
The other part that they really help solve is sort of tracking whether you're building the right thing or not. Sort of coming up with a framework that allows you to measure the success of your design system. "Are we building the right thing? Are we on the track to build the right thing? Do we need to adjust and try to sort of change our approach and maybe build something different?"
10:29
That's a really important part of the design system because it's not a thing that you build once and it's done. You're going to be evolving it over time, and somehow you need to track the evolution of that design system and make sure that you are building, that it's solving the needs for your employees, for your teams that are building out the different products that you might be building.
10:48
Jennifer: You're working with product owners at these different client organizations. Is it easy or fundamentally challenging to get people to align on that? You've got marketing and brand, and you've got all of these stakeholders. Fundamentally easy to design the concept or to explain the concept of a design system and how it will align them? Or does that require some clarity as well?
11:11
Catherine M.: I don't think it happens overnight. It's one of those things that the different parties involved need to start seeing the benefit. Maybe you start somewhere, you start somewhere small. Especially if you have like multiple brands. Maybe you find one brand and you start kind of building out a design system with a few different components.
11:31
You take a couple of key flows, you take a couple like high value parts of the experience where you know you're kind of doing the same thing over and over again. You turn that into a design system and watch that go from, all the way from the design and hand it kind of through the full development process.
11:48
Jennifer: That's interesting in the sense that it's not, "Take my monolith and completely rebuild it," and I sort of sit and watch it happen, but it's, "Take a small portion of your business and develop a micro design system for that." Who knew that was possible?
12:00
Catherine M.: Yeah, I mean that way you're not kind of trying to boil the ocean overnight. You're trying to do something small, get feedback, see how it's going and, hopefully, gain momentum over, like as you go.
12:11
Because once you've design a few components, the next page or the next flow or the next thing you start looking at, hopefully, you already have some of those components built, and you already kind of have that system in place, so the next thing becomes a little bit easier.
12:23
Jennifer: Momentum, slash, buy-in.
12:25
Catherine M.: Yes. Momentum, slash, buy-in. Of course, that too, the components won't be done overnight. You will have to go back and revisit the components. I think one of the big dangers is to think of a design system as a project rather than kind of a product or a program. Like this is something that's going to continue and iterate as we go on.
12:45
Then, one of the biggest successes I see is if one brand or one team's starting to use a design system and then somebody else goes, "Hey, how can I get involved in that?" Because they start seeing the value of, "Well, if you've already done all this thinking and you've packaged it up in a way that I can start using it as well, why would I redo this work?"
13:07
Hopefully, by like slowly pressing outwards, then other people will start buying-in. That's when governance really becomes a big part of it, because you need to make sure that when there's more people involved and they have new things they want to contribute, how does that all feed back into the system?
13:23
Jennifer: I think, and Varun, I'll get you to talk about this a little bit because I think it's an overlooked but pretty important component of a design system, to me, is that idea of governance. It's the idea that, "This is our look and feel, and this is the tone," and the ability to enable team members to be a part of that process, while still keeping that look and feel. That's a pretty incredible gift that a design system could give.
13:46
Varun Vachhar: Yeah, absolutely. Catherine brought up a really good point, that you kind of need to start small because you're going to be touching every part of your organization. You're going to be touching how design works, how developers work. How do content creators create pages with that design system?
14:03
Really, it touches all of the parts of your organization, and so you kind of need to start small to understand, "What is the process that's going to work in your organization? How do you introduce that governance model? How are you going to ensure that the brand that is true to your product is applied consistently across all of those silos?" Making sure that the ultimate experience that we deliver it to the user satisfies those guidelines.
14:27
It's really important to document that governance model, and make sure that you've actually thought it through and tried out in smaller experiments first, before sort of expanding it out to all of the teams in the entire organization.
14:41
Jennifer: Yeah. It's kind of an amazing concept really, the proof of concept in motion and while you're actually doing work. Like, "Let's not make something up. Let's take a piece of your business and do a POC with you." I think that's kind of an interesting perspective.
14:53
Begs the question, how has the role of designers and developers changing as a result of the adoption of design systems?
15:00
Catherine M.: Yeah, definitely, definitely changes. I think it changes almost in two very different ways. If you're someone creating the components, I think it's forcing designers to think way more technically than they had in the past. Like you're no longer kind of just thinking about how users are going to interact with these things.
15:20
You have to double check that everything that you're creating, it fits in with this system. Every decision that you make in font sizes, in spacing, in really anything you can think of has impacts across the whole system, and you have to make sure you're kind of thinking about how that cascades.
15:35
It does take a lot of diligence and a lot of discipline to do it, but it's really powerful kind of once you've created those components. Because then you go to the flip side of people who use the components, and no longer ... I think Varun was talking about this. The fact that you're no longer thinking about buttons, you're no longer thinking about UI choices, you're thinking about experience choices.
15:56
I actually was working with a client who was doing a design system, and you kind of look at the ... It was an automotive client, and they were looking to release a brand new car. They were kind of doing a bunch of pre-launch pages for the new car.
16:14
If you had looked, kind of what they would have done prior to the design system, they would have created a page, there would have been a counter on it. That page would have been designed, it would've gone through development. At the end that page would be live and it would do the trick. Given the fact that we now had all these components, you could kind of change that mindset to "Okay, what page can we build?" To that mindset's now, "How do we build anticipation?"
16:38
They were able to build a bunch of different pages with the components that were already built, so day one, it's really, really vague. The next day, there's a little bit more information. You could kind of amp it up and focus way more on the story and on the content, rather than creating just a page and thinking about those UI nuances.
16:55
Jennifer: A true customer experience, at the end of the day.
16:59
Catherine M.: Yes, exactly.
16:59
Jennifer: That's where I get excited is, how do we take the mindset away from like the review process and the, "It has to go through 30 people"? And more go to, "How's this going to land? Show me the measurement right away." Right?
17:11
Catherine M.: Yeah.
17:12
Jennifer: It's like that old adage, "Show me the money." Right?
17:15
Catherine M.: Yeah.
17:15
Jennifer: It is that. It's the ability to put something out there real quick, and hear back. I mean it's, yeah.
17:20
Catherine M.: Exactly. That supply chain kind of mentality. You can kind of like put it out really quickly. If it's not working, change it, tweak it. You have those tools in your toolkit, you have those Lego blocks.
17:29
Jennifer: Yeah. Is it as simple as that? Am I oversimplifying that, Varun?
17:32
Varun Vachhar: I mean, there are a bit of a challenge, some challenges in building out the design system, but I find that it really does empower the teams that are consuming the design system. Because you don't have to go through a designer to build out every little part of your application.
17:47
You have a lot of the building blocks ready for you. Those blocks have your design systems baked into them, so it empowers product teams to actually put out features without having to go through a full design approval process.
18:01
On the other hand, I find that it also reduces the need for everyone on the team to have a similar level of skillset to build out UI. Because you have a team that's sort of dedicated to building out the design system, you can sort of leverage their expertise in building out really, really polished UIs that are accessible.
18:25
Then, the rest of the team doesn't necessarily need to have the same level of expertise. Because a lot of that heavy lifting has been done for them initially, they can leverage that expertise through the design system, and it makes it a little bit easier for them to actually build out the feature or the product that they might be building out.
18:46
This does require a lot of constant communication, so there needs to be a lot of communication between the end-users of the design system, the teams that are going to be using it and the team that is building it.
18:56
There are different approaches to it. There is sort of a centralized model, where it's just one team managing it. There's also other models. Sort of like a federated model, where there isn't really one team managing it, but it's all of the team's responsibilities to sort of contribute back to the design system.
19:10
As long as there is some kind of communication, you are talking to another person, I feel like that alleviates a lot of the issues.
19:16
Jennifer: Does it matter who owns it in an organization? Does it matter? Or does it just fundamentally matter that everybody's aligned and on how it will enable or facilitate that process of getting to market quick?
19:27
Varun Vachhar: I think Catherine mentioned this earlier. One of the most important learnings for us is that you really do need to treat the design system as a product or a program. Treat it like any other thing that you might be building out. Know your users, do research. Go talk to them. Try to understand, "What are their problems?" Then build something that actually solves those problems. Not just build a design system in isolation and then release it out to the rest of the organization.
19:54
You actually do need to take a similar design thinking mindset as you would take to building out any other product to building a design system.
20:01
Jennifer: Design systems are the way that they're built in and of itself. Do they force the collection of the right data at the right data points? You're saying to iterate and get better over time. Do design systems force that in the sense that it's built right into it?
20:16
Catherine M.: What exactly do you mean by that?
20:18
Jennifer.: Like in the way that the components are built, as an example. Are you building in the measurement data points? Like the way that a customer engages with something or the way that they're using a particular feature, as an example. Does it force that issue, like for you to think ahead of time about how that will be measured?
20:34
Catherine M.: Yeah, I think if we do it right, to a certain extent, there will be those. Like accessibility is a really good example of building that right into the component. If you're kind of talking from the analytics approach, I'd probably defer to Varun a little bit from the technical standpoint.
20:51
Jennifer: The accessibility piece is actually quite important.
20:54
Catherine M.: Yes, yes. Definitely. It is something that's very much overlooked because it's something that's like sometimes can be seen as a larger investment upfront, but it's something that ... It really shouldn't be something that you're even considering whether you should do it or not.
21:09
By putting it into the components themselves, it again, that heavy lifting is done upfront. Through that, and the right documentation, and the right breakdown of the components. Kind of breaking down components in the correct way is an art, and figuring out what should be componentized and what's not, all those considerations, if we do it right, help set up the people who are using it for success.
21:36
Varun Vachhar: Yeah, exactly. Just like having a design system is not going to make your product incredibly accessible, it does help you get there much faster. Because a lot of the heavy work, heavy lifting has been done initially, but you still have to sort of make the ultimate investment in making sure the final experience is accessible to you.
21:55
Similarly for analytics, if the components are sort of broken down in the right hierarchy, you're not going to embed the analytics within the components that are in the design system, but it helps you break down the final experience at the right level, so it gives you a natural place to hook in those sort of analytic hooks to measure what's happening on a page.
22:19
Instead of treating the entire page as a monolith, and then trying to figure out, "What is happening here and what do I need to measure?" you're sort of thinking about the experience from those sort of sub-components, and building it up, and composing out the ultimate, final experience that the user interacts with, so you're much more aware of, "What is going on, and what are the parts that I need to measure?"
22:39
Jennifer: Which is pretty incredible, because it speaks to that idea of putting something out there. Just getting measurement right away, the idea that this would enable that process is pretty exciting for ... Well, as someone who has worked in retail for a long time, for me, for sure.
22:51
It is the idea that you could take a piece of the business, like a brand new product or a feature or a process and throw it out to the world and, "Hey, what do you think, guys?" In the most meaningful way. It's kind of incredible.
23:02
All right, so I'm going to ask each of you a one piece of advice or key information you want to ensure that people know about design systems, or the role that design systems can play and will play in a digital transformation journey. Catherine, why don't we start with you?
23:16
Catherine M.: I think the big thing is, is it's taking away the reinvention of the wheel, so you can build something for one brand or for one locale and make sure that works. Build and test it, build it and test it.
23:36
Then once, again, as long as you've had enough foresight to understand what locales you're using, and that way the global impact that you can kind of have across many different places then is really, really quick.
23:51
Jennifer: Awesome.
23:52
Varun Vachhar: Something along the same lines. I find that with design systems, you just end up focusing on solving the real problems, as opposed to doing the same work over and over again.
24:01
That's, I think, is what helps sort of the most successful products, ultimately win out. Because they're trying to solve the problem that the user has, instead of trying to build another login form for the 50th time for whatever reason. I think that's where design systems are a fantastic tool for getting to that point.
24:20
Jennifer: It's also that gorgeous white space where, in that process of discovery with customers, you discover those unique, beautiful little white spaces that nobody owns right now. It's like, "Wow. All customers are doing this in this way with this product. Nobody's owning that. We should," which is kind of exciting. That is about that innovation framework, which I absolutely love. Right?
24:39
Catherine M.: Yeah, definitely. It helps people kind of rally around the same problem too. Again, having this centralized source of truth in that one place and whatever tools you are using.
24:50
If you have that right setup and you have that right process and that right structure, now so much more of your time can be put towards kind of thinking of those sorts of problems. Versus being like, "Oh, can you send me that document? This is the latest version of it. Oh, what did you mean about this design?" Like that's all out of the picture. Of course, there's still communication but, hopefully, it's a much clearer communication, and a centralized communication.
25:17
Jennifer: Thank you so much for joining us today, guys. I really appreciate it. Don't forget to subscribe to ensure you are notified about all future episodes. Thanks so much to our guests, Varun and Catherine. It has been incredibly insightful to hear from you folks working on the front lines in this new frontier, which is exactly what it is.
25:33
We hope you got some great insights today and we would love to hear back from you, so be sure to send us your comments and feedback. Thanks so much for listening and have a great day.
Other Episodes in This Season
Episode 2
What is a Design System?
Episode 3 • Now Playing
Episode 4
Episode 5