Author: Jerry Cao

Based in Virginia, Forum One is a digital design agency specializing in public sector projects.

We sat down with Courtney Clark (Managing Director of UX) and Amy Vainieri (Senior Designer) to learn more about their “design systems first” approach to tackling large redesign projects. Watch the full video or read the transcript below!

To know more about the benefits and processes of design systems, download the free e-book Why Build a Design System?

Jerry: It’d be great to start and get an idea from both of you of how you ended up working on design systems at Forum One. And I guess we could start with Courtney, and then we’ll move to Amy.

Courtney: Great. Hi, I’m Courtney Clark. I’m the managing director of user experience at Forum One. And this all started a couple years ago when we were starting on the Peace Corps project. Peace Corps had gone through a rebranding but needed to extend their new brand online. So, as we were starting the project, Amy was actually the one who was like, “I think we need a design system.”

Amy: I’m Amy Vainieri, the senior designer at Taoti Creative. Courtney and I used to work together at Forum One, where we worked on the Peace Corps project. It was a matter of looking at the scope and breadth of the Peace Corps project, which is just enormous. Knowing that we’re really passionate about the site, and knowing that we wanted to get the best site possible. And the only way to do that was to use a design system to build the pages because there were so many different kinds of pages that we wanted to make for them. So that’s really where it came from. We just started working together at the wireframe stage and then at the design stage to come up with reusable components that we kind of building throughout the whole site. So that kind of happened by accident, but it turned out to be a really good thing.

Jerry: And how long did that whole process take for you guys to build out the design system for the Peace Corps project?

Courtney: The project total was about eight or nine months long, so we had to be … That was the other thing, is we knew that we had to be very efficient with our time because we had a very hard launch date. They were celebrating a … Now I’m forgetting. Anniversary. I think it was a 50th anniversary, so we needed to be really efficient with our time.

So, at the beginning, after discovery, we really dug into layouts and the design system. And then, Amy do you remember how much time we spent on that?

Amy: Yeah, it was probably about … It was either mid to late January through the end of March, so is that like eight to nine weeks, total.

Jerry: For that project in particular, what would you say were some of the challenges you faced along the way as you built out that design system?

Amy: Well, I think that the part that was kind of just an accident, neither of us or anybody on the project had ever used a design system before. So learning how that works and learning the benefits, there was a little bit of growing pain, so we’d have to go back and redesign something because we hadn’t accommodated for it, or something like that. So that was the main challenge and just the breadth of the project. It was really big.

Courtney: Yeah. I think what we had going for us is that historically our front end developers have used a tool called Pattern Lab, which allows them to start front end development before the back end is built. So they have already when we’re reviewing work, they already are thinking in a system mindset before we get started, so it was really natural that we were front loading that even more, structuring it. But there was … I think one of the challenges was we need to start with a bang with the design and get people to fall in love with it, and people don’t necessarily fall in love with basics, or just the single elements. So Amy worked really rapidly to show a full page design, and the whole time we’re planning backwards a little and saying, “Okay, but what are these pieces? How will they be reused? How can we fit the together in different ways on other pages?”

So it was very rapid, but it worked out. It worked really well.

Jerry: Yeah, it’s interesting that you mentioned getting people to fall in love with the idea of this reusable design system is a little challenging. Did you find that selling the design to the client was challenging, or were they pretty on board with the idea?

Amy: So they didn’t actually know about it at first. We didn’t specifically … Like I said we didn’t start out with the goal of doing a design system, so it wasn’t something that we kind of took the client along with us as we went until a few weeks into the project maybe, so it was a matter of kind of explaining to them in simple terms like, “You’ve seen this piece before, you saw it on X, Y, Z page, so we’re just reusing it here.” And then eventually they kind of … We introduced them to the system as a whole. We never showed them the system just because it wasn’t really something that they needed to see. But, there wasn’t a lot of selling to it. They really got it right away. They were great clients, and Courtney has fun stories about them.

Courtney: Yeah. I think part of it going into it … So their old site and their brand hadn’t been refreshed in a while and it wasn’t just one site they had many sites that they were managing. So they were really interested in consistency, especially with the rollout of the new logo and the new look and feel to maintain the brand it needed to be consistent across all the properties. And the design system speaks directly to that need, so that worked really well. And I think to Amy’s point we wanted them to fall in love with the initial look and feel so we showed page designs really quickly, and then there was a slow sort of education process about these are the elements we’re going to reuse these and here is the benefit of it.

I use the analogy of Legos a lot of times like we’re going to have these blocks but we can reassemble them in many different ways. But we needed them to see a finished piece before we could start pointing out the different Legos.

Jerry: Right, so it’s interesting that this started as amongst a sort of underground, like internal tool that you guys build outright just to help you guys along the process and then you sort of brought the client into it and explained the benefits of using this. Now at the end of the project did you then hand over this design system to the client as well as just sort of kind of an extra thing that you guys had built, that maybe they could further implement in the future in their organization.

Courtney: It’s still alive, we’re still doing work with them. So the first launch is in June 2016, and we continue to work the Peace Corps to refine and build out new pieces they’ve updated same thing. So we’re still partners in managing and updating that design system, and that’s also been a learning experience as well. ‘Cause as new team members come on or leave we do have this central piece that everyone can use the same language around and reuse. But it does lead to some interesting challenges about how it evolves and grows over time to meet new needs. ‘Cause that was a year ago, almost two years ago.

Amy: We did end up giving the system to some third-party vendors. There were a couple pieces of the Peace Corps website that we weren’t going to touch and having that available to kind of give to them. It’s like, this is what you need to use to make your site consistent with the rest of what we’ve been working on, that was really valuable.

Jerry: Gotcha, so it’s interesting then that you have sort of become the stewards of this design system over time. What started as sort of this internal project has since I imagine grown quite a bit in scope and also in just the amount of involvement and also just governance from everybody involved.  Is this design system something the Peace Corp owns and drives along or is it something more that you guys manage and involve them as needed.

Courtney: Well, we’re certainly partners in the work. It’s their website, and we’re helping them maintain it and build it. They do a lot of work on it, of course, so we are very passionate about the organization and the project from the start. Our CEO is a former Peace Corp volunteer, the project manager on the project is a former Peace Corp volunteer, so there’s a lot of passion around it to start with. But we maintain it together ultimately the Peace Corp owns it, it’s their brand, it’s their look and feel, but when it comes to making updates or providing guidance around how we extend it we often suggest the direction hat we want to go in then we have a discussion about it to make sure it makes sense because ultimately it’s theirs.

Jerry: Right. And is there a dedicated team at Forum One that just works on the design system or is it an effort that is sort of spread out across the project. the day to day project team members?

Courtney: Yeah, that’s an interesting question ’cause I was watching the interview you did with, what’s his name from Intuit?

Jerry: Joe Preston, yeah.

Courtney: Yeah, yeah so they have like a team who used that design system, and that’s what they do. Because we’re an agency we have project teams, so we have a user experience person, creative design person, a front-end person, you know the mix of … So whoever is on that project team is a maintainer but also does all the other work related to the project. But there’s not like a dedicated owner or a group of owners that takes care of it and grows and feeds it; it’s the project team who does that.

Jerry: Gotcha, and that sort of make sense in an agency environment right because there are a lot of projects and also clients where it probably makes sense to have some of that responsibility shared between people, and you may not just have the resources necessarily to dedicate to just maintaining that design system like a large organization like Intuit might be able to do.

Courtney: Yeah, that’s right.

Jerry: And I’m curious then since that was a year ago. Since then has building design systems been a core project that you’ll work on with clients at Forum One?

Courtney: Yeah, I can speak to … Amy, did you want to?

Amy: Well yeah, I was just going to say there’s something that … Knowing how well it worked on the Peace Corps and what we learned from that project, it’s definitely something that I try to use in the project since then at Forum One and at Taoiti. It’s just an easier way to build things, in my opinion; it’s a more systematic way of scaling things. So it’s definitely something I’ve used since at both companies.

Courtney: Yeah, and I say that more than anything because of the success and because a lot of … It’s an industry trend right now and for good reason. And so we’ve certainly incorporated it into our processes in other projects. And they all take different forms; not everybody is starting with a fresh new brand or logo. We do work with non-profits and foundations, and a lot of them have some legacy work, but they can update smaller pieces along the way. So the other thing that we’ve been doings is, even more slowly introducing a design system and it has to jive with the legacy look and feel and structure. And then introduce a new look and feel and we’re doing that right now with the MacArthur Foundation, and so that’s like an added layer of challenge to this because you need to have that consistency, but over time it will all switch over.

Jerry: Right and the way that you work with clients is that design system conversation something that you have immediately in the beginning of a project to have them understand that this is a foundational component to whatever work they’re asking for or does that happen as like a one-off conversation.

Amy: I recall a work project that Courtney and I worked on after the Peace Corps project it actually became a really useful tool for starting one of those redesign conversation with a particular client we ended up doing a design audit. Basically took all the different button styles and all the different textiles and showed them what was inconsistent about their site and how we used a design system on other projects to mitigate that. Which that was a really useful tool to start those conversations. They ended up going for it, which was great, but it was a little bit of work to get them to agree, but they went with it.

