Member-only story
Building a design system: A one-year retrospective
In this conversation, I sit down with my coworker Brian Clay to reminisce and reflect on the first year of building our company’s design system, which we call Kyper. Check it out here as a Figma Community download.
Brian is a super talented designer. I brought him onto my team a year and a half ago to own and reboot our design system. We talk about how it’s gone and advice we would give to anybody just embarking on a company’s design system journey.
This conversation transcript has been edited throughout for clarity.
Start with Outcomes in Mind
Derek Boman
All right, well, we’ll dive in here. Today, we’re gonna talk about design systems. And what makes a good design system, a little bit about what we’ve done at MX, we’re a year in, and there’s been some ups and downs along the way. So we’re gonna dive into those.
So in terms of goals for a design system, I think it’s important to always start with, “What are the outcomes that you’re trying to achieve?” And as we think about it, here are a couple that comes to my mind, and you can add in any that you think about. I think about, (1) as we have distributed teams, how do we keep the product consistent between individual designers. (2) How do we not have to rethink things that have been already hashed through and problems that we’ve already solved? (3) On the developer side, being able to increase speed to market, test ideas, get things out there, the ability to quickly deliver product, and not have to reinvent the wheel every single time you have a similar component.
Those are just a few that come to my mind. Anything else that you think about in terms of desired outcomes for a design system?
Brian Clay
I think that’s a solid list. The most important one to me is saving our developers’ time. Being able to build the actual product more quickly, I feel like, is so huge because you can do a lot of user testing previous to build. Still, I…
