Smashing Podcast Episode 51 With Ben Callahan: What’s The Value Of A Design System?
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
This episode has been kindly supported by our dear friends at Wix, the platform for professionals to build client sites, manage complex projects, and grow businesses online. Thank you!
In this episode of the Smashing Podcast, we ask how you can prove the value of a Design System and how you can pitch it effectively to stakeholders. Vitaly talks to Ben Callahan to find out more.
Show Notes
- Ben Callahan on Twitter
- Ben’s website
- Sparkbox
Weekly Update
- Meet Skeleton: Svelte + Tailwind For Reactive UIs written by Chris Simmons
- Everything Developers Must Know About Figma written by Christine Vallaure
- Designing A Better Back Button UX written by Vitaly Friedman
- An Introduction To Context Propagation In JavaScript written by Evyatar Alush
- Implementing A Reset Password Feature With Next.js Dynamic Routes written by Caleb Olojo
Transcript
Vitaly Friedman: He studied computer science and worked as a software engineer, as an audio engineer for independent films, as an animator and of course, as a front-end developer focused on standard-based web development. These days, he’s the design system researcher and consultant working with wonderful people, almost sparkling people at Sparkbox to build a better web. Now, he’s always in learning mode and there is no better way to describe him as an explorer, maybe even Internet Explorer, with a very strong focus on design systems. Now, he lives in Dayton, Ohio, loves cooking, poetry, travel, photography, coffee; that was an important one. And has two, pretty as well kiddos, my threshing friends, please welcome. And I hope I can hear the cheers and applause right here, Ben Callahan. Hello Ben, how are you?
Ben Callahan: Hi, Vitaly. I am smashing.
Vitaly: Well. That is fantastic to hear, while you do look smashing as well. If I may say so, Ben, let’s start right away and dive right in there. How does a person who just happens to be a software engineer turn into a design system researcher? Can you show a bit of your journey to get there? Because I know that you’ve been working on design systems probably before it was even a thing. So I want to hear it all.
Ben: Yeah, absolutely. Thank you for having me, Vitaly. I do appreciate it. I’m super excited because I love design systems. And one of the reasons that I think it’s become an area of focus for us is because I have seen how it has helped organizations create a lot of unity inside their teams, which is something that I’ve always wanted. And so, if you’re asking about my journey, the reason I’m pointed in this direction is because of that. And if I go back, I did study computer science.
Ben: I was frustrated working in the corporate world feeling like I didn’t have a lot of… There wasn’t just a lot… This wasn’t a vision for the things I wanted to work on. And so eventually, I stepped out of that space, took a year to just explore different technologies like animation and audio, and just other things that I was interested in, and ended up starting a business, doing video production and audio engineering.
Ben: And then we did a website for one of our clients. And as soon as the rest of our customers saw that we offered that, it just was the only thing they wanted. This was early days of the web, and so I ended up buying my partner in that business out and transitioning it to a web studio, a very local web studio here in Ohio. And eventually merged that with a few other folks who were doing good creative technical work in town, and the result over a few years of us churning to figure out what we really wanted to do was again a focus on the web.
Ben: And that’s how Sparkbox was born. I’m really fortunate because we’ve grown slowly and steadily over the last 14 years. And that means that as a front-end engineer, as a computer science guy, I’ve transitioned out of writing code every day. And instead, I get to focus on where I want us to be headed. What do I think is important for us to be learning, and how can we best serve our customers? And that’s really how I pretty naturally ended up digging in deeper to design system work. Because I actually do believe that it is a unifying opportunity for a team, so that’s how I landed here.
Vitaly: Oh, that sounds very exciting, indeed. And I think in many ways, we are everybody who is listening to the show now as well; I think we all have been in one place, and then we moved to a slightly different one just steadily and slowly. And I know a couple of people who used to, I don’t know, sell glasses before the internet was a thing. And then off you go becoming a designer, developer, manager into design systems and all things like that, so that’s really exciting to see that.
Vitaly: Interestingly, talking about design systems, I think we are in a very interesting position right now because it feels like we have been playing, and doing, and experimenting, and working around design systems for many, many, many, many, many, many years now. And I don’t know about you and probably have, of course, way more experience than that. Many teams already have one, right? Or they’re trying to get one, and it might be up-to-date, maybe not, but they’re definitely not something new and shiny around the block that we just need to try out.
Vitaly: Many people have tried to do that, you did spend a bit of time trying to understand what makes a design system mature. So maybe you could actually dive a little bit more into this and explain, based on your experiences, of course, the Sparkbox as well. What is the maturity model for a design system? So what does it entail?
Ben: Yeah, you’re right, Vitaly, that we have been as an industry working very systematically for a long time, years before we started to use the word design system. And Sparkbox, like many other studios or consultants, had been working in that way for a long time. I think when you put a name on a thing like design systems when you give it a name, it takes on a life of its own.
Ben: And so definitely, there was a point probably six years ago when our clients just started asking us for that, six or seven years ago. And so I think when that starts to happen, as an organization, as a leader in an organization, I feel like it’s my job to better understand that. And for us, what that has meant is for the last five years, we’ve done what we call the design system survey.
Ben: And that’s just to open to the industry. And as part of that process, I get to ask; I get to do lots of interviews with folks who I just find online, who are doing this work in an interesting way. And I just ask if I can have half an hour or an hour of their time, and I just ask them a ton of questions.
Ben: And so that has given me a lot of exposure to very broad perspectives on what’s happening in the space. And so with all of that, as part of an input for me, what I have done over the last four or five years is each year talk to lots of folks and then sit down and try to find some cohesion in all the different stories that I’m hearing.
Ben: So, a couple of years ago, leading up to the release of our survey for 2021, I had done that series of interviews. And I realized that there were some patterns that I was seeing emerging in terms of how systems were moving and maturing. And that’s where we landed on these four stages that we think most design system programs move through. And that we tried to keep these quite simple because I don’t want this to be something that’s super theoretical.
Ben: I want it to be practical and useful, but at a high level. The model is there are these four stages; the first is just building version one, so that’s literally everything you do up until you release something for subscribers inside your organization to start using. And then pretty much every team that I’ve spoken with who has gone through that and actually got something out the door, their next big focus is almost always on adoption.
Ben: And that makes a lot of sense, right? You spend a bunch of time building a thing. Of course, you want to see if other folks are interested in using it. And so that second stage is driving adoption. And then, if you’re able to make it easy to become a subscriber, and if you do a really good job supporting folks who are using your system. And if you continue to evolve the system in a way that it shows value to lots and lots of different types of subscribers inside your organization, then you can reach this third stage, which we just call surviving the teenage years.
Ben: And it’s a tricky season, because there’s lots happening, right? You’re having a lot more people use the system. I can guarantee you that they’re probably going to try to do things with it. You never imagined they would. This is where you heard of having to make a decision. Are we actually going to treat this like a product? Are we going to offer support in a really healthy way? Are we going to come alongside the subscribers and engage with them been good ways?
Ben: And if you can continue to survive that stage, you reach what we call stage four, which is just evolving a healthy product. And this is really where the design system team actually takes a role in terms of leadership inside the design organization itself. And these teams that are stage four are doing incredible things. When I talk to people inside these organizations, they talk about the design system team as the place where the most skilled workers in their organization operate.
Ben: They say things our design system team was ready for us. When my product team came and said, “Hey, we want to try view.” That they had already done a spike on the design system team to show they could support that. They’re very proactive. They’re not reactive. And that’s, I think, a really healthy place to be at the table for big conversations, to be driving decisions inside the org. That’s what I think is possible if you mature in that way.
Vitaly: Well, that sounds very exciting. But then in your experience, looking again at the work that your clients are doing, where would you see most companies are at this point? How many actually reach level four, and where do most companies struggle?
Ben: Yeah, that’s great. I’m glad you’re asking that because I think doing that work, one of the outputs I was hoping for is to make it clear how to move through these stages in a healthy way. I think you said something earlier that I’ll just harken back to you which was… You said most folks have a system already. What I’m seeing is that many organizations are on their second, third, fourth, or fifth attempt at doing this work.
Ben: So it’s not just that they have a system; it is that they have been struggling to build a successful system for years in some cases. Most of the time, I would say most organizations that I get a chance to interact with are stuck somewhere between two and three. And it’s actually really common to get stuck there because this is where everything before stage three is about building something people will value and use.
Ben: And in order to transition into three, you have to… What it seems like right now is that you need to increase the size of your design system team. And the skill sets that are needed are a little bit different. This is where you have to actually add in a product support team, like customer service for your subscribers, right? And it’s because the system is if it’s going to take root, it’s going to be a really fundamental piece of any interface work that your organization does. And for that to be the case, you have to really actually support those folks in a really healthy way. If they don’t feel like you’re there for them, if they’re going to use your product, you have to show them that you’re trustworthy, and so-
Vitaly: That’s right.
Ben: … that requires more people, there’s just more to do. And so that’s a tough spot. I see folks oftentimes moving between two and three quite a bit. I haven’t spoken with a ton of folks who have reached that stage for more mature, really driving more proactive decisions inside the org yet, but they’re out there.
Vitaly: Yeah. One interesting thing for me was when I encountered working with one of the bigger companies from Romania, actually, and they’ve been working on a design system for six to seven years, pretty much aligned to what you were saying as well, where everybody was on the gold-rush design systems, gold-rush in a way. And I was extremely impressed with just how concise, how well established, how reliable, and how sophisticated the design system was.
Vitaly: And so that took a lot of iteration, of course, as well, but it also takes a big commitment from the top. And I know that you also have been speaking for a while now about how to sell design systems because very often it is expensive. And very often, you still need to convince the right people that this is the right amount of effort and that the return on investment will be worth it. Would you say that at this point, it’s something that’s already considered to be true most of the time? Or is it something that you actively have to prove every single time with some metrics or KPIs? How does this work for you?
Ben: Yeah. It’s not proven. I think, I mean there are organizations who have done that work for their use case and I think that’s great. This is a tough area, and I don’t have a single answer. I have more of an approach. I think that has helped us. So I have had the opportunity to speak with a lot of leadership inside organizations where they’re trying to make a decision if they should be investing heavily in a system.
Ben: And I think that’s actually probably the right first step. I’m not somebody who is absolute in this. I think there are situations where a design system is really helpful, really beneficial. There are situations where I probably wouldn’t recommend it. That doesn’t mean some variation of patterns and components and things isn’t needed in most cases.
Ben: But if you have a single product and a small team and you’re in startup mode, it’s probably not worth investing all this time and money to build a design system to support a single product. It’s just the bang is not there for your bucks. So there are definitely use cases. That’s one of many where I probably wouldn’t recommend it.
Ben: In terms of once you’ve made that decision to pursue it, then it is about making sure leadership is on board at some stage in there, you have to make that transition to getting leadership really bought in. Not every system starts that way. We talk about in the maturity model, there’s a concept called origin stories, which is just really how involved and aware and supportive your leadership is in those early stages.
Ben: And there are many systems that are very successful now that started without any… No leadership involvement at all. It’s a transition; it’s maturity that has to happen. And as part of a successful system, you do need that long-term, but the way we help our clients figure out how to get support from leadership is that we do what you would do with any other product as we go. And we talk to those folks, and we try to understand what their needs are and what their goals are.
Ben: And how can a design system be shaped to serve those things that are important to them? And if you can reposition, the effort in a way that it solves problems for folks, they’re going to be willing to support it. The other big thing to talk about in those early days when you’re selling the systems especially is that you… A design system is only going to show its value over a very long period of time.
Ben: So this is truly an investment, right? It’s the kind of thing you put time and money into, and you have to trust that over the years, you’ll start to see a return on that, but it’s not a quick thing. So being clear about that upfront is actually really helpful in the work. And your last question was about, is it something you just sell once? And then you’re done.
Ben: I’ve never seen that really work. It’s a constant. That actually is part of the maturity model. We talk about three things, education, which is convincing folks, talking to folks, casting the vision, explaining why, what, how, and all those things. Engagement, which is getting folks involved in the work with you. It’s not a one-way thing.
Ben: It’s definitely very… There’s a lot of work required from all the different groups involved and then evolution, which is just simply making the system better over time. So if you’re not doing all three of those things all the time, you get stuck in that, in those steps to mature, so that’s what we’ve learned.
Vitaly: Right. Well, that’s very exciting. I’m wondering, and I really want to know more about what you have learned because you did mention that you and the wonderful team at Sparkbox have released the design systems survey 2022. And I’m really curious about some of the new things that you maybe haven’t uncovered there. What were some of the most surprising findings that you discovered there during that research?
Ben: Yeah. I mean, each year, we do that. This is our fifth year releasing that; each year, we come away with some really interesting insights, and this year’s no different. One of the things that really stood out to me I remember when we were working on what questions we would ask this year. And there was a series of questions in the survey this year about your top challenges. And we give folks a list of options to choose from, and then what are your top priorities? And we give them the same list.
Ben: And I remember reading that question and saying to my team, aren’t people just going to pick the same things here, right? If these are my challenges, then why wouldn’t those be the things I’m prioritizing? But they convinced me to leave it in, and they thought we would find something insightful there. And, of course, they were right. One of the things that are really interesting to me is in that survey; there are a handful of areas where you can see a difference in what is important to people in terms of what is a challenge and what they’re actually able to prioritize and work on?
Ben: The one that stands out the most is staffing. And this ties in actually with what we were just speaking about, Vitaly, around that stage two to stage three transition where you need to grow the team, the number of folks working on this, like the volume of work gets much larger as you move from stage two to three. And if you don’t have the support from leadership to increase staff, which is what that is hinting at, you can’t really do that well. You can’t make that transition well, and to me, the way I’ve interpreted this is that a lot of folks in the survey data say staffing is a big challenge, but it’s not; it can’t be a priority for them.
Ben: And it’s interesting because I think what that means is there’s a separation in the things that the design system team has the authority to prioritize, right? So they may be able to say, “Here are the things objectively that we have as challenges,” but maybe they don’t have the authority to choose how to spend the money or how to prioritize things, which I feel is a disconnect. If we’re going to trust these folks to run this design system program, we have to trust them to set their own priorities. So that’s one that stood out to me for sure.
Vitaly: Right. Right. It’s always kind of a story because I think in many ways when I deal with companies that choose to go ahead and give the green light to the team for design system, there is still always a little bit of trust that this is a simple, relatively simple site project, which is not going to drive us away from the main core product that we’re working on. So if designers, in this case, believe that this is the right thing, surely this cannot be the priority. And so surely there will be no extra stuff involved in making this happen.
Vitaly: And so that’s pretty much, I guess, aligned with what you are saying here as well. And obviously, people are important. So I’m wondering, though, in your experience, maybe that would be interesting to explore. What would you say are some of the important ingredients of a successful design system? When do you know that you are on the right track? Or how do you know, do you ever know, Ben? Do you ever know?
Ben: Yeah, it’s hard, man. It’s hard because it gets into the promises you make early on, which are the things that people are going to expect you to prove later. So I think successful systems can look very different inside different organizations, and it’s really. I wish there were a simple answer. I think there are some common things; we talk about a lot of those things in our survey we ask each year, do you feel your system is successful?
Ben: And then we can take that information and look at the other characteristics of design system programs that where they feel they are successful? And then we can make some interesting observations. One of the things that we always see is that having better engagement almost always means that individuals feel that the system is more successful. So, in other words, you can’t operate on this. You can’t build and offer a system unless you’re actually working alongside the people who need it.
Ben: It’s like any other product, you have to understand their needs, and you have to get down into the work with them. And so that’s what we encourage and help our clients set up as those engaging practices. I think the educational side of it is always key too. And this is where, in fact, this year, one of the things I’ve been focused on is just going back to what a design system is.
Ben: And this sprung out of a couple of consulting engagements last year, where big companies that have had systems for years, and we get in there and ask a ton of questions. And what we understand very quickly is all the people here have very different ideas about what a system is. Why it’s important? How should it be done? And this is seven, eight years into folks working on this stuff. And people still don’t actually understand what a design system is? And so that’s a problem, right? And-
Vitaly: Right, right.
Ben: … I’m not saying that you have to have the same exact definition that I do, but if you internal to your organization, don’t have that defined, that’s where the real problem is. So we did a bunch of work this year to lay out what we just call the anatomy of a design system, which is a very simple breakdown of what a system is. It gives us some common language to use, and that’s been really helpful for our clients and for us as we work alongside them. So I think going through that exercise with your own internal team is one way to make sure that you’re going to be setting yourself up for success. There are probably many more.
Vitaly: Right. But then, Ben, can you maybe shed a bit more light on things like, “Hmm, how would I put it best?” So if I’m working with semi design system in the company, and I’m pretty confident that things are going in the right direction, and it seems like everything is reasonably well structured within the organization, there are people who are working on it. It goes as it’s supposed to be. What would you say as some of those red flags that one usually should be aware of? Just avoid… I don’t know, deterioration, I guess, of a design system in the company.
Ben: Yeah. There are definitely seasons. I think folks go through where they feel like, “Hey, we’ve got things figured out. We have a good groove. We’re following our processes. Everything’s good.” I think one of the things that we’ve seen is that, like any other product, there is a level of stability you have to aspire to as well. And the same challenges that we’re used to solving for our externally facing products are also going to be the reality for us with an internal product, like a design system.
Ben: And that’s when things change around. And so many times we’ve come into work with an organization where they felt they had a great program running and leadership changed, like a new director comes in, or a new VP comes in. And they have a very different perspectives on how to approach the work. And they haven’t been there for the journey that you have been on. And so, all of a sudden, you’re thrust into this instability where you have to, again, prove that you’re a valuable part of the organization and the process you have to show.
Ben: Sometimes, this is where the metrics come in, where you have to not just tell them which you have to actually show them. And so that’s one tiny example, but shifts in the market, right? Pivoting a product like a rebrand, all of these kinds of things can impact that. What feels like that stability? And so we try to think about… We’ve done a bunch of work to try to figure out what are the things that we can have in place in the seasons where things are feeling good. How do we make sure we’re creating more stability that will actually help our system last through those kinds of changes?
Ben: And there’s three big things we’ve identified. The first is authority, which is that real visible support from leadership. The second is value, which is that you’re continuously monitoring the product you’re offering. The design system itself is actually valuable to the folks you’re asking to use it; that’s engagement, right? You have to be making sure that it’s doing something helpful for you… It has to be the easiest way to work, and then tradition is the third.
Ben: And that’s a little bit different in that you earn that over time, right? Having authority and being valuable over time, you become the way an organization builds interfaces. And that tradition of this is how we work. Actually is quite a stabilizing force in the context of a lot of change. So those are the three things we help our customers put in place in order to create systems that last beyond just those seasons of feeling like we’ve got it figured out.
Vitaly: Right. But I also think the underlying asset behind all of that is something that we spoke about in Berlin when you were here. I remember that cup of coffee. That was a very nice cup of coffee.
Ben: Yeah. That was good.
Vitaly: And also very nice conversation that we had back then. And we were talking about culture.
Ben: Yeah.
Vitaly: We’re talking specifically about… For all of this to succeed, we need to have proper culture and companies and organizations that not only support and enable a design system but also have a little bit of a design system sprinkled pretty much everywhere in the organization. So maybe you could share a bit more on that because I know that you spent quite a bit of time working around design systems and culture.
Ben: Yeah. Yeah. This is what I’ve been working on most recently. And I’m so excited about it. I think I have learned a bit from a couple of our engagements with clients where… Any place where people are getting together consistently, a culture is formed. So that means if you work at a big company, there’s an organizational culture that is created from all of these folks coming together to work on a thing. But also, each day, you’re probably not interacting with every employee.
Ben: And so, your small team that you interact with on a daily basis will form a subculture that exists inside of that larger organization’s culture. And there are probably hundreds or thousands of subcultures inside big organizations, right? The group of folks who get together on Zoom and knit over lunch, there’s going to be a subculture formed there, right? The book club where they’re reading about whatever science fiction book just came out.
Vitaly: Well, I love a Good Book Club.
Ben: Yeah. See, there’s a subculture being formed there, right? I have been doing a bunch of research by just reading papers from the last few decades of other folks much smarter than I who have been researching organizational culture. And I’ve been looking at that because I feel like there’s a missing piece in what we’re talking about with design systems. And that’s an observation that I’ve made just in our work.
Ben: And one of the things that I think is helping us to frame that challenge up a little better is understanding the different types of cultures that can exist. And there’s lots of material on this. There’s a model that I love. That’s, I think, from the late or early ’90s, which is called the competing values framework. And I’ll send you a link that at least you can share in the show notes, but—
Vitaly: Absolutely.
Ben: … it’s really nice. And it just takes two ideas on a spectrum X and Y. And it gives you four high-level general types of cultures that can exist in an organization. And one of the things that I’ve learned is in my interviews, almost every single one of our design system teams that I’ve talked to is on the left side of this diagram, which means they’re internally oriented. So they’re either collaborative or they’re controlling. Those are the two culture types that are the most common for a design system team.
Ben: And that makes sense, right? A collaborative approach is when you’re saying, “Hey, everybody come help me do this.” And together we’ll build something that we can all use. That’s very common. And then controlling is a little different. And that’s we’re saying, “Hey, this design system is in place to ensure that the output is consistent.” And so you cannot veer from this. It’s more like us being restrictive.
Vitaly: Like a strict guideline that we need to stick to, right? Mm-hmm.
Ben: That’s right. So those are the two… This is very general, but those are the two general ideas of cultures that exist really in design system teams, but there are two others, and those are more externally oriented. And one of those is competitive, which is about being driven by the market, and the other is more entrepreneurial and it’s creative, it’s called. And these are folks who are just trying to disrupt stuff. And so, with these four ideas, what I’ve learned is some of these cultures work well together, and some of them don’t.
Ben: And as a design system team, you don’t get to choose the culture of your organization, right? You are going to be a subculture. And so what we’re learning now is there’s a lot of nuance in being smart about how to structure the culture, how to curate the culture of your design system team in a way that it can operate successfully inside the larger organization’s culture.
Ben: And that’s a lot of the work that I’ve been doing. And I’m real. I just feel like there’s so much to this. I have a lot more research to do, but it’s already starting to show a lot of value in our consulting work, so-
Vitaly: Yeah. Yeah. That makes sense. Because once you have an organization that already has a culture in place, you probably can’t change that, but you might change the way how your design system would operate in that environment to make the best out of that.
Ben: That’s right.
Vitaly: Well, I hope that at some point you will be, I don’t know, writing articles, maybe even books about this.
Ben: Yes.
Vitaly: Either hear something, a rumor about an upcoming book on just that eventually.
Ben: That’s the plan. Yeah. Trying to put something together that has these three big concepts, the anatomy of a system. So actually getting some nuts and bolts about being very clear and articulate about what a system is? Understanding how systems mature, as we’ve already spoken about, and then recognizing the impact of an organization’s culture on the design system team and how we can structure that in a way that it’s successful? So those kinds of the big—
Vitaly: Any deadlines that you’ve put yourself in your calendar?
Ben: I’m hoping to have my draft done this year. And then from there, that the whole process of editing and all of it, so-
Vitaly: Yeah. I even know a publisher who might be interested in publishing at some point-
Ben: Oh, yeah.
Vitaly: … who knows you.
Ben: Yeah. Give me their name.
Vitaly: Yeah, I will, I will maybe let’s just spend a bit more time thinking more hands-on about what are some of the things that designers developers working in organizations, working in companies on a design system? What can they do to make things a bit better for the process, for collaboration, for the workflow, for everything?
Vitaly: Let’s start maybe just by you briefly maybe highlighting, how do you start the kickoff projects when it comes to design systems with your clients? What do you usually start with? Obviously, there is going to be some research involved and all, but what would be the initial steps to get to a solid foundation early on?
Ben: Yeah, you’re right. It is research. We call this phase onboarding at Sparkbox and what we try to recognize is that those early days of an engagement like that, or the days when you know the least, right? And so we try to embrace the idea that we’re going to know a little bit more tomorrow than we did today. And we try to be very iterative. I think those early days for us are oftentimes about building relationships with the folks inside the organization.
Ben: And we do often ask to be introduced to lots and lots of people, even if we’re not going to work with them daily in the design system work. We still need to know what they’re dealing with? What they’re going through? How are they accomplishing their tasks each day? What are their goals? And what we’re trying to do is I think, model for our clients that you cannot do design system work effectively unless you really truly understand the needs of your users, your subscribers.
Ben: And so that is where we start. And so it’s about… We do that in a lot of different ways. So we may run a small internal survey and send that to lots and lots of people. We may schedule three to five interviews with each discipline. And one of the things that’s a little bit of a pet peeve of mine is that we talk so much about how a design system can benefit a designer or a developer, but we ignore a lot of other disciplines.
Ben: And so one of the things that we’re intentional about is making sure we’re not only speaking to the designers and the developers but also let’s talk to some folks in QA, let’s talk to the product owners. So let’s talk to UX research folks. I think the system should be broad in its goal of serving lots of different disciplines. And so the only way that we can do that is if we understand the needs of all of those folks so that’s how we get rolling.
Vitaly: Right. And then, as time progresses in terms of collaboration, let’s say between designers and developers, right? It’s still always a topic handoff or no handoff. Den Mole and Brett Frost are speaking about the hot potato model as we throw.
Ben: Yeah.
Vitaly: The stuff from designer to developer, from developer to designer, it’s all alternative. And there is no notion of a handoff because it’s just happening all the time in small bits and pieces. What do you see working? Or do you see it working best or maybe not working well at all?
Ben: Yeah, it’s funny there. This is a spectrum; there are so many organizations that are more iterative in that way. There are a lot of organizations out there that are still very linear, and I definitely fall more in the camp of iteration where we believe, but I talk with our team a lot about this idea of empathy. And I’m not talking about empathy for our end users. I’m talking about empathy for the other disciplines that we have to work alongside.
Ben: And I think that is key to doing this work well, is understanding that every decision you make, say you’re a developer, every line of code that you write to build an interface has an impact on the visual side of the things, right? So, and the experience for the end customer. So recognizing that all of our decisions are interplaying with each other, I think, is necessary. And that’s where building relationships with those people is the way that you can do better work.
Ben: So we encourage that. And that’s why I love design systems because it forces all of us onto the same team instead of us thinking about, “Oh, I’m on this products team.” No, we’re actually all trying to build stuff that better serves our end customers, right? And the one way we can do that is with a system.
Vitaly: Right. And when it comes to… Let’s say those little fine little details; for example, many teams will be working with storybook on the coding side of things and then Figma on the design side of things. How do we then, the ultimate, the billion dollar question from me to you? Ben, of course, how do you breach that gap? Will tools save us? Will processes save us workflows, Slack channels? I don’t know. You give me an answer, Ben. I don’t know.
Ben: Yeah. I definitely don’t think tools are going to save us. I get asked a lot about tools because right now, especially with design system stuff, there are so many tools coming on the market, and every tool that’s out there is investing heavily in offering better and better services. And that’s great. We need that innovation happening in the space for sure. And I’m not saying you shouldn’t use tools, of course, but I don’t think tools will save us.
Ben: I think it’s… So in our anatomy of a design system model, we talk about every layer of the system consisting of three different parts. And those are, of course, the assets, which are the things everybody thinks about, the files, the components and react, the Figma designs, all of it. But those are important, right? But also, we talk about documentation, which is like a major piece, which is offering a really actual, insightful explanation of what a component is or what a token is. Or whatever the thing you’re documenting.
Ben: Of also, why is it important? Why is it that way? And, and then we also talk about the process as a key part of that, of this for each layer. And this is, I think I had to say what will save us; I think being intentional and thinking through the actual process that you’re going to follow and being clear about what it is and how to follow it is the way that we’re able to set these different disciplines up for success. In the example you said, designer developer, like one of the common things that one of the biggest challenges we see is that folks don’t trust the design system because the version of it that a designer used is no longer in sync with the version of it that a developer is going to use.
Ben: And that’s a problem, right? Because now, all of a sudden, I’m going to… The next time when I come around, I go through the process thinking that it’s in sync, and at the end, I realize, “Oh my gosh, I used the design system as a developer. And now, the output is different than what my designer designed. That’s a problem. I’m not going to want to use the system anymore because that issue means I have to go redo stuff, right? So that actually has taken away any efficiencies that we might have gained by having a design system because I’ve just created a bunch of rework for myself.
Ben: So the solution to that, there’s two big things, right? One is defining a process to keep these things in sync and just being clear about what that is. And the other is transparency about the current state of each piece of a system. So now, I can choose as a developer to use the system. I know if there’s transparency, and I know that it’s not quite in sync with what the designer used. That just means, oh, I might have a little bit of iteration to do on it, but I haven’t gone through expecting it to be perfect at the end so that transparency creates trust.
Ben: And the process is the way that you can say, “Hey, we know things will, at some point, become synchronized, you can choose to wait until that’s done, or you can go now and maybe help us create the synchronization.” So I think those are the two things that’s just one example, but it’s a balance, right? Of the way that we work with each other and the tools offering some of that automatically. And then when they don’t putting the process in place to do it manually, so-
Vitaly: Right, absolutely. Well, that sounds very exciting. Well, I do have to ask one more thing, Ben; as we’re wrapping up slowly, I know that you’ve been working on so many different projects with so many different companies, so many different brands, and so many different designs systems across. I don’t know how many companies and brands, at this point, do you still have a dream project that you would love to be working on one day? I don’t know, maybe it could be a design system for a big brand, or maybe it could be anything else.
Vitaly: I know that you know, you are a big audio guy, right? So you have been spending quite a bit of time with audio and as not your engineer as well, and you have so many other things that are really interesting to you, and during the conversation that we had back in Berlin, I just realized just how broad your interests really are. So if you could do anything, any big project that you would like to take on, what would it be?
Ben: Oh my goodness. Yeah. I think it’s not, for me, it’s not about the size of a company or the brand awareness, that kind of thing. I mean, we have worked with some big organizations, and that’s always fun to… When you’re talking with your family later to be like, “Oh, you went to that website; we helped build that.” That’s always a fun moment, but I think for me, it’s always been about impact.
Ben: So if there was a way to help organizations actually create that unity on their teams, that’s the thing that really is driving me at the moment. So, the idea of a book, I think, is a way to put that together and actually see folks grow from it and make better decisions within their daily work.
Ben: That’s pretty exciting to me. The other one, I think, is just that I really enjoy teaching and working with folks. And so, I think at some point in my future, I probably will find a way to give back in that way. And that’s pretty exciting for me to think about. So there’s a couple.
Vitaly: That sounds great. That’s great. So dear friends, we’ve been learning quite a bit about design systems this episode, but I’m still wondering, what have you been learning about lately, Ben, that might not be related to design systems or might be related to design systems? What keeps you busy these days? What keeps on a toast?
Ben: Yeah, that’s fun. My son is at a camp this week, and he is studying VR gaming. He’s learning how to make VR games. And so, he and I have a lot of fun. He’s learning to program as well. And so my computer science background gets me back into some code, goofing around with him. So there’s some stuff I’m learning there. I’m always learning about coffee. You can probably see some of my coffee equipment here. So I have a couple of new toys that I’m playing with within the coffee world too always, so-
Vitaly: That sounds great. So do you think we should be expecting you to become a VR developer or VR engineer or barista anytime soon?
Ben: Yes. That’s definitely. I’ll be a barista probably in the near future if nothing else works out.
Vitaly: Right. Well, that sounds about right. If you, dear listener, would like to hear more from Ben, you can find him on Twitter, where he’s @bencallahan, and will obviously post the link to it in the episode notes and also on his website @bencallahan.com. That’s not very surprising, or I would say, but you also can find him @sparkbox.com, where the wonderful sparkling Sparkboxers. Is that the right way of saying that?
Ben: That’s what we say. Sparkboxers. Yeah.
Vitaly: Spark boxers are doing all the incredible job on design systems and beyond. So thank you so much for joining us, Ben. It was a pleasure and fun as always.
Ben: Yeah.
Vitaly: Any parting words of wisdom streaming to the internet out there as an Internet Explorer?
Ben: Oh my gosh. Internet Explorer. No. Well, go check out the second draft of the tokens spec that’s coming out. There’s a lot of feedback needed there if you’re into that space, so that would be a thing. I would encourage folks to go read.
(il)