Courtney: Yeah, and that audit was vital. Amy did the audit and as you can imagine it’s like just a smattering of all the different menus and like she said buttons. And once people see that they start to get it a little bit more they’re like, “Oh yeah, how would somebody know how to move through when things are so inconsistent here.” So the efficiency is another big selling point as well because once the system is created … Actually, on Peace Corps, Amy was able to put together pages in minutes because all the building blocks were there. So once we talk about those pieces and they can see a couple of really beautiful examples. And there are many examples in the product space but seeing them in the non-profit space and the foundation space; people start to get excited about it then.

Jerry: Right, and I think that’s what so interesting about the work that you do with design systems at Forum One is when you look at a lot of the existing design systems, they are for very high-profile enterprises, like IBM, Microsoft just recently released a fluent design system, Sales Force, of course, is known for Lightning. But not a lot of people may know that these non-profit organizations also do have internal design systems as well, and that’s actually really cool that that’s possible with your guys help. And I’m also curious when you work on a design system with different clients is it pretty much a project that Forum One can create all on their own, or does it require a bit collaboration between their developers and their product managers as well?

Courtney: Great question, it varies with every group. ‘Cause we’re often working, sometimes we’re working with their IT departments, sometimes we’re working with marketing or communications. So in order to be good partners you have to be a little bit fluid to figure out who is going to own it and how you can get buy-in when you’re internal within that organization, you can lay that out you sort of know the people to talk to, but we’re often coming and have to figure out that landscape as well. So that’s the first part of our goal is just to figure out the landscape and the stakeholders and who might be interested in it so that it can live on ’cause eventually what we’re creating will launch and we hope to continue working with them but ultimately, like I said we hand it off, and it becomes their design system.

Jerry: When you’re working on a design system with these clients have you found that the technology is a constraint you have to work within or are you open to suggesting changes to, let’s say for instance the CSS framework that they may be using on their backend? Is there some freedom in technology that is provided to the team when you’re working on a design system?

Amy: It kind of depends on the project, both Forum One and Taoiti work primarily with Drupal so there is only so much we can do, but we do our best to work within the constraints of whatever CMS we’re working in. Peace Corps was built on Django. I felt like we had a little bit more freedom with that one than we have with other projects. But that may have just been me being excited about the project. But it really depends on the client in what we’re working with and how we’re building their project.

Courtney: Yeah, I say a really common project for us is a full redesign. Like we can come in and work in a more phased approach, but it’s really common that groups will come to us and say, “We’re ready to overhaul it.” And when that happens we’re not editing existing CSS. We’re upgrading the CMS they’re on anyway, so more often than not we are able to start from scratch which is kind of a blessing. But that is to say; I’m on a project right now where we’re making edits within an existing ecosystem. What that means though is that we just have to be very close with the front end and backend developers so we know how far we can push things. Or where there may be challenges ahead so it takes a really tight project team and a lot of really honest review sessions to make sure that what we’re designing can actually be implemented.

Jerry: Have you found that working or rather creating that design system as a foundation for the project does make it easier to collaborate and communicate between the designers and the developers?

Courtney: Absolutely.

Amy: Yeah, so much we have. The developers on the Peace Corps project, in particular, were just thrilled because they’re already thinking that way. So they’re using Pattern Lab, they think in a systematic way on they’re going to build the cages, so when we started thinking that way it just makes their job 10 times easier. And the fact that all of us were using the same language to describe things made it to easier for project managers and for the sales folks to kind of be on our level and all talk the same language and communicate a lot better. It’s great.

Jerry: And Courtney, I think what’s interesting is you mentioned that a lot of times you will be brought in to work on full redesigns for clients, and it’s actually very interesting that this design systems process has become something that is part of the redesign process. That instead of the alternative method where you just go to a client, and you would just redesign the site and hand it off when you’re done now you’re actually giving them not just the final representation in that site, but also the sort of derivative components that they can then use forever, and they have something powerful that they can evolve and make future redesigns easier as well. That’s actually really cool to see that the conversation starts with the client saying, “Oh I just want my site redesigned.” But it becomes something a lot more meaningful once you get involved and start building that design system as the basis for that project.

Courtney: That’s right, and we talk a lot about how to design stuff that can scale. Because a lot of groups that we work with whether they’re grant making foundations, or they’re non-profits, who are running some real different programs what they’re doing changes year to year. So their digital needs can vary greatly. Part of our UX and design practice is to ensure that we’re creating solutions that can scale up and down and the design system is a key piece of that. The point is that we talk a lot about scaling, design systems work really great for that. And it’s more bang for your buck. Where were already doing that thinking up front then it can live on and it can even extend ideally into not just the website, the social media presence, the marketing materials, a lot of stuff that we’re figuring out can be repurposed elsewhere.

Jerry: Again, what seems so powerful about that is once you have that design system in place Forum One isn’t so much as a vendor at that point as more of like a long term partner because you’ve created … It’s not just a redesign, you’ve created infrastructure for a client and when you have that. That, I imagine, from a business standpoint creates a lot more opportunities for future projects down the line instead of being treated as just this sort of one off agency in the corner that they pass off projects to.

Courtney: Yeah, that’s the goal. We’re in it to be good long term partners and their web presence doesn’t end when the project ends, their digital presence doesn’t end when we launch the website June of 2016. It lives on, and then there is a team who has to maintain it and make sure it’s still functioning properly and meeting the goals of the organization. So yeah, we’re in it to ensure that they have a really solid framework to continue on with.

Jerry: I’m curious for both of you, do you have a background in development? Because as I’ve spoken to a lot of folks who work on design systems, they seem to be the sort of hybrid designer/developer profile, where they kind of live at that intersection and I’m wondering if that is true for both your experiences.

Amy: I think Courtney and I are both … Courtney has a background in graphic design, and I’m starting to explore the UX side of things. So I think we’re both more of the UX/designer hybrid than the development side of course I’m speaking for Courtney, but I think that’s the case with you as well.

Courtney: It’s really interesting that you point that out because where Amy and I are similar is that we are, we’re organizers and what I love about user experience and information architecture is figuring out how to organize large bodies of information, and that takes systemic thinking like a library science person right. And I think that that sort of systems thinking lends itself to design system development as well. But no, no development passion.

Jerry: That’s really interesting, you mentioned that having a sort of information architecture approach to a design system helps designers who don’t have a development background grasps the concepts better and I think that’s a great point because on design systems teams from what I see at least on the pure, in-house corporate side most of the folks here have some sort of development background but it’s great to see that, that doesn’t have to bee the case. You don’t have to be a designer who’s also a developer in order to understand how to create and govern a design system and obviously both of you are proof of that with the multiple projects that you’ve worked on at Forum One.

Courtney: I think thought that you do have to be … When you don’t have that deep development understanding or skillset, you do have to be a really good collaborator, and you have to be willing to work through a solution with your front-end developer or whoever it is that actually will implement your work. And I like to think that Amy and I are pretty good at that, working with our teammates to … Instead of just throwing it over the wall, that we’re reviewing, we’re brainstorming together to ensure … Cause we care, we don’t just design for the sake of design we want our work to actually be implemented, and in order for that to happen, you have to be a good team member and figure it out together.

Amy: And be able to understand what can be done and speak the right language so you guys can collaborate in a useful way.

Jerry: Yeah that’s actually a really interesting point, you mentioned that strong collaboration with the developer can help to overcome some maybe personal understanding of how everything works technically. Is there certain processes that you have found useful at Forum One or even at your current company Amy, for better collaboration between designers and developers?

Amy: It’s just a matter of making time for it. Developers in, I think, every agency I ever worked in the most overworked, overbooked people that exist. So it’s a matter of finding the time and really making a point to meet with your developers and talk to them. ‘Cause so many ideas that have gone into sites that I designed have come from the developers ’cause they want to do cool stuff too. And I think one of the tings that was really successful on the Peace Corps project is that we had a set time every day at noon so we could catch Courtney in L.A., that we would just have an hour open for anybody to join in, we called them Power Jams, just to talk about issues [inaudible 00:26:49] we’d be talking about something and talk to developers and we’d make sure they were invited and attended that day. So having that open space for collaboration on the calendar was invaluable.

Courtney: And we actually … This is our plug for UX pen ’cause we used UX pen to sketch listen, and so those meetings started off with Amy and I sketching, laying out the blocks of the pages, but to Amy’s point the team was invited, they could listen in, they could participate and that sort of transitioned from to UX to design meetings to development meetings to reviews and that was a place because we met every day at the same time, it was a place for the developers to join as they wanted to and also could listen in while they were doing other work for example or once they were deep into the work they knew that they could reach us at that time to answer questions, to troubleshoot, to figure out different solutions if we needed to and I think that was really vital to our success on the project.

Jerry: Yeah it’s interesting of course you guys use UX pen. I would be curious to understand how have you found the platform helpful for you in terms of, not just collaboration, but overall design workflow? Has your process changed in anyway using UX pen as a collaborative design platform?

Courtney: Man, I’m going to have to think back to days of OmniGraffle. Well I mean the biggest difference is that when there are multiple Users, designers on the project we can all get into one project and edit things at the same time and not every tool allows that, so that’s a huge benefit and was vital to this. However, I would love to Amy’s thoughts here because initially once we’re getting … My goal is to do the wireframes to a high enough fidelity that Amy could take it and run with it, and she’s not doing that in UX pen. But Amy what was your experience like?

