Subscribe
Share
Share
Embed
The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive!
If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in!
Stay in learning mode ❤️
Ben Callahan (00:05)
Hello everybody, this is Ben Callahan, host of The Question, and I'm very excited to welcome Shimaa Hassan as my co-host for episode 69. Shimaa, thank you so much for being here.
Shimaa (00:15)
Yeah, I'm so excited. Thank you for inviting me.
Ben Callahan (00:18)
Yeah, I, you and I, we were talking about this. We met because I just reached out to you cold on LinkedIn and I was like, Hey, I like what you're saying on LinkedIn. We should be friends. And so here we are. ⁓ just a testament to don't be shy, get out and connect with folks in the space. ⁓ I love it that we've been able to sort of make something really fun happen with this episode. So in our conversations leading up to this, we were, talking about this idea of rebuilding a design system mid flight, which is something that you're experiencing.
right now in this moment. in the conversation, you know, this is our recap from that conversation, but we were, we had asked four questions of folks. We gave them a range of, for the first answer from zero to five. And that question was how many times a month do you think about throwing your design system away and starting over? And I think you said, Shimaa, that you were expecting that number to be much higher than it was. Can you say a little bit about what you were thinking there?
Shimaa (01:14)
Yeah, like with the innovation that is happening, everyone sharing their knowledge, there is new ways to architect the system. There are new Figma features that comes out, you know, every few months. So there's always a reason to start over. So I was expecting that number to be way higher. ⁓ But it's 50-50, it looks like.
Ben Callahan (01:36)
Yeah,
you're right. It pretty much played out in sort of a standard bell curve, I think a little bit lower in this two, number two spot, but most for the most part, it's pretty much a standard curve, about 46 % in the bottom half and 54 % in the top half. So very even split on that one. We gave folks three other questions that were all open text for them to answer. And so those were, if you, if you chose to start over, what's one decision you'd make differently on day one.
And then how do you keep product teams confident in a system that's actively being rebuilt underneath them? And then finally, we invited folks just to tell us a story about rebuilding a system mid-flight. And so we got a lot of really, really folks really took their time and answered ⁓ this episode. We sent this out to over a thousand folks, 1,061 design system practitioners, and we got 53 responses. And as always, wherever you're watching or listening to this, you can get the link to the raw data and do your own analysis.
So, all right, where to start? I think I actually want to start with this idea of ⁓ something that we spent a lot of time in the deep dive talking about, which was the idea of an approach to rebuilding your system is take what you currently have, fork it, and then let people continue to use the old version while you work on the new version, and then at some point in the future, give them the tools or opportunity to migrate from one to the other.
And we spent a lot of time talking about this, but as we were chatting just before this recap, what we didn't talk much about is an approach that you're taking now, which is a more iterative approach. Can you, Shimaa, just explain for us, like, how is it that you're approaching this rebuild mid-flight?
Shimaa (03:19)
Yeah, there's different ways. mean, you have to talk to your team and you don't have in the design side, you don't have to copy it exactly what the engineers is going to do on the code. So for example, for us, so we took a different approach because, you know, teams are shipping, you know, and the current version is well adopted, but it's lacking a ton of feature that we wanted to add to the new one.
So on the design side, I rebuilt it from scratch, so it's a completely new library. Maybe from the look of it, there is nothing different, but it's all re-architected, right? You know, multi-level token architecture, a new component with slots. Obviously, it's a new feature that Figma had. And then on the engineering side, they took a very different approach. They go into to be making small changes, incremental changing.
in the code, so nothing also gonna feel different to the consumers. They're just going to be getting these updates for free. And I wanna, I don't have a large design system team dedicated to this. I literally have two engineers. So we are taking it very slow. We are bland for this. With the innovation of AI that we are adopting as well, we are making this not taking six months or a year. It's only weeks. So we are, you know,
leveraging everything under our belt to make this smooth and easy as possible for consumers. So, yeah.
Ben Callahan (04:53)
Yeah, this is a I love this. Can you can you give us like more detail like pick a component or pick ⁓ like a layer in the foundations that and just walk us through like sort of kind like step by step what how you've approached it in a way that's allowed for this more iterative approach to kind of like actually be successful in the org. Can you do that?
Shimaa (05:14)
Right. So I'll tell you how I actually did it. ⁓ So because I was this kind of the architecture of the system was a new system, we are supporting white labeling, you know, multi-brand and we adding the semantic layer and component layer right in the token architecture. The current system only have primitives, ⁓ typography, spacing, color. Every designer have to remember what they used before or just
Ben Callahan (05:43)
Yeah.
Shimaa (05:43)
pick what they like, right? So what I did is that I had the entire front end code onto my machine. And that's what I used to ask a question. Where is this GRAY-900 used? ⁓ How many card components do we have today? Right? And I used another thing to ⁓ an MCB called Design System Assistant. It's extremely useful.
to be able to say, this is my current state of the system. This is how my current architecture look like. Here are my goals and the feature that I wanna support because I talked it to leadership and this is like the things that we wanna support in the new ⁓ world of this new version of the system. Tell me what is, you know, major design system do, what is the best practices? And then you just back and forth until you come to...
where the level of where you feel like, okay, this feels great. I'm gonna create this document, verbose to the team, walk them through everything, and then I'm gonna start building, right? And I'm using also, again, I'm using AI to kinda like go into the Figma and start like blah, blah, blah, blah, you know, creating things for me and make this very speedy. And then on the engineering side, because we're co-creating, so they onboard on this thinking, the direction.
They planning to take every, let's say, sizing collection and they go into to look at it in the code, implement it across the board. They're gonna take typography instead of just a primitive, they're gonna add the layer of semantic because I am not like inventing new sizes. I'm not inventing new things. I'm just abstracting layers. The migration is still. Exactly, exactly.
Ben Callahan (07:29)
You're systematizing what's already there, essentially. Yeah, gotcha. Okay,
cool.
Shimaa (07:35)
Naming things properly, so instead of like white background, it's surface small, surface medium. You know what I mean? Naming things and then adding small increments. For example, we had a lot of snowflakes around inverse tokens. If there's a black background or a brand color background, then what type of button to put is always snowflakes. So made that as a native to the system.
Ben Callahan (07:42)
Yeah, yeah.
Shimaa (08:02)
so that it's kind of like be replaced or adopted seamlessly. So this is kind of like how we are approaching it so far.
Ben Callahan (08:10)
That's interesting. And one of the folks on the deep dive brought up this idea that when they release something new, that it is sort of creating a bit of work for consuming teams. It's like a breaking change of some kind. They are also releasing some tooling that helps with those teams in the migration to sort of like resolve the break. ⁓ Are you all experimenting with that kind of thing at all too? Or is that not been a part of the approach you've taken so far?
Shimaa (08:40)
No, we try and do not make any breaking changes, right? ⁓ Like if there is an existing, let's say, a token set, like spacing that already exists, we're not going to change the names of these tokens because that's a breaking change, for example, because it's not worth it, right? So we can make like, your battle. And in terms of component design, like again, I'm trying to support what's live today, give it names.
Ben Callahan (08:43)
Hmm.
Shimaa (09:08)
put it in within the existing architecture and then adding new things to it so that I avoid that breaking change. So yeah, this is kind of like the strategy. It works for my case, but it might not work for everyone, right? So solution needs to be contextual to your company need.
Ben Callahan (09:29)
Yeah, of course. It's almost like this feels a little bit like sort of an approach to say what's a middle ground we can get to that kind of honors the existing design in our products. And then from there, maybe we can sort of do another round of evolution on the system that would enable change in the end products. Is that kind of the mentality or? Yeah.
Shimaa (09:49)
Yes, exactly. Like,
if we really wanted to remove borders from all the cards in the future, let's do it. But today, cards have border. Until everyone migrated to the new version and it's all well adopted, I feel safe making the change because it's a global change, right?
Ben Callahan (09:59)
Yeah.
Yeah,
gotcha. Interesting. that's so cool. ⁓ I love hearing how teams approach this kind of thing. It's not simple, right? Like there's a lot of moving parts and when we try to do this well, we have to make sure we're also leaving our consuming teams feeling well supported through this kind of change. So it's really critical. I like this approach. ⁓ So we talked a little bit about the multiple, we talked about the iterative approach you've taken. We did spend...
quite a bit of time in the session talking about this idea of like multiple versions of things that, this is sort of another approach. And, you know, like there were, I think Guy gave us an example where he said, Hey, we use semantic versioning. We only do a major release once a year. We do lots of minor releases and we give
We have months of planning in advance before we do something that breaks. you know, I mean, I think there's like, this is like, this to me feels like a much larger kind of like enterprise approach to ⁓ this kind of shift as opposed to a more iterative, maybe startupy kind of, you know, startup world kind of feel to the change. We also had folks who said, I do not like the idea of maintaining multiple versions, right? Like I think Liz had a whole thread in the chat that was really good where she was saying, look,
I'm a small team. It's just me and a couple people and we do not have the bandwidth to maintain multiple versions, keep those versions in sync. So we have to sort of like pick and choose where we can put our energy is kind of how I heard her saying that. Do you resonate with one of these two other options as well or are you, like how does that sit with you?
Shimaa (11:45)
Yeah, it was really interesting to hear like, yeah, different approaches to this depend on the scale. Like I love this idea of ⁓ you have a set release schedule and you are aligning your changes to that. So it's really smart. And everyone was feeling really strongly about not maintaining different version because that's really, really bad. And obviously it's hard. Like, yeah, when you have smaller team.
Ben Callahan (12:07)
Yeah, it's hard.
Shimaa (12:12)
And like even the person who was talking about this, she said I am like 50 50 design system work and product work So I cannot have space at all to maintain multiple versions to just kill the old keep the new and Everyone needs to migrate, know So yeah, absolutely. It has to be really tailored to your organization and you should not feel the need that if like we all agreed on the change Then we should all commit to it like just leaving all the version
It's creating debt for design and engineering. yeah, let's all move forward. That's what I would say.
Ben Callahan (12:48)
Yeah,
yeah, Taylor, ⁓ it kind of jumped in at one point and asked us, he kind of said, Hey, I have a poll I want to do. He said, raise your hand if you have had a formal mandated migration period from one version of a system to another. think he was trying to get at like, is this even a reality that teams have right? Like that we would build a new version somewhat in isolation from the reality of the current version. Like
you know, again, this is that branching model of like, let's start with something fresh, iterate or build this thing into something brand new, and then have a moment in time where we say, okay, migration starts now and it will end by this date. And only, I think it was like a quarter of the people raised their hands that this is something that was accessible to them, you know? So, and I don't know, I didn't look to see what the size of those orgs were, but I would bet those were larger organizations, you know, where that was an approach. ⁓
Shimaa (13:45)
Yeah.
Ben Callahan (13:45)
So I didn't
know, what did you think about this poll?
Shimaa (13:49)
Yeah, it was excellent. ⁓ It's really made a good point. No one is going to pause and do migration. Except if you like, have like, you know, 20 engineers on the design system team to do that. Nobody had the, you know, the time or the energy to stop and do migration. Like it needs to be really tailored to. ⁓
features that we want to ship today, things that make money to the company. That's why we're all here, right? You need to think about the business aspect. Everyone bossed to do migration is taking away from actually shipping work that needs to go out. So, really depend on the size of the company and the business ⁓ prioritization, basically.
Ben Callahan (14:19)
Yeah.
Yeah, it's interesting. I'm just thinking, we don't really talk about this in the deep dive, but just hearing you talk about this, I'm wondering about a model where you have, if you have sort of a reasonably sized design system team, maybe let's just say you have 10 people, right? Like that's a pretty good sized system team, right? If that's your scenario, I wonder if it would be better to have that team wholly focused on evolving the system.
and doing the education and whatnot and engaging with other teams in terms of learning what they should be building. So they're making a product that teams want. But that would be one approach, right? It's like I have a consuming team and I have a system team and the system team focuses on the system and the consuming team focuses on the product. Another model I'm just thinking about would be what if we split the system team in half and we had five people.
who are working on evolving the system. We still have the consuming teams working on products, but now we have this middle ground team that is like a little bit like split, right? Their job is implementing the system in product. And it's not full implementation, right? Because the product team needs to learn how to use the system, of course. But in scenarios where there's ⁓ a new team coming on board as a consumer or an adopter, where there's a big rollout of breaking changes.
things like this where there's a bigger impact on the consuming teams. If we had a subset of the system team that's job was to go in and like help them do this well, I wonder if that would help, know, it wouldn't even have to be a large number of folks, you know, I don't know, that's maybe something to think about.
Shimaa (16:12)
That's actually, I experienced that when I was at Square where we had 30 folks on the engineering side, multi-platform and design side. We had a team, there was a design manager that advocate for design system work. So in that situation where the company is 20,000 employees, we did have that leverage. And actually what we call it was like a rotation embed where engineers would depend on the roadmap because everything is defined in advance.
We know that we're to have capacity on the system team to support that team's implementation of the certain component or experience. So we would send out people from design or engineer, not just engineers, embed on that team for a quarter or so to help them. And we would also want other teams, consumers seem to get familiar with system work. So we would borrow engineers to come and help us.
And we did this on system design and engineering and it was really successful when you have the, you know, the manpower to do that.
Ben Callahan (17:15)
Yeah.
Yeah, that's really great. And just the empathy building that happens when you do that, you know, like consuming teams, individuals on consuming teams coming and spending time with the system team.
understanding the challenges that we face, know, and likewise, you know, the system team going out and being a part of the product, getting to know those customers better, you know, like, I mean, there's so much benefit there. I went when I've seen this kind of thing happen, this sort of like, you know, individual exchange program sort of thing, ambassador program or whatever. ⁓ One of the challenges I think is it can also be disrupting for those teams to have like, somebody new popping in just for a quarter, right? Like there's the onboarding and offboarding and all that that has to happen. And so there's
There I think there are pros and cons to that, know, but but it sounds like you had a great experience with it. So that's cool. one other thought that I had, which is we spent I feel like we spent a good amount of time talking about this idea of. Like the system is the place for standardization, not necessarily the place for innovation and.
Shimaa (18:05)
Yeah.
Ben Callahan (18:22)
I you know that's it's an interesting quote. I this is this was Taylor who kind of made that statement and I think we had some we had some back and forth on this like what's your take there. Do you agree with that statement.
Shimaa (18:33)
Yeah, absolutely. think it's really well ⁓ built because, well, my experience was rebuilding right now. I basically kind of stated the same situation where I'm trying to adopt the existing things in the system so that this is going to become standardization and everyone adopt and then we can innovate after. If the product team in the future decided they don't want the car to have XYZ,
styling or the button styling looks like this, we can do that because it's standardized within the system. So yeah, this is really true and a lot of teams to adopt this mental model, they need to change a lot because some product team that I worked with, they are expecting this new things to happen within the system team. But system team doesn't have capacity to innovate new things because product team are the one that's going to be expert in their field, in their
Consumers, we're here to serve you, not serve the consumers. You know what I mean?
Ben Callahan (19:34)
Yeah, yeah, it's interesting. I think I might tweak this statement a little bit, like if I was going to say it and not because it's wrong, but because I want I think I would avoid the negativity in it. So the system is the place for standardization, not innovation. I would maybe say the system is the place for standardization so that product teams can innovate. You know what mean? Like we give them the space to go do that, you know. ⁓
And I think both are really important and that I think that's, you know, that's a big part of what we're tasked with in the org is just like identifying the standards that sort of emerge ⁓ and encouraging folks to follow those when it makes sense. One thing I see in my coaching and consulting work is a lot of time leadership, a lot of times the leadership is sort of pushing hard for innovation. And they say that in kind of a very generic way, right? They structure how people are rewarded and, and,
evaluated in their career path on have you innovated, but it's actually, I feel a little bit dangerous to just say, hey, we're an innovative company. Everybody should be innovating because that is actually not true. If all you do is innovate, you have nothing. And so there has to be space for that innovation to be standardized. And that's what I like about Taylor's statement here. ⁓ But I think
The job of a system team is to be really clear and articulate the decision frameworks for when do you standardize and when do you innovate? That's a question that most teams don't know how to answer. Is that something you've had experience trying to figure out, like how to make that choice?
Shimaa (21:16)
Yeah, I think it comes down to really have a great relationship with your product team, right? So that they can see you as the one to go to to kind of like think about new ideas. Because like I, for example, was working with a product team on this new pattern that they want to introduce and they created a branch in the library and they put it there and like review. And I go on and I look.
everything looks amazing and yes this should be in the system but how you thought about breaking it down into reusable component it's not right right that's our job to come in and work together on things and actually this in the system we call it x and we can standardize it this way so it can be reused over there and over there like you're thinking horizontally
Ben Callahan (21:54)
Yeah.
Shimaa (22:07)
versus your product designer is thinking just within the bounds of their area, right? So this is how we can like work together to make things available to everyone and to kind of introduce that innovation within the system as we go. This is how I think about it.
Ben Callahan (22:13)
Yeah.
Yeah,
I love that. love that. Sheema, thank you so much for making space in your day and in this week to kind of help me dig into the data, help me facilitate the deep dive, and even just to have this conversation as a recap. I appreciate your time, your expertise. You've been very generous with your knowledge, and I appreciate that. Thank you.
Shimaa (22:41)
Thank you so much, Ben. I'm really excited to be here and it was a great experience. So thank you.
Ben Callahan (22:46)
Yeah, excellent.
We'll see you again soon, everybody. Thanks for listening in. Cheers.
Okay, let me stop the recording and then if you don't mind,