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.