Amy: I would you echo exactly what you said I think the list of valuable things in UX for me was the ability to watch Courtney and the other UX designers that we had on the project work in real-time so that could watch them work and be able to help them see common things as they were working on it in real-time in the platform we used, really cool.

Jerry: And I see how that all fits together now, because your team has multiple people in different parts of the country and to be able to work on these fairly complex projects especially if they involve something large scale like a design system requires a bit of collaboration and having that almost like common sandbox environment for everybody to come together in, I imagine probably helped to reduce some of the emails and otherwise disjointed conversations that may be happening. So that’s actually really cool to hear. I’m curious since both of you have worked on quite a few design systems projects now, is there a common set of metrics or evaluation criteria that you look at to determine whether a design system you worked on has been successful for the client?

Amy: That’s a really good question, I don’t know that any of the systems I’ve worked on have lived long enough to comment fully on it, but maybe that’s good thing that it hasn’t broken down yet. I imagine that a good metric would be if the client is coming back to you and asking for more things that you didn’t accommodate for, that would certainly be something that I would look for as a missing piece we have may have not quite met the mark in. That’s a really good question though; I don’t know have you seen anything Courtney?

Courtney: Well it’s not necessarily a metric, it’s anecdotal but there have been points on projects where we’ve spent a lot of time crafting the design system, maybe educating the client about what it is and the benefits and we get to review down the line and this really happened where we were like, “Hey, we have designs ready for you to review could you take a look?” And the client said, “Oh yeah if it matches the system we’re totally good to go.” So they mentioned it, they approved it without looking because they bought into the system that we created and it became a little bit more … They knew what to expect, and that was part of their goals. So I think again is anecdotal but that’s like the dream for somebody not to go through thousands of iterations and say like, “I trust it, I know what to expect, the system is great, we’re good to go.”

Jerry: That actually touches on a common theme that in the interviews I’ve done to date so far has been pretty prominent which is just the fact that it’s like a codified standard for design and development best practices so people sort of know this is the source of truth, if it matches what is here then we don’t really have to have all these conversations about, “Does the page look or feel right.” And then on the technical side, some of the in-house teams what they’ve used to measure the success as well is looking at deployment times from when a first iteration of a design has been created versus when it goes live. How much time did it take with the design system in place versus before? And I’m trying to remember who it was, I forget of the people I’ve spoken with so far, but they mentioned that sometimes it can be quite drastic like going from what used to take weeks and now it takes a couple of days because they can, like you said, they can skip all those iterations and all those conversations.

Courtney: Yeah and that’s one of the things when we’re first introducing the concept to folks who haven’t heard of it or worked with it before is talking about the investment because if we’re designing custom things all the way up, the investment just increases it never levels off. But with the design system there’s an initial surge of design activity but then it mellows out a little bit because of the reuse and sort of hitting that magical point where you can start to reuse those elements and yeah you are gaining efficiencies in time and resources.

Amy: I feel like it’s one of those things that you a website is designed really well when you don’t notice how it’s designed, I feel like it’s kind of the same with the design system. You don’t know how well it’s working because you’re probably not hearing a lot of issues it’s just working ’cause it’s magical and wonderful and pages are made really easily. I feel like there is a little bit of a comparison there if it’s working well it’s just a smooth train.

Jerry: Courtney you mentioned, this is interesting, that there is sort of an initial peak of activity in creating the design system where after you get over it that it sort of tapers down a little due to the reuse. In both of your experiences have you found that there is a certain, perhaps company size at which it makes sense to create a design system or do you find that it’s something that could be useful for a company regardless of the size of their team.

Amy: I could see it being useful for a team and being a good tool as well. ‘Cause I worked in-house in a non-profit several years ago and it’s hard to control the brand but if you have a system in place you have certain parameters that you have to stay within it would become a really useful tool for in-house teams to be able to defend their decision and justify their decisions to some internal stakeholders. So from that perspective, I think it would be useful to just about any size company.

Courtney: One of the things that we talk about when we talk design systems is if you’re on a project where there is a lot of hand off between team members or a lot of different folks are jumping in on it, if your site is going to grow or evolve rapidly over time, or if you just have crazy wild styles across all of your visual platforms those are three big indicators that you probably could benefit from a design system. So I don’t know if it has to do with the size of the organization, but maybe the size of the digital presence or how your team works in the handoff between your teams. Certainly, a little baby site that’s just twenty pages, of course, it would design system, but it’s really those products that are thousands of screens or thousands of pages where it’s a no-brainer to utilize a design system from the get go.

Jerry: You mentioned the scale of some of these projects you’ve worked on, what would say is the like the most complex design systems project that both of you have worked on to date? Would it be that Peace Corps project or is there something else since then that has become even more intricate?

Amy: It’s definitely Peace Corps for me, that was certainly the biggest breadth of project I had worked on ever.

Courtney: Yeah, I think one that’s live right now is the Peace Corps. I am working on one right now that will launch later this fall, that is a site that has over a hundred thousand pages, and we’re building a design system for that, but that’s not done yet. So talk to me in November.

Jerry: And for that Peace Corps project, was it difficult to really most just the pure scope of the content, the fact that there were so many pages or was there other process complexities that made it more challenging.

Amy: I think it was a little bit of both just from the pure page perspective that was the most custom design pages that I’ve ever seen designed on a website. We did 29 different templates that we worked with so that as a complexity was just beyond and absolutely benefited from the design system. But it was also being a learning curve as well that makes it kind of special.

Courtney: I would add that the size of the site had a major influence on our process decision but also as I mentioned they had just rebranded and so creating that consistency across platforms they didn’t have was a huge part of the redesign. So a design system helped with that and then third like Amy said a design system starts to put up some gates around like, “This is what we’re going to do.” And when you have a lot of stakeholders, Peace Corps has several programs, they have several stakeholders that were involved, and when you have a lot of people you have to set up some like, “Here’s how we’re going to operate, here’s sort of the bounds of what we’re working within.” And a design system hopefully sets up those bounds to create the consistency.

Jerry: What’s interesting here is also that you mentioned the design system kind of sets boundaries on the scope of the project. Have you found that once you’ve started working on a design system that you’ve had to revisit what it is that you guys are actually going to be doing? So you’d have to go back to the client and tell them, “Oh the scope has sort of changed because as we started working on this, we realized either more or less work needed to be done.”

Amy: I haven’t experienced that yet.

Courtney: Yeah, I haven’t either, and I think it’s because we worked on a really big design system. We’re now talking about how we can have like, what’s the small, medium, and large size of the design system. Not everyone needs what Peace Corps has or what Intuit has or what Microsoft has right; there are smaller groups that need a more basic size. No, I haven’t experienced that yet.

Jerry: Going back to the beginning, I know both of you had mentioned that part of the process for creating the design system was doing an audit first and seeing where all the inconsistencies lay. Perhaps you could just describe your process for creating this design system in some more depth. So the first step would be, of course, doing the audit and then from there what did the process look like for, let’s say that Peace Corps project?

Amy: Well it really started with Courtney, it started with the UX process and thinking about the design from a really high-level and what sorts of components they were going to need to use on the various pages as we filled them out. So the collaboration and the design system definitely started at the wireframing stage when we started reusing stuff within those wire frames. And then it was transferred to me where I built it out piece by piece.

We’ve tried to start with the most complicated pages that had that type of those components in them so that that we could hammer out those big ones first and then they basically just sent in Photoshop files and I was dragging them into new files as I created them into each individual page and then once we were done with the page part of it, I kind of put the whole system together, the whole with all the various elements and components into it and that’s when it got handed off to a developer who essentially put that into a pattern map and built out each one of those elements individually so he could start plugging them in on the code end.

Jerry: So it sounds like part of the process really was getting the design system all set up in place first as part of the redesign project and then once you’ve had those unified design and code components you could then have this toolkit that you could then actually, formally move forward with actual redesign work itself. So you wouldn’t have to be doing so much redundant work later on.

Amy: Exactly and the Peace Corps was a little bit of a special case where it was essentially everything got scrapped. It was built the site from the ground up when we worked on a not as invasive redesign project it’s a little bit more of a balance of what’s existing, what can you find through that audit versus created creating new stuff that may not be necessary at the time. Balancing the existing design with what you would really like to see systematized and brought into the consistency.

Courtney: And the thing, there were a lot of audits going on. We did a huge content inventory and audit, we did a lot of discovery in understanding stakeholders, and our audiences, and our goals for the project. So that’s all background stuff that was happening but it totally influenced the decisions and the approach on the design system itself ’cause you have to know the content before you know the layouts that you’ll need or the elements that you’ll need. So there was a huge amount of effort put into figuring out what this thing was and the content that it would hold before we started being like, “This is what a form field look like.” But there were you know every project I think what we’re seeing and figuring out now are like, “What are the staples that every design system absolutely needs?” And then for each individual project, “What are the custom elements that we need to create or update?”. And there’s even efficiencies once creating design systems becomes part of your process hopefully because you’re seeing the trends in what you’re reusing over and over again from project to project.

Jerry: What’s nice about this process that you’ve described is your kind of front-load all of your buy-in right at the beginning. As you build this design system you already thought of a lot of the difficult problems that could cause you concern later on, like you mentioned getting an idea of how much content there is, which then from that you then know how many patterns or components are required to accommodate that content and you can have those conversations early on and by the time you have this design system built out, hopefully from that point it becomes mostly how do you mix and match those components in a way that satisfies the usability goal for the project.

