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:01)
Hello everybody. My name is Ben Callahan. I'm your host for The Question and I am joined today by my co-host Hannah, is to help us discuss this idea of building design system infrastructure lasts. And we just finished up the deep dive and are sitting down now to have this conversation, the recap conversation for episode 70. Hannah, thank you so much for being here and for spending some time with me.
Hannah Clarke (00:28)
Thanks for having me.
Ben Callahan (00:29)
Yeah, I'm super excited. And I also just want to say thank you to Mintlify who sponsored this episode. Mintlify is the intelligent knowledge platform. They're offering us a nice discount for members of the question community. You can get 50 % off your pro plan for six months by using the code MINT-THEQ So check out Mintlify and there's more information on that deal over in the FigJam file wherever you're listening to or watching this.
⁓ I had so much fun this episode there was like it sort of went in unexpected directions I think which which makes it kind of fun. ⁓ We asked four questions we said we have two that were a little bit more quantitative and we gave folks some choices. ⁓ The first one was which of these statements best describes your company led by engineering led by product led by design or led by a balance of those. Then we asked.
Hannah Clarke (01:01)
Yeah.
Ben Callahan (01:20)
on your design system team, which roles have at least one dedicated person? And we gave them choices to check DevOps, design ops, UI design, front end dev. And then we asked two more qualitative questions that just had open text answers. The first was, who has responsibility over the delivery of your coded components? And the second was, what do you believe are the most important actions a design system team can take to create a system that lasts?
We sent this out to 1,061 design system practitioners. We got 45 responses. And as always, wherever you're listening you can find the link to see the raw data yourself and do your own evaluation. I think we came to this first question with sort of different expectations. Hannah, tell us what you were looking to see from this.
Hannah Clarke (02:04)
Yeah.
I mean, I think the fact that led by product was the most popular response that didn't surprise me. ⁓ I think probably because of my previous experience in the companies that I've worked in, where it has quite often been products like leading the decisions for the direction of what's being built, what's being designed. And then, you know, causing engineering teams to have to pivot when they change their minds about things like I don't think I was particularly surprised by that. But I know that you were.
Ben Callahan (02:35)
I was, I think I've just worked with a lot of organizations that are engineering led. And so that just biased my thinking, you know? ⁓ And a lot of times those organizations, you know, the system itself may not live inside of the engineering org, but they are constrained by the views held by somebody like a CTO, you know? ⁓ And so...
in that world, is again, this is speaking very generally, but in that world, there's a lot of pressure to move fast, you know, and the amount of time I think that it takes to sort of raise the quality bar of design through a program like a system program is often not respected, you know, in that that in that world. So
is a challenge I think I spend a lot of my energy helping teams sort of work through. ⁓ So the thing that shocked me the most though was the low number of led by design. mean, good grief. Yeah, just almost nobody, you know, and I don't know, how do you interpret that?
Hannah Clarke (03:31)
Yeah.
I mean, I do wonder if people are saying that it's led by product and not led by design, who's doing things like user research? Is that responsibility within product rather than within design? ⁓ Hopefully someone's doing user research. And I wonder if it's less of the division by role rather than division by responsibility, I suppose. ⁓
Ben Callahan (03:55)
Yeah.
Yeah.
Hannah Clarke (04:07)
Otherwise, yeah, if the design isn't at the forefront, then what are you providing your users really? Like, that's kind of key.
Ben Callahan (04:14)
Yeah.
Yeah, it really is. I do think it's, it's, you know, it's been slow to see organizations acknowledge the criticality of design at the highest levels of the org, you know, like chief design officers are certainly not as common as, you know, chief product or chief technology officers. Right. So I think in a sense, even organizations that value design, if they haven't elevated it to that level, it just has an impact on the culture, you know, so.
Hannah Clarke (04:46)
Yeah,
yeah, for sure.
Ben Callahan (04:47)
You know, maybe that's
maybe that's what we're seeing here. ⁓ There were quite a few folks who answered other as well on this, and I put a summary of those in the FigGem file. So if you want to see some of that of that summarization of the other answers that the high level there is a lot of those are folks that are on very, very small teams. You know, ⁓ it's a small organization. Maybe there's one or two people.
like kind of part-time helping on systems. And so I think for those folks, it's harder to make a decision. You everybody's pretty scrappy at a small size, you know. The second one more quantitative was around the roles that folks have. And I think the thing that both of us were shocked to see was the overwhelmingly that most teams have front end developers even more than they have designers, which blew me away.
Hannah Clarke (05:35)
Yeah. Yeah, I mean, and I think it came up as well in some of the conversations we had about the number of roles that are available in different areas. And when I was looking for my current role, I was not finding a lot of developer roles within a design system team. Like they seem to be few and far between, but tons in design. So this is really interesting that there are more teams with front end developers than there are with designers in them. Like I did not expect that at all. In my experience, it tends to be
Ben Callahan (05:54)
Yeah.
Hannah Clarke (06:04)
front end developers are borrowed from other teams by a design system team rather than actually being an integral part of it.
Ben Callahan (06:10)
Yeah, yeah, I've definitely seen that model quite a bit. It's funny because Sean Bent, who used to run engineering for the Spotify design system was on the call and he recently wrote a post about.
how he sees exactly what we were just talking about how so many of the roles that are available for systems teams are are focused on design. ⁓ And so I you know he wrote about that I think others have felt like hey that's not what we're seeing so maybe it's just sort of like a little bit biased by who's in our communities and the things that we see you know in those feeds that we're living by these days. ⁓
Hannah Clarke (06:26)
Yeah.
Ben Callahan (06:49)
And the idea of borrowing front-enders, know, I think this got into, think Kelly had a really interesting observation, you know, that she's also, you know, looking around for a new role and in looking at those job descriptions, she's just seeing the need for like basically people who are amazing unicorns that can do all of it. And so, you know, this is a common problem. Of course, organizations are going to say they want somebody who's a magician in that way, but.
Hannah Clarke (07:07)
Yeah.
Ben Callahan (07:14)
We all know the reality of that. It's really, really hard to find those folks if they even exist.
Hannah Clarke (07:19)
Yeah.
Ben Callahan (07:20)
Yeah, and it's an interesting transition for us in this conversation, because I remember as we were talking through some of this unicorn stuff, we had a great conversation Greg led around this idea of, you know,
organizations sort of asking for that unicorn person. And ⁓ as an individual who has some of those skills in both sides, you know, he's primarily a designer, but has learned to code. He was saying, I don't want to be a full time developer. You know, like I want to use my code knowledge to do my design job better. Right. So I love that sentiment. I think that's a quote that you called out afterwards. ⁓ Is this something that resonates with you? Do you have that sort of leaning? You can do a little design, but you consider yourself an engineer or.
Hannah Clarke (08:01)
I think
I would never say that I could do design. I think I can appreciate what is good design and I think that's what makes me a good front-end developer. I have an attention to detail. can build something pixel perfect. I would not want to be... I don't have the specialism and I wouldn't presume to think that I could just do that because, ⁓ you I work in front-end, therefore I should be... It's a whole different skill set and I think there is...
I think it's dangerous to devalue people's specialisms like that and say that everybody should be a generalist. But from both sides, really, I think it's great that there are far more designers now who understand code because I think when you're building components and you're particularly in Figma where you're sort of naming things, if you understand how the code works, then you can build components that are more code friendly for the developers who are using them. And I think that just makes us all better collaborators.
But I think it's really dangerous to say, you know enough of this, therefore you can go and do it as part of your job. I think it really devalues people who are very good at those things.
Ben Callahan (09:08)
That's so true. I think this quote from Greg really does a nice job of sort of summarizing what I think you and I both believe, which is having empathy for those roles, having empathy for the challenges that are required to do great design or great UX thinking makes me better as a front end developer. So I think that's a fair way to think about it. I love that.
It's interesting when we were chatting before the deep dive, you called out this quote, ⁓ which was one of the responses to question four, which was about, you know, tell us what are the things you can do to create a more system that lasts. And somebody mentioned community here. They said connecting people that ask about the system, right? Tools will keep changing over time, but people will keep interest alive. I love that statement. You were drawn to it as well. What about that?
Hannah Clarke (09:57)
Yeah.
Ben Callahan (10:00)
kind of stood out to you.
Hannah Clarke (10:02)
Yeah, I think, I think because we spend so much time really thinking about the tooling and particularly me personally, you know, my job mostly these days is, is infrastructure management and DevOps, which is bizarre ⁓ for the front ender, but it's very easy to get bogged down in the kind of technical tooling and, and, you know, what tools we're using and is it the right one and, and doing all of these things to build the resources, but
ultimately if you haven't built the community around the design system and you haven't put as much thought and importance on that, then you can have the best tools in the world and if no one's aware of it they're not going to use it. So what would be the point? I think building that community is just as fundamental when you're thinking about design system infrastructure because those are the people who are going to advocate for using it to other people as well and they're the ones who are going to
Ben Callahan (10:43)
Yeah.
Hannah Clarke (10:56)
contribute back and give you feedback and actually they're the ones who are benefiting from it. So they have to be brought in at that fundamental stage as well and considered part of the foundations.
Ben Callahan (11:08)
was having a conversation with some consulting peers of mine on a, on a project and the phrase human infrastructure came up in our conversation. And I think it's like, how do we create that human infrastructure, a network of individuals that care, that have shared values to sort of go coincide with the technical infrastructures we're building. ⁓ I love that. And I think there's a lot to unpack there. We need to, we need to keep figuring that out. when we looked back at the data after having
Hannah Clarke (11:14)
Okay.
Yeah.
Ben Callahan (11:36)
after you called that quote out, I went and just quickly took a peek and it looks like over 60 % of the responses to question four mentioned humans, people, community, champions, trust, those kinds of things. So even in a systems conversation like this, it's very technical about infrastructure and delivery of coded components. The humans are still coming to the forefront, you know.
Hannah Clarke (11:44)
Yeah.
Mm-hmm.
Yeah, I think as well that also taps into a conversation we had about developers wanting specific frameworks. I think like I was really naive when I first kind of did the web components research and was like, this is going to work. This is great because I just assumed that I solved the technical problem and therefore I'd solve the problem, right? But what I didn't appreciate was the fact that I was going to have to go and talk to a bunch of developers who
Ben Callahan (12:22)
Ha ha.
Hannah Clarke (12:29)
we're very reluctant to do anything different to what they've been doing. And it's just as crucial as solving that technical hurdle is then actually getting the people who are going to use it on board with what you're doing.
Ben Callahan (12:43)
Oh my goodness. It's the cultural side of our work. You know, it's like shifting the things people want to do, not just giving them the tools to work differently. And so let's set this up with the data, right? So in the answers, we, there were three quotes that I pulled out. Um, one was from one of your teammates, but they were all around this idea of like, let's try to make the system as framework agnostic as possible, you know? Um, and so that came through in, you know, implementation agnostic foundations or
Hannah Clarke (12:46)
Yeah.
Ben Callahan (13:13)
⁓ application being platform or application agnostic, right? So the idea of saying, hey, let's build something that can work across platforms, across frameworks.
And a counterpoint to that was Joanna, who said, we've built our system into frameworks versus the framework agnostic approach. And she said, they had ⁓ a big team of React folks and a smaller group of folks who needed to use Angular for whatever reasons. And those folks using those tools said, hey, if you build this with web components, we're not going to get the features we need, the native to React, native to Angular features we need. And so I'm just curious for you.
Hannah, as you went through that research and made choices to, and we could talk about your decisions around a framework agnostic approach, but like, was this a conversation you ended up having? Like, have you had to deal with this kind of conversation?
Hannah Clarke (14:08)
Yeah. And it was really challenging because, you know, we, we had this kind of this longevity idea, this sort of bigger picture sustainability idea in mind when we were coming up with all of these choices and we didn't want to end up building something that would be out of date in two years because we'd picked a specific framework and, know, it wasn't going to hold up long-term. And so when we'd made these choices, we were like, well, this is the right thing to do. But then.
trying to have those conversations with developers where they were like, it's not going to do exactly what we need it to do. That was a really big challenge. you know, with one of the teams, we didn't really ever get past it because I think if you've got people who are very kind of, they're very focused on how they want things to be, and they're not willing to budge, it's always going to be a difficult ask. So I can see why there are teams who just kind of gave in and didn't.
couldn't do anything different because you also want people to use the thing that you've built. You know, we went against it. We carried on because we knew that it was right for the system and we crossed our fingers because we have a lot of product teams and we just hoped that it would work out okay because we knew it was the right decision. But it was a massive gamble. And you know, we've got other product teams now who are using our packages and our React components and they are, they're so great and they are advocating for what we're doing. But at the end of the day, like,
had all of our teams turn around and said, you know, we're not using this. It doesn't matter if we'd built for longevity with no one's using it, then it doesn't even exist to begin with.
Ben Callahan (15:43)
Yeah, gosh. And talk to me a little bit. in the deep dive, you gave us a nice pic. You painted a nice picture of sort of your approach to delivering components. So with all of this as context, tell us a little bit about where you landed and how you're actually delivering them.
Hannah Clarke (15:59)
Yeah, so we did a lot of research when we started out because we kind of were lucky enough to start with something of a blank slate, which gave us a lot of flexibility to decide how to deliver components to our teams. So I did a lot of research when I first started at InTap into web components and whether that was the right thing for us. And so we ended up using Stencil. There are a number of different, they're not frameworks, guess, kind of libraries you can use with web components to kind of make.
development easier and Stencil worked best for us. So we build our components as web components. Stencil kind of has this built-in React output target functionality to generate React components. And then we've also then added in something separate to do. So we've got a separate React 18 and React 19 SSL package. So now we can provide, we have NPM packages for tokens, styles, web components.
React components and React 19 with Next.js SSR support. So our teams can kind of use whichever of those they need, whichever suits their requirements. Some teams just use styles. Some teams use all the the actual components. It kind of, it's all there to fit what they need basically.
Ben Callahan (17:15)
Do you have teams that are just pulling in tokens and using those to kind of build their own, ⁓ you know, UIs or?
Hannah Clarke (17:23)
We were looking at this recently actually because we thought that maybe we did, but actually the data shows that the teams are not, when they say that they're using tokens, they're actually using our styles package. So yeah, we had thought that we did have teams who were just using the tokens and nothing else, but I think they are actually using the styles. So not quite, but you know, it's there and available should they want to do that and should it be the right thing for them to do.
Our mobile team use our tokens actually because we can't really provide much else for them at the moment.
Ben Callahan (17:58)
Yeah. So the styles package is that like a big CSS file basically? Okay.
Hannah Clarke (18:04)
It's a lot of different CSS files.
We have individual ones for components. If they've built their own button, they can use our button CSS. But then we also have our kind of base styles as well. ⁓ We're just getting into theming, so we'll have dark mode, light mode in there and everything as well.
Ben Callahan (18:09)
Mm, okay.
Nice, very cool. And so what a nice ⁓ approach that you've taken that sort of gets you a whole lot with a small team. And I know we talked a little bit about some of the automation there of like being able to generate stuff for different versions of React and some server-side rendering libraries as well. ⁓ You also have talked a little bit about some of the additional script stuff that happens when you do one of these builds. Can you talk a little bit about what's going on there?
Hannah Clarke (18:49)
Yeah, so I think it was one of the issues that I think, I can't remember who mentioned it, but sort of what they got from using web components and putting a React app around it didn't suit what their teams wanted. And we ran into the same problem, you know, just running the kind of the basic stencil ⁓ function didn't immediately give us the perfect React component. So...
I ended up writing a lot of kind of post-processing scripting on top of that. A few things were just kind of like nice quality of life things like moving stuff into specific component directories, not just having like everything in one massive directory. But then also adding things like a standalone types file, doing things like pulling through default values. So we would get the default values working in web components, but that wasn't then translating through to React. So the script was pulling those out.
and then adding them in as a fallback if a prop value wasn't passed in for where there were defaults needed. And just generally adding things like, you know, when we had required props, that wasn't always translating through to React and just making sure that those things worked as we'd want them to. ⁓ And generally kind of them as good as possible for our React developers so they couldn't turn around and say, well, you we don't get any of this stuff, so we're not going to bother using it. ⁓ Anything that we noticed was missing.
Ben Callahan (20:11)
Hmm.
Hannah Clarke (20:13)
went in the script and it does a lot of work now. It's got a bit out of hand and I've had to split it out into a lot of separate files, but you know, it's working and it's useful to be able to have that control over it as well.
Ben Callahan (20:26)
Yeah, that's so nice. And you're consuming engineering teams are lucky to have a system team that's that nuanced, you know, like thinking about those things. makes this much, it makes adoption much more ⁓ an easier choice, I think for teams when you take that care, you know.
Hannah Clarke (20:43)
Yeah,
I think we kind of realized that we had to as well. you know, if we wanted our teams to even consider adopting anything from the coded side of the design system, we had to make it as painless as possible for them. So we were very aware of the fact that, you know, it felt like we were asking them to do more.
when they didn't want to do it, despite knowing like, it's the kind of thing where it's like, it'll benefit you in the long run, but you're not going to see it now. So we had to kind of make it as easy as possible. So they wouldn't just say, no, we're not doing it. It's not, it's too much for us to take it on.
Ben Callahan (21:12)
Yeah. Yeah.
Did they, when you started getting teams to adopt the ⁓ stencil generated versions of components, was that a big lift for them? Because they were already, there was already stuff available to them in React. Is that fair? Is that right? Or?
Hannah Clarke (21:38)
⁓ The team who'd originally started the design system was a product team and they had some components in React in there. ⁓ The team that we work with mainly at the moment, ⁓ it's a really nice kind of collaborative relationship we have with them where they're doing a lot of work on different things and they'll come to us and say, do you have this component? We're looking at adding it in. ⁓ And they were using Material UI.
Ben Callahan (21:47)
Mm-hmm.
Hannah Clarke (22:08)
So they've been kind of really used to that. And there were some things where they were like, well, actually material works better for this, but we also want to use the design system. And I think having those conversations where it's like, you don't have to take everything that we're offering, like, you know, making that distinction between like, well, you you have very specific requirements for this component. And that kind of makes it not really useful to have it in the design system in this way.
Ben Callahan (22:37)
Right.
Hannah Clarke (22:37)
you do what you need to do and we'll provide you with the things that, you know, that are kind of a bit more generic that you need all over the place. And so like, think when we had those sort of discussions, that's where we could start to see the real value because, you know, we weren't, we weren't kind of holding them back by saying like, we can't make our component do this specific behavior. It was making that distinction of like, you know, this is here to work for you to try and help you with what you're doing. It's not here to...
Ben Callahan (22:44)
Yeah.
Hannah Clarke (23:07)
to kind of tie your hands behind your back and stop you trying to build what you need to build. So it's been really good to work with them and they've been really good at providing feedback on components and things as well. So it's a good working relationship. But then I think that again, it comes back to the community thing where that kind of relationship, that's what is gonna make it successful.
Ben Callahan (23:29)
That is such a refreshing posture to hear from a system team, you know, and the fact that you're in an organization that sees
that the system shouldn't have everything in it. Like that is such like a, that's like such a framing assumption that I think a lot of leadership especially has around when they invest in a system team, they think the system team will build all the components that any product team might need. And that's just not a smart way to operate. So your mentality of like, what's common? What's, what's everywhere. Let's, let's focus on that stuff. I think it's so easy and smart to do. ⁓
Hannah Clarke (24:01)
Mm-hmm.
Ben Callahan (24:07)
Pivot away from this. We spent a lot of time talking about the delivery of components, but we didn't really just talk about the bigger bucket of DevOps. Can you give us sort of your perspective? Like what is that and what does it and what should it contain?
Hannah Clarke (24:16)
Yeah.
I think in terms of what I do on the day to day, I make sure that our teams can get those packages. We ⁓ use artifactory to host our private packages across the company and we use that for hours. So I have a lot of responsibility over making sure that when we deploy the pipeline runs properly and those updates get put out there.
but we also have like storybook as well and, sort of making sure that all of that is up to date and the pipeline has run properly. A lot of it comes down to what the pipelines run properly. but also things like testing as well. ⁓ you know, the team that we're working with really closely, we've had a lot of issues or they've had a lot of issues with, ⁓ testing. and we've sort of tried to help out with that, but one of the biggest things that came out of that was making sure that teams could.
Ben Callahan (24:59)
Yeah.
Hannah Clarke (25:19)
be certain that the components we were providing them with were adequately tested. So that was kind of big for us. It's like, how do we improve visibility on this? Because we need to test our components, but then also we want to provide this reassurance to our product teams that we're doing that. Because we can say, oh, we've run tests, but they just have to take our word for it. So trying to move that into kind of a more visible
place and make it so that, yes, it's functional, but actually it provides an extra benefit in that it's providing trust and security to our teams as well. So yeah, I think there's a lot of different aspects to it, but we are essentially providing a service. So from the DevOps side of things, it's making sure that everything's working as it should do and running properly. yeah.
Ben Callahan (26:14)
Yeah.
What percentage of your time would you say Hannah is managing sort of DevOps II kind of like pipeline type stuff versus working on components? ⁓ 100%.
Hannah Clarke (26:27)
100 % of my time. I've built, since I started
at Intapp nearly two years ago, I've built one component, which was, I mean, arguably it was quite, it was a radio button. Well, radio button and radio button group, one or two components, depending on how you look at it. It was complicated. took a while, but that's all I've done. Because my focus has been on everything else, infrastructure, DevOps related.
Ben Callahan (26:36)
Okay.
Yeah.
Hannah Clarke (26:56)
So whether that's kind of upgrading our storybook so that we can get the latest features. We had to move deployment from Jenkins to Azure pipelines. getting all of that, making sure that I was maintaining both though, because we were using two different artifactory like resources at that point, we were moving from one to the other, but I had to maintain the old one because some of our teams hadn't moved yet. So keeping that in mind, I'm currently like working on developing.
Ben Callahan (27:13)
issues.
Yeah.
Hannah Clarke (27:23)
an AI chatbot integration to bring all of our different documentation sources together. I don't build components. I thought this would be my job. I thought it would be building components and I've, yeah, I don't do that, which is interesting for UI engineer.
Ben Callahan (27:31)
Yeah. Yeah.
Yeah,
that's incredible. And what an amazing opportunity to sort of broaden your expertise, though, you ⁓ like we were saying earlier, you know, like a deep understanding of these other specializations will make you better at anything, really, in the scope of our work. So that's really cool.
Hannah Clarke (27:47)
Yeah.
Yeah.
Ben Callahan (28:00)
Anything else on your mind, Hannah, that you want to talk about?
Hannah Clarke (28:04)
yeah. Talking about like, we talked about sort of agnostic on the development side, but the design side. ⁓ I think that's a really, really interesting area that I don't really have an answer for. ⁓ And it was really interesting. It was particularly interesting to hear what Guy...
Ben Callahan (28:11)
Mmm. Yeah.
Yeah.
Hannah Clarke (28:24)
has been doing but yeah it does kind of feel at the moment that everybody is just very much tied into Figma and there aren't alternatives but I don't know if that's sustainable and what do we do about that.
Ben Callahan (28:38)
Right. Yeah. So the context for this part of our deep dive conversation was as we were acknowledging the, the, specific episode was more focused on engineering, you know, dev assets specifically. But when we started thinking about this idea and seeing it in the answers from folks of platform or framework agnostic components that got me thinking like, Hey,
That team seems to be something we talk about a lot on the dev side, but not so much on the design side. so one of the things that I've been working with a lot of my consulting and coaching clients is this mindset shift away from them thinking so much about their design system as.
a figma file and a react component library or whatever and more that the system sort of exists absent all of that and it is this kind of concept and guy actually Sean hinted at this because at Spotify he said they treated figma as a platform so they supported four platforms figma iOS Android and web and so or react I think for them and so they had these four platforms figma was one of the platforms right and so that that to think that way means that you've you've abstracted
your system above any platform, any tooling and you maybe this is like the way I think about it is this documentation driven implementation, right? We document and we define with words, we define the thing and then we have what we need to implement in any tool in any design tool in any engineering tool. And so I don't know, you know, it's a very theoretical concept. I know there are folks ⁓ Nathan. ⁓
Hannah Clarke (30:09)
Yeah.
Ben Callahan (30:16)
Curtis is working on this. Kevin Wilden is working on this. Just folks who are saying, Hey, how do we, you know, articulate everything about a component with data, like a YAML file or a JSON file or something, right? and say like with this source of truth, we could sort of convert it to a Figma file or convert it to a pen pot file or convert it to react component or whatever, you know?
Hannah Clarke (30:39)
the Figma is a separate platform thing is really interesting. And then, you if I think about like our zero height documentation, you know, we have a section where we pull in our storybook stuff for our coded components because it has like the code examples in. And then we have a bit where we pull in the Figma designs, but it's the same thing, right? Like, you know, we're pulling in these things, but the documentation is kind of bringing everything together. It's like...
We know this is what a component is. This is what a component is in Figma. This is what a component is in React. This is what it is. So I think that's a really, it's a really useful way to look at it. And that's, I've not really heard anyone talk about it like that before. And that's, yeah, I like that as a concept.
Ben Callahan (31:23)
Yeah, really nice framing for systems work in general. I think it's it is actually coming back to our original questions here on this episode. It is a strong mindset for creating something that lasts, you know, because the frameworks will change, the tools will change. I mean, five years from now, we are not going to be using the same stuff we're using now. So so how do we make something that can last? You well, Hannah.
Hannah Clarke (31:42)
No, course. ⁓
Ben Callahan (31:48)
Amazing episode. Thank you so much for sharing all of your experience, your wisdom ⁓ for helping facilitate this conversation. I will definitely have to get you back. I really enjoyed it and just appreciate your time. Thank you.
Hannah Clarke (32:01)
Yeah, thank you so much. I've really enjoyed it. It's been great.
Ben Callahan (32:03)
Alright folks, we'll see you on the next episode. Goodbye.
I'm going to end and if you just would stay on for a moment while things upload.