Courtney: That’s the dream, that’s the dream.

Jerry: Yeah it is. Did you see that it played out close to that in the Peace Corps project or was there sort of some unexpected challenges that came up along the way?

Amy: I think for the most part it was pretty smooth, it was again those growing pains of not having done it before and not knowing where the speed bumps might be. When Courtney and I talked about design systems a couple of times at conferences, and one of the big things is the lessons you learned. There were some big ones like, make sure you understand what the final version of this system is, where the files and things like that. So there were a few bumps along the way, but overall it was a pretty, pretty smooth process.

Courtney: Yeah, and I think the nice thing if you have a design systems team the great thing is that those folks have a committee or they decide is this in or out, do we need to reuse the element or create a brand new one. And when you’re in an agency setting there is not an owner who can say yay or nay it’s a discussion, and usually people are … the discussions are good, but you need to have those guiding questions, you still need to have the rules and guiding questions to help you understand where it flexes and where it grows or where it doesn’t. We were at Triple-Con speaking a month ago, and afterward somebody asked a question about, in higher education when they have a new commencement site, and that’s like every year the team was wanting to redesign it from scratch and the question was, “How do you convince those stakeholders that it’s okay to reuse elements?” So I think that’s another challenge that sometimes teams whether you’re in an agency or in-house there is this desire for something new. So I think there’s really interesting conversations to have around how you guard the system but also where there’s flexibility, so it doesn’t feel stale.

Jerry: And in your work, working on all design systems have you had to hold those conversation with clients? For instance, have they had to come back to you and say, “Oh, it’s been a year? Why don’t we refresh things?” And then you kind of have to remind them that maybe there’s really no business reason for doing that?

Courtney: Yeah, for sure and it’s a discussion right? Because there are some … Like we talk about Lego blocks a lot, there are some sites where their design system is eight Lego block, and somewhere it’s like 40 Lego blocks. And what we’re constantly figuring out is what is the right number of elements or pieces for that group or for that client that will last them the longest. And so that’s … I don’t have a special [inaudible 00:47:18] for figuring out, how many elements you’re going to need, but it’s a discussion that you have to have early. And using examples I found is the best way to say, “How big is this thing and how much shifting is it going to need over time?” And people sort of have to predict but also if they’ve been at the organization for a while the can look back on the past couple of years and be able to say, “Oh yeah, we … ” Some of it’s predictable around what their needs are or what their desires are for the main stakeholders.

Jerry: That’s actually really, that’s really interesting. Because I can see now how in an agency environment like you mentioned those conversations can pop up more often than if you’re in-house and the design system is perhaps given a lot more hands on day to day attention by a full team, so those updates are a lot more visible. Whereas in an agency setting that may not always be the case so people may come back and come up with requests for things just because they don’t see what’s all going on all the time.

That’s the last question that I had here, this has been great learning about both of yours experiences at Forum One and elsewhere as well, and all the design systems work that you’ve done. This is particularly interesting because of the design systems approach that has been used for actual redesigns. This is a very, I think, efficient and just like a really up and coming method for tackling these large projects. It’s always cool to learn about. Thank you both Courtney and Amy for joining us here, I really enjoyed our conversation here.

Amy: Me too, my pleasure.

Courtney: Thanks for having us.

We sat down with Dan Mall of Superfriendly to explore his best practices from design systems projects with startups and corporations.

Check out the full interview recording and transcript below.

To learn more about the benefits and processes of design systems, download the free e-book Why Build a Design System?

How did you get started working on design systems? What was that progress and journey like?

 I run a consulting company and we work with all sorts of different clients from mom and pop shops to Fortune 500 so all sorts of things, and the more clients we started to work with that have been in business for a long time, they started to realize that they have a ton of digital properties that they try to manage.

When I was doing work 10 years ago, it was like, “Help us get our website off the ground.” Right? But now everyone has a website and they have more than a website, they have websites, micro-sites, and apps, and all these things and they all start to get really … There’s a lot of discrepancy with a lot of them, because a lot of them are made one by one, there’s not a lot of consistency, there’s not a lot of efficiencies, and as organizations start to look across their properties and they go, “How do we manage all hundreds of the apps that we make? And why do they all look different?” They start to realize that they need some sort of system to be able to manage and update, but also just maintain all that stuff.

And I think the idea of design systems is a thing that a lot of organizations are sort of coming to rather than it like you know no one invented that idea and then people are climbing on board. It’s more like, people are realizing it pragmatically. So I think it evolved pretty naturally.

Have you seen a certain size at which a company benefits from a design system?

 I don’t think so, ’cause I’ve seen companies, start-ups that have a handful of designers start to invest in that stuff. I’ve seen companies that have tens of thousands of employees or hundreds of thousands of employees do it. I think it’s more about how many digital properties do they manage? There are certainly a ton of companies that have many, many employees that are just starting to get into digital now and they may not need a design system. But then there’s let’s companies that are natively digital like Airbnb, they’ve made a bunch of things and are starting to realize before they get too deep into it, “Oh we actually need something to help us propel this forward.”

I don’t think that there’s any particular size that I can pinpoint, but I think it’s about how many digital properties they maintain or intend to maintain.

How do you sell the need for a design system?

 In my experience as a consultant, I rarely have to do the selling for a design system. It’s usually somebody who works at the organization that is in charge of digital or maybe a product director or something, or a web manager, or something like that really has to do a lot of the selling. Now we can help with that but it’s that person who really needs to make the case for it. So a lot of the clients that I work with, what they do is they sell things the way that anybody sells things which is you show people the pain. You show them like, “This is the pain that we’re experiencing and here is a solution that will help alleviate that pain.” And a lot of those instances it is a design system.

So one of my clients, I wrote a blog post about this, but one of my clients walked into his boss’s office with thumbnails, hundreds of thumbnails mounted on black mounting board to say, “Here are all the websites we developed this year and look how different they are and how desperate they are. Here’s how much money we wasted on that. And I know how to fix it and here’s how much money we’re gonna save if we do it the right way if we invest in it.” And so making the good case for it was really showing and visualizing the pain, like, “Here’s what it looks like to not have a design system. And let me paint the picture of what it actually looks like to have one. And we can compare those apples to apples.”

Right. That was the Seventh Day Adventist Church project, that you were talking about?

  Yeah. Exactly.

Brent Harding was the web manager there and he did a fantastic job of evangelizing that idea in the organization so that we had all the buy-in that we needed when we came in and did the work. I find the most success that we can have is ask people who come and help us consultants is when somebody internally has already done that due diligence and the level setting for everybody, the expectation setting. Like, “This is what we’re going to embark on because this is what we get out of it.”

How would you describe the benefits of a design system in 30 seconds?

  My definition is evolving and I’m not sure that there is a canonical definition but I would say that the more and more I’m thinking about the idea that design systems should help you design better and faster. Or maybe just better. I’ll just stop there. And for some organizations that means faster, some organization that means to a level of higher quality. I think it should help you design better. I don’t think, and this a thing that I previously thought, I don’t think that a design system should remove design from your organization. A lot of clients think like, “Oh, if we had a design system, we don’t need to design anymore, right? ‘Cause all the decisions would be made.” And I think that I’ve never seen that actually happen. Design systems should just help you design better. So you’re still gonna have to go through the process of design, but a design system should be a good tool in your arsenal for you to be able to design better. And eliminate some of the useless decisions that you might have to make otherwise.

What are some redundant decisions that you’ve seen a design system help eliminate?

So here’s a really oversimplified example, but what color palette should we have for this app?

Well, if you’re working in an organization that has a brand guideline and style guides and typography guidelines, that’s sort of a useless exercise]. You’re gonna explore a bunch of color palettes and then it’s gonna get shot down by someone. But if your organization already had that kind of stuff, having that codified in some way so you can implement it is easier. But for you to waste time exploring a thing that doesn’t need to be explored, I think that’s where a good design system can help out. Same thing with typography. Same thing with things that you should be able to take for granted, but if you don’t have the right tools you end up having to explore those things again and again.

Kind of reinventing the wheel.

What are some common design system mistakes?

 I’m not sure that I can pinpoint what mistakes clients make. I can tell you the mistakes that I’m making. One of the things is that I often have took for granted the fact that I know who the design system is for, I know how those people are going to use it. And the more I take that for granted, the more we work on stuff without talking to people, and the more we launch something and say, “Hey, this is gonna be good for you.” And then we find out that that’s very, very wrong. So it’s a fairly simple example, any good product design has that cycle in it where you gotta talk to your users, you gotta have both quantitative and qualitative data that supports the things that you’re making. Otherwise you’re just speculating.

A recent example of what we found was, we spent good bit of time designing a design system for an organization and then launching that thing and we get a ton of feedback from the people that it’s meant for saying, “We can’t use this. And here’s why.” And part of that’s just us not doing our proper due diligence in research and getting people in on the ground early, very early. Testing what we’ve got, validating it. Everything from what kind of coding standards are we gonna use all the way to where’s the rest of the colors that I can use? Every organization has different processes, so to assume like a good design system is there’s a canonical version of that, that’s a thing that I’m learning. There’s not. Every organization is a special snowflake and they have specific needs and specific people that use them.

So another example is that I’ve worked with organizations that the design systems are for purely developers. That’s it. It’s not for designers. And then in other organizations, a design system has to work equally well for designers and developers. And so just those two examples, those two design systems have to be drastically different from each other ’cause they need to support different use cases and different people. So I think that’s one of the things I constantly am reminded of and constantly making mistakes about of just taking for granted, like, “Oh, I know what this is for, I know what we need to do here.” And just forgetting to talk to people about it and really spending a lot of time interviewing and making sure we’re gonna build the right thing.

How does a design system for mostly developers versus one that is for a mixed audience of designers and developers differ?

  If I could sort of sum it up, and again there’s a lot of nuance in here, but just kind of generally, the design systems that I’ve worked on that were solely for developers are ones where a lot of the developers tend to say, “Give me the one line that I could drop in and everything works. Like everything’s hooked up, I don’t need to think about this. Take away some of the thinking that I’m not comfortable with and let me focus on the thing that I am comfortable with.” So if I need to build a certain component, I don’t want all the parts, just give me the one line of Javascript that I can use to plug in this component and it all works.

Vice versa, the design system for designers or one that has to work equally well for designers and developers. Sometimes those designers are thinking like, “Give me the parts and let me figure out how to wire them together. Let me figure out what the design process needs to be for this flow, or for this particular thing. I just need the kit. I just need what all the Legos are.” For lack of a better metaphor. And so some people want the Legos, some people want the thing that the legos make. And I think that those are probably the two ends of the spectrum and then certainly all the areas in between.

How would you describe your process for creating a design system, from start to finish?

 From a 1, 2, 3, 4 standpoint, 3 and 4 are almost always different for me so I’m not sure if I can codify that? But 1 and 2 tend to be constants so I can give you 1 and 2.

So 1 is, as you just said, just talking to people, just interviewing a ton, just talking to as many people as are gonna touch this. And having really a good sample size. We’ve talked to some organizations, 8 people and sometimes that’s representative enough. And then other times, like close to a hundred people and sometimes that’s representative enough. So I think it depends on the scale of the organization. 1 is just like getting the lay of the land of who’s gonna use this? How are they gonna use this? Is this person who’s very vocal, are they an exception to the rule or do they represent the median there? So I think understanding that is part 1. And spending as much time to do that as possible, I think I’m realizing more and more the value of that. So that’s part 1.

And then step number 2 is…I haven’t done a design system where we didn’t pilot it first. So what I mean by that is when a lot of people think of a design system, they generally are talking about a combination of a style guide and a component library and it’s tempted to say, “Well look, we could just build a bunch of components, we’ll build buttons and carts and tables and tabs and all that stuff.” But the way that we know that those are gonna work is through piloting and application.

So, step 2 is usually, for our work, is give us an inventory of all the apps that you use. So we walk through with people, whether on screen share or in person or we ask them to make print outs, however they can deliver that stuff, show us all the apps that you use. And just walk us through them and we’ll take screenshots and once we’ve seen 20, 50, 100 then we could start to inventory and say, “All right, of these 100 apps we just saw, or these 100 websites we just saw, all of them have some sort of left side navigation. That’s a component that maybe we should start with. All of them have a very specific kind of footer, or all of them have a special kind of dropdown.” So we’ll try to take the first 10 or 15 or 20 components that we’ve seen across 100 apps and then we’ll start to build from there. And then after the first 20, we’ll say to the people that are going to be using it, “Here’s our beta period, what do you think of these? Are these on the right track?”

And if they are, the next step after that is let’s use those things to try and build a new app, or maybe it’s rebuild one of their existing apps. Let’s try to rebuild it in the new design system and see how they work. What are we missing, what didn’t work out as well?

All of the design system projects I’ve done involve anywhere from 4 to 9 pilots of, “Kay, let’s get an inventory of this stuff. Let’s build a small component library and then let’s try to pilot building these apps with the design system and then rinse and repeat from there.”

So you start with almost a minimum viable design system in a way, right? And you test it out with the organization to make sure that, not only are the components correct but that it’s built to suit the audience. Then you can expand it.

  Absolutely. Nathan Curtis wrote a great article about the fact that a design system is a product. A lot of people see it as like, “It’s a website,” or “It’s a reference site.” Absolutely not. It is a product and you have to treat it like a product. It grows like a product, it gets used like a product. And for people to think like, “Yeah we’ll just create it once and then it’ll sit there.” They’re not realizing the value of it and they may not actually get value from it if they’re not treating it like a thing that also needs to grow in time and adapt over time.

In order for a design system to be successful, does it need a dedicated team to evolve and maintain and govern the system?

I’m split on the term dedicated.

So, I think if you mean somebody working on it full-time? I’m not sure. If you mean somebody who will pay attention to it when it needs attention, then absolutely. So I think it does need care. It needs sustenance. I think it needs people to pay attention to it when it needs attention. I think there are times that it can just kind of hang out for a little while while people are using it, but I also think that it needs to be able to respond to it. So if it’s one of those things that an organization doesn’t have any resources at all to devote to doing it, then it’s just gonna sit there.

I’ve been part of a lot of organizations that as they’re creating these design systems, they don’t have people to care for it. So most of the organizations that I’ve worked with have already had a design system at one point but it just was never cared for. It’s not like this is the first design system they’ve had, it’s sometimes the second or sometimes the fifth and with all the previous versions they’re like, “Oh well it was just one person’s pet project.” And then that person left the company and then it just sat there for a while. So I do think it needs some sort of sustenance and some sort of care to go along with it, to kind of grow. It’s like a product that doesn’t have a product team, it just sits there. And it doesn’t grow and then people get upset and frustrated because nobody supports it and they’re not getting answers to their questions.

In the same way that any good product has a support team, the design system needs a support team. Whether or not it’s full-time I think is up to it’s usage. But certainly it needs people to pay attention to it.

Is the cadence of maintaining a design system similar to maintaining an external product?

I would imagine that somebody that works at some place like Salesforce that had that Lightning Design System would have maybe daily or weekly updates to that. I would imagine other organizations that maybe use it more than they grow it. Maybe it could be bi-weekly to monthly, I’m not really sure I’m just speculating at this point. Not sure that I’ve seen enough to be able to answer that well.

For a design system, is it challenging to find that balance between ensuring consistency and inhibiting creativity?

 Yeah, absolutely. A lot of the times when we’re doing interviews, a lot of the resistance to a design system is well, like, “Is it taking my job away?” Essentially. And that’s why I, kind of to the question you asked earlier, that’s why I’m more and more liking the definition of a design system helps you design, it doesn’t remove design from you. It doesn’t remove the process of, “I have to create a thing.” It just helps you do it faster. I think any good design tool is that.

I could make a website without Photoshop. I could hand code it. I could make graphics in Microsoft Paint. Photoshop makes it easier for me to do that. But when Photoshop came out, a bunch of people said, “Oh, this is gonna kill my job.” So any new innovation in design, people have that worry. Any new automated thing, people have that worry and they don’t realize, “Well yeah, any design tool that could take my job is also a design tool that could actually make my job easier. Help me do my job.”

So I think the same thing is true for a design system is that if you think about it solely as a component library and all you’re doing is making and assembling components, then sure it could probably replace you. On the other hand, most designers and developers at the organizations that I know have design systems, the design system doesn’t solve their problem. They still have some sort of user experience or customer experience that they need to think about. A design system should help them to do that, it should help them build those things faster or more efficiently or more consistently. It should help them to do that, it doesn’t take away the work. That’s why more and more I like that definition that it should help you design. The creative part and the problem solving part, you’re not gonna find that in any style guide, component library, or design system out there.

How do you figure out the workflow between a design system and the products it serves? 

 I think it can go both ways and I hate to give the “it depends” answer too much, but I think it does. I’ll say that I’m working on a product right now and just this morning I went through with some of my team about creating our design system for it. We’re starting to create that now. One of the things that we talked about was let’s just be really scrappy about how we’re gonna build this. Let’s build one-offs as many times as we can. And then if we find that we’re building the same one-off 3, 4, 5, 10 times, then we codify that into a pattern. We’re taking that approach to how we’re doing this is like, “Let’s not worry about whether or not this rolls into the larger thing. Let’s do it on a small scale and then as we see it cropping up more and more and we get tired of repeating ourselves, then we’ll roll it into the design system.”

So we’re gonna keep the design system very, very small and it’s gonna be just the things that we know are patterns and we know, okay, we don’t need to reinvent that wheel anymore. And then as we see more and more of those things, then we’ll start rolling them into the design system. I like that approach, that’s a approach that I’ve recommended to a bunch of my clients is like, “Don’t be too aggressive on everything’s gotta go into the design system because that’s a way to bloat the thing.” So rather than bloating it, instead just be very vigilant about what things make it in and what things don’t. It’s okay to build a bunch of one-offs. And there’s gonna be a little bit of inefficiency there but that’s okay as long somebody’s noticing. As long as you notice, “You know, this is the fifth time we’ve built this thing this way. Maybe we should patternize this somehow. Maybe we should say okay, this is a common thing and we need to reuse this solution more and more so that’s when it rolls into the design system.”

How do you measure the success of a design system? Are there certain metrics you communicate to clients?

  Absolutely. I think the most obvious one is time spent. Like with a lot of clients, when they say, “Hey we want to make a design system.” At that point, even if we’re not starting work together, I’ll say, “Great. Measure the time it takes you to do this thing right now.” So like how long does it take you to build an app? How long does it take you to build it? And you can generally, you can translate that into dollar amount. The amount of time a salaried employee spends on it times their salary for the amount of time they worked on it times the amount of people working on it, right? You can quantify that fairly easily, or roughly. And if you can say, “Well look, this took us 6 months before and roughly 375,00 dollars. And then after the design system it tooks us 3 months and it cost us 175,000 dollars.” You can make a very good case as to how that’s gonna work out.

So before and afters tend to work well. It’s not good for … If I’m at a company, I’m trying to convince my boss to make a design system, I don’t have numbers, so I don’t have a before and after. But I think the more other organizations start to publish that stuff and become more public about that stuff, it’ll be a lot easier to say, “Oh, look at Salesforce numbers, here’s how much they saved by having a design system. Look at Airbnb and Spotify.” These companies that have been very public about their design system work. I’m hoping that in time they start to publish some of that stuff too and in the same way that they’re publishing their code and their design style and their component libraries, I would hope that they would publish some findings about, “Here’s what it’s saved us. Here are the benefits of it from a bottom line standpoint.” And other companies can look to that and say, “Look, there’s a path here already. There’s logic to this and so we can make a good case for doing it ourselves.”

Have you worked on any design systems that created surprising results?

  Almost every time. I don’t know that I can point to any specific thing or at least talk about any specific thing. But especially because we get a lot of users in before we’re done building the thing? I think part of what, I don’t know how to explain this, part of the value of a design system is to be able to point to a thing as a showcase piece. ‘Cause we could say, “Hey look at this cool design system.” But if no one can understand what you can make with it, then it doesn’t matter.

Having people come and work with it early and then when the design system launches, also launching with a gallery. Here’s a gallery of stuff that people have made already with it and you’re looking at those things going like, “Wow, I didn’t even realize you could make this.”

One of the organizations I worked with, they tended to use Material Design as their design system before they had something custom and in house. And they had a bunch of people making amazing things with Material Design. And once they had their own custom design system, people that were doing things with Material Design were creating things with their own design system and saying things like, “Wow, we couldn’t even create this with Material Design as easily as we could with our own thing.” Those are good testimonials, those are good rallying points for people to see within our organization look at what people are doing with this, look how much easier it is for us.

And the kicker of course is that it does have to be easier, you can’t fake that stuff. So it actually has to be authentic, it has to be genuine. I think the more and more examples we have of that, the easier it is to get more adoption.

Do you tend to help organizations build design systems completely from scratch or do you get brought in to improve an existing design system?

I would say that 90 percent of it has been we know we need a design system and we’ve had kind of starts and stops, but we just can’t figure out how to get this thing off the ground. And so a lot of our work tends to be how do we help organizations get to a v1? And part of that is because it’s not just making a tool, it’s different than making a website, if we were just making the website part of it it would be easy, but the reason that the design system is so hard to get off the ground is because it requires organizational change. It requires people to have different mindsets about how they’re going to work.

For example, if you have isolated design and engineering teams, a design system isn’t gonna do you very well because a design system requires collaboration between designers and engineers. If you don’t have a culture where that already exists, in order to even know that that’s gonna have adoption, you have to start to change the culture to say, “Okay now we’re going to be working together in a different way.” And that takes a lot of work.

So a lot of our work around the design system tends to be not making the tool but really coaching the teams on okay, here’s what it looks like to be more collaborative, here’s how you work on it. Here’s how you shorten your cycles from 6 weeks to 3 weeks because you’re working on pieces and you’re working on atomic parts and you’re working on collaborativeness. And you’re not building in this very waterfall, you design everything and sketch and then you throw it over the fence to this person. It’s all that organizational change that comes with it. It’s not like going away, making a website. It’s more like how do we coach people to work better together? And then once I understand that, what tool can even further facilitate that? And design system is a good example of that.

A lot of them can’t get it off the ground because they don’t know how to do that piece of it. They like help, so we tend to help with stuff like that. Very rarely have I come in to like, “All right we have a v1 already, here’s a v2.” And the reason for that I think is fairly obvious, which is that once you learn how to work collaboratively you can do anything. That’s the key. The key is being able to work together and if you can work together, you can solve any of the problems. So one you get it off the ground, you’re already along that train and then the v2 solves itself because you already know how to work on it.

At a organizational level, can a design system becomes reroute and improve your workflow?

 Totally.

I’m not sure that the tool itself forces collaboration but it certainly a catalyst in encouraging that type of work. Just having a design system isn’t magically gonna make an organization work better together, but the process of making one kind of forces these situations that maybe an organization hasn’t had before. And then they go, “How do we do this? Wait what do you mean we should sit together and work? What do you mean we need to reorg the way that our organization is structured? What do you mean we need to have a design system team? Why do we need to do that?” And it kind of forces those conversation. So it’s certainly more of a catalyst for it than anything.

Do designers on a design systems team need a development background?

Certainly not a requirement. It’s funny, I just did a talk about this yesterday. I was talking about that at the  O’Reilly Design Conference. It’s definitely not a requirement. You can create great digital experiences, and some of my favorite collaborators are designers who have never touched a lick of code or developers who have never, never don’t admit to being designers at all. I think it’s certainly possible to make great things without that.

I do think it helps though. I think that … And the reason is is empathy. The reason is that the more I know about what my collaborators are doing, the better I can help them, and the better I can serve them. The better I can take work away from them. The more they can take work away from me. So if I’m working with an engineer, if I could say, “Hey, you want me to write that JSON file for you? You don’t have to worry about it.” That helps that person out and they can focus on something else that’s more worthy of their skillset and their time. Vice versa, they can take work away from me.

I find that the more we can do each other’s jobs, it’s just means we can help more. If I don’t know how to do what you do, I can’t help you. I don’t think designers coding is a requirement but it’s certainly helpful because it means you can jump in.

Have the processes of creating design systems evolved over time?

It’s interesting because a lot of organizations and teams say that they’re agile.  And then when you get into their nitty gritty, you’re like, “This is not agile.” What it generally tends to look like is, oh the engineering part is agile but then the design part, the graphic design, the UI design, whatever you want to call it, that part is the waterfall part. We’d design stuff first and once all the design requirements are done, then we can get agile about this. And that’s not the way to do agile.

I think that a good design system will roll everyone into the same process. Whether that process is a waterfall one or an agile one. I’ve seen it work more successfully in flavors of agile and that’s how my team tends to work, is in that way. I think that the process of sort of rolling it out, keeping it up to date, is one that needs to work like any good product design cycle and it’s not a coincidence that generally a lot of product design cycles are centered around an agile workflow. I think part of the trick is how do you get designers involved in the agile workflow? Because a lot of designers feel like they’re at the outskirts of that and don’t really know how to be involved.

UX designers is a little bit different. UX designers and engineers tend to be a good pairing. But graphic designers or people that are doing UI design don’t quite know how to fit in to that. I think part of that is how slow they move in their tools. I think they need better tools like a lot of people will take a full day to bang out a comp in Photoshop or 2 days or 4 days in Photoshop or Sketch. And that’s not conducive to a very fast moving, nimble environment.

Designers, graphic designers, need to beef up their skillsets in getting faster at the work that they do. So that they can fit into a more rolling process and need to be able to bite off smaller chunks. Which engineers have learned how to do over the years. I’ll work in a way that is modular and work in a way that is … I can break off different pieces and measure those pieces. So designers haven’t quite figured out how to do that as an industry yet. So I think that the more designers can fit into that, then they’ll fit into a cycle that fits naturally with Agile.

So how do you see design systems working with Agile?

I think the design system fits in the way that any good digital product project process works. Everybody’s seeing, everything’s transparent, you’re seeing what everybody’s doing. That’s what the agile process does, it exposes those things through rituals like daily stand ups or retrospects or things like that.

What I find is that designers don’t know how to do that generally. They don’t know how to fit with that. And I think part of it is just the chunks of work are too big. So engineers know how to chunk their work down into things that you can measure, things like velocity or work in progress limits or depending on the flavor of agile. Designers are like, “Well I have to design the product inside and out.” And how long is that gonna take? I don’t know. It takes as long as it takes. Well you don’t have to design the product. Design the header, how long is the header gonna take? Oh, 2 hours? Great, chunk it up in that way.

I think as designers are sharing more often, I think if they are exposing some of that process more often, then they start to get in that flow of, “Okay, let me show something that inspires someone else. And that person’s work is gonna inspire mine.” And kind of let them riff off of each other. Like that’s what a good agile process does, is it allows this kind of double dutch thing of somebody works on something and somebody else works on the same thing and somebody hops in there and then somebody else, like it kind of builds on each other rather than, “Let me do my part and then I’m done and then it’s your part. And then your part can’t influence mine because I’m done. Because I said I’m done.”

And so by chunking that up, I find that that’s a very useful way. It’s a very simple but useful way to figure out, “Well let me just share a little sketch of what I’m doing, let me share a piece of what I’m doing.” It’s a bit a cliché now, but I think that it works. It’s like share small pieces more often. And designers, of everyone in the process, are the most guilty of not doing that. They share larger pieces less often. ‘Cause they feel like they gotta do the big reveal thing and they’re afraid that if they reveal something too early or too late that people aren’t gonna see all the things in it. I think that if you give your team credit for being smart and being able to see through certain solutions, see to the end of it even if it’s not fully realized, I think that actually opens up the door for a lot of good value.

Does the modular nature of design systems facilitate an Agile design process?

Maybe, I’m not sure. I haven’t really thought about that too much. I think that certainly design systems help designers be more agile because it makes you faster. I could simplify it more to be like anything that makes you faster helps you fit into that process. ‘Cause the process is about speed at some point. There is a reason that Scrum measures things in velocity. It measures workflow in velocity. It is factor of speed, it’s about how quickly you can get things done. And sometimes it’s about- it’s not about fidelity quite yet, it’s really just about pace.

A design system at some level would probably help you to do things faster. It’s a good tool for speed. And I think tools for speed help designers, engineers, everyone to fit more in that process because they can make more in a shorter amount of time and then share it. And say, “Here this is done, everybody check this out.” Or, “Look at this and tell me what I need to do in the next cycle for it.”

I think that designers, maybe of all the industries so far, don’t have the tools for speed as much as other industries do. And so I think that the more we get better tools for speed, design system being one of the major ones, I think the better we’ll be able to fit in.

What design systems do you find particularly interesting or inspiring?

  I’m not sure that I can name many digital ones, other than the usual suspects. I think one, I’ll say that any design system is a major feat. Launching one, creating one, maintaining one is a feat in itself so if you have a public design system out there. Congratulations, that’s an amazing thing. As I think about those, Material Design, Lightning Design System, Harmony by Intuit, Glue from Spotify, the Airbnb, the companies that have been very public about theirs are … Those are major feats at those organizations. So those are great.

I will say the ones that I learned the most from … And it’s not to knock the digital ones I just think that it’s too early in our industry, we’ve only been around for whatever 30 years, and we’re still getting our bearings on what conventions are. So a lot of these style guides, a lot of these design systems are not specifically design systems for the implementation that they’re in.

For example, Material Design isn’t just a good design system for Google products, it’s just a good design system for anyone building for the web. Same thing with Airbnb, same thing with Lightning, those are all good for general best practices. I think what those are starting to do is they’re starting to create conventions for us as an industry for the designers and the engineers as an industry. Because they’re giving us things like, “Oh this is generally what navigation should look like.” And it’s no coincidence that navigation patterns and tabs patterns across all of those design systems are pretty similar. ‘Cause they’re starting to surface these conventions.

When I read some of the design systems in the print world or specifically the NASA style guide and the MTA brand guidelines, as I look at those design systems those to me feel very mature and they feel like they help me to design. If I was designing for the MTA, I would know exactly what to design and what to design for. Because the brand guidelines are so thorough. Not only do they give me the pieces that I need but they also give me the logic and the mentality to know how to design for those things. I don’t know that I’ve seen or could recall a lot of digital design systems doing that.

So when I work on a design system I try to focus specifically on what makes for a good design system for this organization? Not generally on the web but for this organization. What are the patterns that they need that maybe others don’t? And those are the things to focus on for the design system. How many tabs can you design? How many interfaces for tabs can you design? But is there a specific way that this organization uses tabs that is custom to them, that if they had this out of the box it would actually advance their work? It would make them faster at it.

So those are the types of things that I try to focus on. I’m not sure that I’ve seen them in a lot of digital design systems, and partially because I don’t know the requirements for those organiza- I don’t know what Spotify needs, I don’t know what Airbnb needs, so I’m not sure what I would even be looking for there. I think those are the things that I try to focus on in my work.

If you could speak for a couple minutes with somebody who’s about to start creating their first design system, what would be your most important advice?

It’s a tough question. If I could only give them one piece of advice, I would say talk to people. Talk to the people that are gonna be using it, find out what they need, and then spend all of your time on that thing or on those things. I think it’s easy to get caught up on making design systems that look like the ones that are out there already, like, “Oh this is the convention, this is the guideline so let’s just make more of these.” And I don’t know that those are necessary. And I certainly get caught in that trap all the time. Like, “Well, Salesforce looks like this so ours should look like this too.”

But oftentimes you’ll find out that people in the organization, they don’t need that stuff. Sometimes they do and it’s good to know that and sometimes they don’t and it’s good to know that too. If I were to give advice to someone, I would say, “Talk to as many users are you can.

Talk to them about what they need and just build that stuff. And as soon as you build that and no sooner or no later, as soon as you build that thing see if you built the right thing.”

Talk to people and then test as early as you can to make sure like, “All right, is this what you said? Is this what you meant?” Oftentimes you’ll hear a “no” and the earlier you hear that “no”, the better chance you have of getting it closer.

Kaelig Deloumeau-Prigent is a Senior Designer on the Salesforce Lightning Design Systems team.

With years of experience in front-end design and development, Kaelig sat down with us to share his advice for building a design system. To learn more about the benefits and processes of design systems, download the free e-book Why Build a Design System?

How’d you join the design systems team at Salesforce?

Kaelig: That’s actually a pretty funny story. My wife moved to the U.S. to work at Apple. She’s American, but we lived in London for a while. I thought, “I might as well follow the wife.” I came to the valley to just visit her, and started talking to a lot of people here. Just about what they were doing.

For lunch one day, I meet with Gina and Steph. They’re talking to me about this thing they’ve been working on called The Lightning Design System. It was very early stages, at this point. Nothing too crazy in production. It was very promising.

I saw what they were looking at in terms of vision, and in terms of infrastructure, as well. It was awesome. I did not see Salesforce as a UX minded enterprise before. That totally changed my mind on how Salesforce is capable of doing UX.

I thought I’d love to be on that team. They were … It actually came to me as a discussion during lunch where they were like, “Wait, so you’re moving to the valley? That means you’re going to be looking for a job at some point.” It was very natural, and really good fit. I’ve been there for about a year and a half, now.

When you first joined the design systems team in 2015, what was the bulk of your work focused upon?

In the beginning, I was working, a little bit on the CSS. A lot of peer requests and the reviews revolves around nitty gritty details of the code and it was definitely a lot of time that was spent on looking at stuff that could be automated. I quickly started looking at opportunities to improve the process such as, just basic things like: linting or how can we better at continuous deployment. All the little things that were getting in the way of shipping really good CSS in the first place.

How was the design systems team structured when you joined?

It was very multi-disciplinary. The manager was the designer. His name was Chris. He was awesome. He left shortly after I joined but he was the glue between the design system’s team and the rest of the company, definitely. He was playing the role of the interface between us and the rest of the company.

Then there was Steph, who was the lead, and she’s still the lead by the way, on the CSS architecture.

Adam is the, been since the, kind of like the, almost since the beginning I guess, who has been working on Theo as well, I don’t know if you’ve heard of it. It’s a great tool for exploiting design tokens, we can talk about this later. And then he’s been one of the forces behind the code infrastructure of the stuff.

Brendon handles CSS, and has huge background as a creative director and just really good at turning code. Just building a lot of components.

Then there was Gina who is more on the design and evangelization side, and the, and kind of took into the whole thinking behind how we can integrate with design at scale. And we had an amazing graphic designer who came up with lots of the icons, tailor made for  Salesforce. He was the guy behind it. And I joined as a more, technical sort of guy after that.

When you first joined the team at Salesforce, what were some of the biggest challenges that you were facing?

The biggest challenge in a company, a large company like Salesforce is definitely to try to have great processes that are really fast and really efficient, while being part of a greater organization, which itself has its own processes, its own way of doing things that has been going on for the past eighteen years now. For me that’s the biggest challenge, because looking at the big picture and all the processed of all the teams that are going to consume to design system and trying to fit with is really challenging to me.

What were some of those processes that you had to modify or completely rebuild from the ground up?

Unfortunately not everyone is using NPM and just get it in general. So in general we have a lot of processes that revolve around our release cycle, which is three main releases a year. When you want to be releasing on a daily basis in terms of design systems so that you can catch errors and regressions as quickly as possible, it doesn’t necessarily fit with that greater goal of delivering features, major features, to customers three times a year. An example that I think Gina likes to take as well is: People keep asking us, “Hey I want an icon for my new feature.” And so it takes a little bit of time for us to build it and to ship it in the design system. But then the greater question is, “How do we make sure it gets to production and what is the process through which designers and engineers can sit together and know, where is my icon right now? Is it accessible in one release ahead of us, two releases ahead of us?” Because I don’t know if you’re familiar with our release schedule, but we are working on two to three releases at the same time. Knowing where all the assets are and what is available to you in the code is the type of challenges we are looking at.

On my side what I manage to do it automate as much as possible on our side of the platform. There’s a lot to do still. But that’s the kind of stuff we are looking at.

At Salesforce right now, where do the design system assets live?

The design system is a collection of multiple GitHub repositories itself. We have one source of truth in the end, which is, it’s a single source of truth, we have an internal portal where all the developers internally, and all the designers can go and collect the resources. Then if you’re more of a graphic designer or UX designer, you want to go to the design system to collect everything, so we are beta testing the internal tooling right now around this as well where we’d having something, like a desktop app, that would integrate really well with Sketch, with other software so that you don’t have to go to a webpage every time you want to look for an illustration, look for designer assets such as icons, most of the time.

I guess its multiple sources of truth, but we are trying to find, also, points of convergence where we could automate most of it. Such as, again icons, it’s a big deal. So that’s where we are at right now.

Where has the Lightning Design System evolved the most?

Definitely in terms of components.

When I arrived we mostly had UTT classes and forms, you know, basic components. And now we are seeing really really massive, really complicated components. High-quality components were definitely the thing that was most demanded across the company. We have multiple dozens of scrum teams working on features at the same time, so they are really demanding and they want stuff and fast. That’s the area where we have been growing the most and now we are looking at other areas of improvement as well, such as design guidelines, building better documentation in general.

You mentioned improving documentation as one of the goals. Could you expand on that a little bit?

One of the most important things in the design system is not necessarily the self-service side of it. It’s also understanding the thinking behind each design decision that was made, and sometimes one component is going to impact so many design decisions at once. Having some sort of peer guidelines on how to use it is great. And also, why this component was built like this, and what was the thinking, is also something we’re looking at.

Explaining some of the research findings, directly close to the components or, actually the design patterns that led to building this component the way it is. Accessibility as well, you probably notice, we don’t include JavaScript on the design system so we need to include peer guidelines for JavaScript developers on how to implement the design system components across multiple frameworks. And so, really good documentation is key to scaling that, kind of, best practices.

For a place like Salesforce, it really matters a lot.

What’s the process for updating the design system?

The public side of it is that you can simply go to the Open source project, and open any issue with a feature request. That’s the visible part of the iceberg because internally we have a slightly different process where … I don’t know if it’s very formalized at this point, I know we have different channels and we are trying to funnel everything through the same person, which then can direct their request to the right people. I’d say that it comes 50% from the designers who are working on the platform, and 50% from feature teams who would really like this little thing that they’ve been working on, and it’s not in their design system, and they’d really like it to be in there. It really depends, sometimes it’s more … Before something is shipped, sometimes its after something is shipped … I’m not sure there’s really formal process, I’d have to check with my team on that.

What goals do you have for the future of the design system?

Improving the collaboration model so that external and internal people even outside of the Designs System’s Team can add documentation themselves or add component even. We are looking into that right now. Not just small features or small tweaks, but whole features, sorry … Whole new components, whole new parts of the website.

Regression testing is a big deal for us. We are trying to improve the regression testing so that each who are contributing, you know you’re not breaking other people’s stuff. Because we have more than 500 components and states, it’s crucial that we have good testing behind it so that we limit the side effects. In general we keep looking at our architecture … There’s a lot of stuff going on on that side and you’re going to see that in the next few weeks if you’re careful about what we are going to be releasing. Pretty excited about that.

What does your release schedule look like for the design system?

The way we release right now is that we have internal releases that are actually happening every time there’s a comment. So we are pushing that to a staging area. And that staging area gets approved at some point. We have a lot of regression testing happening there. Every time someone is opening a poor request, there’s a lot of testing happening every time there’s a something merging to master, it’s pushed to all documentation, documentation side.

Once every week or two weeks we do releases to production in a … It’s not public yet … And then, how do I say it? Essentially what’s happening is that we are always working one release ahead of what’s public … What’s available to the public. For example, if I push a comment right now, it’s going to go into the next release. As soon as I tag it, I give it a version, like, I don’t know, 2.3.0 beta 7. We hand that to a team that’s handling all the CSS and asset management on the real big products. Then we can also spread it to our teams who are using NPM, simply.

There’s a lot of ways for us to push our changes and to release it, but … Then when we release to the public, it’s about 3 times year. Then the actual release is when there’s like a really big thing that needs to be fixed in production, that’s impacting our customers and developers on the outside. It’s kind of a weird release process, where we have to be in sync. We have to really be mindful of how teams are working internally. We have to stick to that process. We wish we could release more often, and I know Salesforce is doing more work on the continuous deployment, continuous integration, and better release management, so hopefully one day, pushing a comment will actually send it to the customer directly, instead of having to wait 3-6 months.

What you find most challenging aspect about working in a design system?

Good question. I think the fact that, again it’s a big company, and there’s a lot of processes going on, and its not always easy to be super agile in that kind of way. I think for somebody like me who’s been working in kind of, a loose type of workplace before, working in a very organized place like Salesforce can be a little bit challenging.

There’s a real schedule behind it, there’s a lot of thoughts put also on the vents that we’re giving and how our developer marketing team can show how to use our products. We have training material, as well, on our training platform. Every time we do a tweak, we have to be mindful of, is that going to impact the way people learn about the design system? I think that’s the most challenging. Having this huge amount of information applied to small details like how well are we doing CSS? How are we releasing CSS? All these little things need to … Take all of that into account.

What benefits have you seen from the design system?

Spreading best practices.

One thing is clear, is that your cannot hire experts on every team. It’s impossible. We couldn’t hire 70 front end experts and put one per team. That’s impossible. Seeing the quality of the front end increase at scale has been a huge win. We couldn’t have hopes better … Seriously, without the design system, I cannot even imagine how much time would have been spent trying to recreate the same patterns over and over across all of our teams. Also, with the type of quality we are expecting from them.

That’s been one of the wins, and more recently, we’ve seen a few really interesting wins. One of them is that really close to a major release last year, we decided to make huge changes to our navigation. What would have been, I would say, months to change, took 1 or 2 sprints. That was a huge win, and it demonstrated changing colors and changing a few things across multiple teams in just a few CSS changes. Proved to management and to the stakeholders that there’s huge value in that design system.

Another thing is that we’ve decreased the custom CSS from production. As this is happening, we see the amount of CSS served to our customer go down, which is great. It’s a really good win for us. It’s just less things to download for our customers, so faster pages.

What metrics do you use to evaluate the design system?

Reduction in CSS code and how much of each main screen of our application is using the design system. We are doing nice visuals for the execs to understand where … There’s the header, its all in the design system. There’s the page header, again, all in the design system. And then as you go down the page, a few things start to break out, where … So we paint some areas in green on a nice slide … The execs like a good presentation. We take a screenshot, we paint some green where the design system is and we start painting some red where it’s not using the design system. We’re showing them at this point last year, this is where we were at. It’s all red. And all of a sudden you look at the new page, its all green.

They know that thanks to that, in the future, if we do design changes, such as changing the content density, changing colors, making tweaks, teams won’t have to go back to their code and you don’t have to ask 70 teams to change that little bit of markup on the drop down. It’s just all in one place and so they see the … Instead of technical debt, it’s like, we’re making a bet on the future. We’re taking a loan on the … How do you put it? I’ve got to remember. I read some sort of a metaphor around technical debt that you can also do the inverse and make it technical investment and I think that’s one of those.

What lessons have you learned along the way?

A few things that I’ve personally encountered have mostly to do with, again, the overall process. Thinking you can change everything on day one.

Support is really hard. We get a lot of support requests from our open source, but also from internal customers, from so many different sources, and it’s really hard to keep track of everything and to be consistent in your support strategy. That’s something we are only starting to scratch the surface of, but I think we didn’t really have any process in place, and if somebody was going on a holiday, a full channel of support was not cared for, for like 2 weeks.

And then customers don’t like that. That’s one of the things that we’ve learned, that support is really important. As you’re building a product, you need to account for support in your overall strategy. That’s part of building a product. That’s a few of the challenges we’ve learned and … It’s been lots of really good wins mostly. I see them more as little hurdles that we’ve had along the way, but there’s not anything that was a huge realization of, Oh my god, why did we do that?

Actually, there’s one thing. Documentation is really important. Not only the external documentation, but in the code. Looking at your own code 6 months later, especially when it comes to CSS, it’s kind of hard. You want to document your weird decisions in your code. In your CSS because you’re going to have to go back to it, and at some point you’ll be like, hmm what was I thinking? And then they’re touching it again and you’re like .. You know you have to keep that code in for months and months because you’re afraid it might break somebody’s implementation and so … Yeah, document your work a lot.

Nathan Curtis has mentioned that working on a design system is like working on a product that serves multiple products. Would you say that statement rings true?

I think Salesforce is the pinnacle of that quote. I think that Nathan Curtis totally nailed it on this article and it’s exactly what the Salesforce design system’s team is doing. It’s definitely building a product, a set of tools around it, a set of contribution guidelines … It’s a really fully pledged product. I think we are more than 20 people working on this right now. It is definitely that.

There’s multiple teams. There’s a team that’s more looking after the CSS and the release process, more UX engineering based. There’s a team who’s building prototypes that then can inform the design system, and there’s the team that’s more on the creative side. I think there’s another team, which is essentially looking after the patterns and the overall design strategy, and the more lower-level, as in, what are the really deep principles that drive each piece of the interface. All the teams aren’t necessarily working 100% on the design system, and their work kind of overlaps at some point. We have a team who’s mostly caring for building the website whereas another team is going to be building, more icons or total, it’s around 20 , 25 I would say.

What advice would you give to someone about to build their first design system?

Start small. That’s what a lot of people are doing. Then get buy in as fast as possible. It’s really really important to get executive buy in because if it doesn’t come from the top, I don’t think it’s going to work. To me that’s the hardest part of building a design system in a company is to tailor that narrative to your business problem, and then deliver something that follows that narrative. I think it’s really really the crucial point and really hard to do because designers and developers are not necessarily good sales people.

I think it all started with people like Gina, who had the vision, who had the ideas, and told that vision to somebody who could speak to even higher instances. That worked out because the designs system got funding and actually we built a team around it.

It wouldn’t have happened if executive buy-in was not part of the game.