In our first episode of 2025, Chris Strahl sits down with Adriana Morales, Design Principal at H-E-B, to explore the evolution, challenges, and triumphs of design systems in organizations at different stages of maturity. Adriana shares her journey from IBM to H-E-B, highlighting how each company’s unique financial priorities and cultural dynamics shape the mission and execution of their design systems. Together, they discuss the paradox of design systems: balancing constraints with creativity, and ensuring they enhance rather than hinder innovation. Adriana also offers actionable strategies for celebrating small wins, sustaining engagement, and demonstrating the tangible value of design systems across teams, leaders, and executives. Tune in for an inspiring start to the new year!
Guest
Adriana Morales is a Design Principal at H-E-B based in Austin, TX, where she uses systems thinking and radical collaboration to create scalable design systems, resources, and tools to bridge the gaps between design and engineering teams and build cohesive experiences. She believes in nurturing the next generation of designers to find clarity in complexity and uncover their hidden powers.
Transcript
Chris Strahl [00:00:00]:
Hi, welcome to the Design Systems Podcast. This is the place where we explore where design, development, and product overlap. Hear from experts about their experiences and the lessons they've learned along the way, and get insights into the latest trends impacting digital product development and design systems from the people who pioneered the industry. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud.
If you want to get in touch with the show, ask some questions, or tell us what you think, send us a message over on LinkedIn. You can find a direct link to our page in the show Notes. We'd love to hear from you.
Hey everyone. Welcome to the Design Systems Podcast. This is your host, Chris Strahl. Today I'm here with Adriana Morales. She's with H E B. Adriana, why don't you say hey and introduce yourself real quick.
Adriana Morales [00:00:35]:
Of course. Hey everyone. My name is Adriana Morales. I am a design principal here at H E B. H E B is a regional based grocery store here deep in the heart of Texas and my love for design got started about 10 years ago. I was one of the first group of designers joining IBM Design back in 2015. I've been in and out of the design system space over the past couple of years, but I'm currently working with a really amazing team here at HV creating a multi-platform, multi-framework design system to support all of H E B.
Chris Strahl [00:01:08]:
Awesome. Well, and this is the I think second to last recording. We'll have the Design Systems podcast before Christmas. So this will come out in the new year. It'll probably be our first episode in the year. So happy 2025 to all our listeners. Just as a couple of quick housekeeping things before we dive into the meat and potatoes of this all, we're going to be having our next Design System Leadership Summit in Atlanta, Georgia on January 30, followed by one at the Figma offices in San Francisco on February 27. Super excited to co host with them.
If you're in the area, want to come and hang out, you can apply at Knapsack Cloud events. Back to the show, Adriana. We had a pre meeting about this that I thought was really interesting because you came so prepared with like this wonderful list of topics and the one that I think that like we hit on is a topic that we've never really chatted about before and is this idea of what happens with that design system that is at that level of maturity where it sort of almost transforms and its purpose and what it does. And I think that there's always this big burst of initial investment when a company and an organization gets excited about a design system and then there's the delivery of that. And then people kind of look around and say, like, okay, and now what? Like, we've accomplished those first set of goals. Where do we go from here? And I think just as a jumping off point, I'd love if you could describe your own journey and kind of where you're at relative to that cycle.
Adriana Morales [00:02:37]:
Of course, I've seen this cycle in two different instances. My first time working in design systems was back at IBM. Previously on your podcast you had Nick Han. Nick Han and I worked on doing a big drastic redesign of IBM Cloud where we had to create a middle layer between the carbon design system and all of the product teams that captured the specific components and patterns to IBM Cloud and all of those use cases. When we were first working on that mini design system, there was a lot of energy and investment. We spent so much time focusing on building everything, like the components, the patterns, the dockside, rallying the troops to start to adopt that design system. Once we launched Design System and people adopted those pieces, we were left in this situation where we weren't quite sure of what to do next. Like, our core mission was so focused on building everything that we weren't quite looking at what was the mountain range beyond the trails that we were following.
And it led to some moments of existentialism. What do we do next? And I think that was a really good inflection point for us to go back and do some research with our internal teams to actually understand what was it like going for them when they were adopting that design system. Like, what were some things that we may not have got into. Like, we realized there was some components and patterns that were missing. We had a lot more work to do on accessibility. So I think doing that type of inflection helps to figure out what's next. I joined HEB two years ago and that was a complete different experience than when I was at IBM, partly because with H E B we were. I was, I was brought at the very early stages of building a brand new design system for all of our external facing teams and all of our internal facing services.
Our big focus was just trying to understand how can we build things for teams. And we spent about two years building our DOC site, building all those components and patterns. And after we went through our beta release a year ago, we're moving on to our next phase, which are mobile native components. But as we've been going through that work I think we are also figuring out okay, we can only build so much. How do we sustain everything? We build to what is actually the long term focus and goals of a design system. Because right now I've been seeing a lot of just churn within the design system industry around. We spend so much time building everything. Is it busy work? What's the value in it to, to how can we just make things better for the people that we're servicing?
Chris Strahl [00:05:30]:
There's an interesting contrast between your time at IBM versus your time at HEB and I think that you know, at Carbon or when Carbon was being built it was this kind of stake in the ground, right? It was like hey, we're going to go do this thing. And the intention behind it was to go make this big open source like splash around. The idea of like this is what a design system is and why it matters. And then I think at H E B like you said to me once, every dollar that we spend on the design system is a dollar we don't spend opening the store. And I think that's a really interesting take on how a design system is viewed at a company that is ostensibly a grocer. And in that case like yes, digital products still matter to H E B but it's a very different take. Where IBM was definitely a very mission driven focus. There's now this much more purpose built thing about how do I create this efficiency inside of our organization so that we aren't going to spending a ton on digital production in order to keep up with the rest of the industry.
And that difference in focus, it feels like creates a bit of an identity crisis around what you're doing and why and give me a sense of like when you think about your time at IBM versus you think about your time at heb, that starting purpose, that foundational idea about what the system was set out to do and then ultimately what it became. And were those the same thing?
Adriana Morales [00:06:55]:
They were the same in certain ways and different in other ways. The first piece of it is the fact that IBM in of itself is over a century year old tech company. When I joined in 2015, the company was growing and drastically changing from the inside out when they brought in over 2000 designers and heavily invested in design thinking and made that the core of their practices. At the same time too, at IBM you have a company that's radically changing from the inside out, going through a cultural change to be more human centered, design focused and driven. At HCB there are some similarities with IBM where we are a 119 year old grocery store company. So we're a legacy company that has a relatively young digital org that's been around for about five to six years that is also growing a lot. We're also going through that big cultural change of how can we continue to be human centered, driven. But I think what differs H E B from a place like IBM or from other companies is one of our core values.
It's called the bold promise where we believe that people and our partners come first. And I think that's been one of our core values as a design system team where coming to heb, I didn't have to fight the good fight of getting PMs or teams to care about the users. That's heavily ingrained in our day to day operations because it's heavily ingrained in the philosophy and ethos of heb. On the design system side though, it's different. At IBM there was a baseline around design maturity because many of our designers went through design thinking boot camps, they went through different training. So we were all at the same level when it came to the type of tools and frameworks we were building. When I joined HEB two years ago, I went through a little bit of a culture shock, a good kind of culture shock though. I had a chance to work with different designers and engineers who came from different companies.
Some came from startups, some came directly from university programs. Design and engineering was all across the board between their adoption of the previous design system to teams having to essentially be really scrappy, build their own stuff. What was a big piece for me is doing that mind shift of understanding. Not every place is kind of like the first company you work at. People do things differently in order to get things done. And it's important as a design system leader to spend that time to understand how things came to be, talk with those teams and start to understand the story of how everything came together.
Chris Strahl [00:09:50]:
Right. And when you also think about that in terms of the definition of value. So the idea of what's the perception of the design system versus the reality of the value it delivers, and you talked about this a little bit too in sort of the preamble was this idea of the self examination of the value of the system is something you felt like you really had to go through. Like are we building stuff just to say that we're busy or are we building stuff that's really like generating the value that's necessary for a business? And so again is a bit of a compare and contrast. When you think about at H E B what represented real Tangible design system value versus the perception of that system inside of that organization. Did you feel like that was really well aligned or were there gaps you had to cover?
Adriana Morales [00:10:34]:
There definitely was a gap. Part of it is when you first go out and start to build a design system, you don't always quite know everything. Our design system at HEB is called the Mortar design system. We knew we needed to go out and build a design system that multiple teams could use. We have web applications to support mobile, native applications that are built on Apple iOS and hybrid apps. So we had that big north star that we were working towards. What we didn't quite realize as we were building out, the design system was more around what was the end impact for teams. We kind of had ideas, but we didn't really quite fully understand the way teams were actually working currently.
So we had to spend some time doing a series of workshops to understand how exactly the different teams on HB.com were building. Where were their gaps occurring? Because we found that components and patterns were actually a byproduct of some larger systemic issues with just designer developer relationships, teams not talking there being like foundational gaps. So what we originally went out to do is building the design system. We actually, as a design system team, we end up actually being investigators into understanding how can teams work together so that our design system team isn't a catch all for everything.
Chris Strahl [00:12:06]:
Yeah, you end up finding all these weird rough edges that you wouldn't expect in the organization.
Adriana Morales [00:12:11]:
Exactly.
Chris Strahl [00:12:11]:
And they exist everywhere. It's not like an HEB unique thing. We work with hundreds of design teams, teams, and we find them every single time. And it's because lines of reporting and communication are different, expectations are different, incentives are different. And there's fundamentally times that people just haven't ever met each other before or spent time working together. And so it takes time to build that trust and that foundational understanding together. One of the things that you're big on is this idea of systems thinking and how it ties into design systems. As you were going around the organization, sort of feeling your way around, was that one of the things that you felt was really strong inside the organization and that was like, you know, like you said, the components and patterns were a byproduct of the organization.
Was that byproduct because people were systems thinkers or was that something you really had to introduce to H E B?
Adriana Morales [00:13:04]:
That was something we had to introduce here at H E B. Going back to what I mentioned earlier in our conversation, we had designers and developers coming from different companies. We grew A lot within the past couple of years, particularly our design Org, we went from 40 designers to now we're at 92. I noticed that some partners were really thinking about the big picture, the end to end experience. For instance, if you were to go onto hp.com, there is a team that specifically manages the checkout experience, cart to home. There's another team that manages coupons, promos and savings. There are some instances two years ago where you can definitely tell that things were done in a silo because there might be one pattern that looks slightly different in the coupons page compared to the cart checkout. And one of the things that I noticed that a lot of teams were really only focused on their local experience experiences versus that broader end to end.
One of the big pieces I did when I was joining HEB and just trying to understand how people worked the company itself, I ran a series of small workshops with teams to start to capture just some basic use cases around. How are we using buttons? How are we using modals? Why are things done a certain way? And I grabbed designers from these different teams just to talk and jam and figure out these things together. And what I found really interesting but also exciting is this was oftentimes some of the designers first time working with each other, like stepping out of their teams, coming together and looking at all of this stuff from a bird's eye view versus versus at the ground level.
Chris Strahl [00:14:55]:
Yeah, I think that's a big jump for a lot of people. Right? Because traditional enterprise pretty much the world over, the place where your focus is is like in your sphere of influence, which is largely your team. And it's very rare that you think about how the thing that you're doing might impact another team. People are just trying to design a button or a card or a modal. They're not necessarily thinking about like, hey, you know, is this other team that I don't ever really talk to going to pick this up and use this? And I think that there's this idea of a blast radius of the work that you do that changes when you start to think about systems. Right. The stone you cast into the pond, those ripples go really far when that's done systematically. And I think that there's a lot of honing of craft to be done around the idea of how systems and systems thinking works inside of organizations to get people to sort of like get that bird's eye view, poke their head above the clouds and understand that the great work that they do could be so much more impactful, spread across an organization.
I think that that's a really awesome kind of take on how to get that viewpoint instilled in folks is just spend time jam sessioning with them and talk about like, hey, these are all the places that I've seen things similar to the work you're doing. Do you think the work you have in front of you right now has value to those other people?
Adriana Morales [00:16:17]:
Absolutely. I think too, when you're bringing people together to start jamming and looking at all of the pieces, not the individual parts, but all of the pieces that make up the entire mosaic of our digital experiences, I find it best to approach it with a philosophy around psychological safety. One of the big pieces that I think it's important to remember as we're doing any sort of component or pattern audit, or if you're just doing an audit of branding, is to also understand what were some of the constraints, limitations and considerations that teams are working with underneath. I think that helps to build not only more empathy towards those teams, but then also to understand how can we build a design system that enables teams to do their best work and doesn't limit or constrain them? And also looking at what are those larger cultural ways of working that might create pros and cons, and how can we share that work back with our leadership so that we can set teams up for success? I found doing those jams to be a really good way of just understanding how everyone works together.
Chris Strahl [00:17:34]:
Yeah. I mean, you've hit on one of the core paradoxes of design systems. Right. Design systems constrain creativity, but they're also necessary in order to get anything creative done.
Adriana Morales [00:17:46]:
I don't exactly want design systems to be design police. We're meant just to create some guardrails to help teams do their best work so they're not thinking about those padding and spacing. They can really focus more on solving their unique customers needs.
Chris Strahl [00:18:02]:
Yeah. And I think that you have a really kind of keen understanding of how this works inside of your organization's culture. Because when we talk about this paradox of like, hey, we need a system, but nobody ever wants to work within the system, or hey, you know, we have to get value from this approach. But, like, nobody wants to contribute to that value. Like, I think that your sort of methodology tends to be really proactive towards heading that off. And like you said, you don't want to be the police. Like, it's not an effort of compliance, it's an effort of genuine outreach and curiosity into them. And I love that idea of coming from a place of psychological safety.
Because I think very often the whole like, oh, design system introduces too many constraints into my workflow is coming from a place of fear and the ability to let people explore where they don't feel a sense of judgment about that exploration usually leads to better outcomes. So I'd love for you to just expand a little bit more on that. When you think about that way of creating psychological safety, that way of getting people to explore, the way of taking people that are ostensibly really busy and getting them to open up about something like this, how do you go about doing that?
Adriana Morales [00:19:15]:
One of the ways that my team and I have gone about this is we try to make everything as accessible and make ourselves as approachable as possible. And what I mean by that is we intentionally create multiple touch points with different teams across our different areas. Like, we, of course have design system office hours every week. We focus a lot on having each of our design team members attend our different design critiques. Whether it's as a active participant or even as an observer in those design critiques or those reviews, Those have been a really good way for us to get insight into understanding how teams are building, how they're using our mortar components and patterns. We've also created just different asynchronous channels, whether it's through Slack, whether it's through tickets and GitLab issues and things like that. So those are some of the mechanisms that we've put in place. What I've personally tried to do is embrace the energy of being a golden retriever and going directly to people.
Just treat it as something as simple as just having a coffee chat conversation to understand, hey, I saw that you had posted these designs in one of our content design review channels. I noticed that, hey, you might benefit from using this type of component or pattern. I think this might create more of just a better structure around the data you're showing. Or, hey, there's this new pattern we recently released. I try to be as approachable and just being able to show people what we have available today within our design system. So I think a part of it is embracing that golden retriever energy to bring awareness to what we have, but then also being really mindful about when it's best to be an observer versus an active participant in those type of design, design reviews or critiques. At the end of the day, we can make everything as approachable and as accessible as possible, but we also have to respect the teams that we support, and we just try to focus in on those partners that are really interested and heavily invested. In design systems, we try to incorporate those folks as like change agents around that culture of, you know, design systems are here to help support you, not be a guardrail that's blocking your creativity.
It's supposed to help enable your creativity.
Chris Strahl [00:21:50]:
Hey everyone, I'd like to take a quick break and tell you about Knapsack's leadership summits. Every month we host an exclusive in person event in different cities all around the country, bringing together design, engineering and product leaders. These summits are all about sharing our learning with tailored discussions to address the challenges you're facing. The best part, it's totally free. Head over to knapstack Cloud events to find an upcoming summit near you and apply to join us. We'd love to see you there. So a lot of what you were talking about, it's a lot of human conversation. It's a lot of time spent engaging with people and engaging with people really repetitively over a period of months or years about largely the same topic.
That sounds exhausting.
Adriana Morales [00:22:37]:
It can be, but it can also be a really great motivator and inspiring at the same time.
Chris Strahl [00:22:45]:
So talk to me more about this because I think that one of the things that I see a lot of is usually two or three years after the initial launch of a design system, you have somebody in a leadership or a product position for the design system that is like, I've had it. Like, I'm at, I'm at a point where like, I cannot explain the value of a systematic approach to one more executive. I cannot go back to the well for funding and explain why this design system matters for the 400th time. I cannot have that 700th conversation with a new designer that tells me that they don't want to use the design system because it constrains their creativity. How do you keep going in the face of all that?
Adriana Morales [00:23:26]:
I like to approach it. When I do hit that wall of oh gosh, I'm sick and tired of pushing this boulder. This boulder keeps following down the hill and it keeps crushing me to actually use that as an opportunity to self reflect both as an individual and as a larger design system team to see why are we still having this conversation? Why are people maybe not fully understanding the message we're trying to share, or maybe it's the way that we've actually been programmed, presenting that message. This was something that I've encountered both within IBM and at hcv where you can explain the value of a design system as much as you can and you can create all of the presentation decks, you can but at the end of the day, what matters and what makes the biggest difference is actually having people playing with the design system, experimenting with it. And what we found to be really helpful to help reduce the number of times we've had that conversation about what is a design system, what does it do? Why should I care? Is to actually show people how it can help improve their workflow. Like last year, two of my team members did this awesome demo where they walked through how using our design system in figma. This was also around the time that figma released Variables in dev mode, truly showing them the power and capabilities of our tokens and patterns to let teams see what it's like to actually see what a design looks like in different modes, whether it's light or dark mode or auto layout, and how it helped facilitate that much easier design to developer handoff, and how it actually helped a developer to build things more efficiently. I found getting people in a room, having them play with the things, is often the best way to help cut back on those conversations of like, why should I care?
Chris Strahl [00:25:25]:
Right? Definitely. I think that I see that a lot too, right? I mean, anybody that's listening to this podcast knows that I spend a lot of time talking to venture capitalists. And one of the things that is really hard is explaining to somebody that's never even heard of a design system, like why it matters, right? And I end up getting really honed at that 30 seconds of why. But usually the light doesn't actually like turn on until we show the product and being able to show that product and show somebody how they use it in their day to day life, that's where a lot of that magic happens. But there is still like a lot of different kinds of burnout because you have the folks that are making the system and the folks that are consuming the system and their idea of how the system should function and their fatigue with it, or ideally lack of fatigue, excitement with it. There's the people that are managing and constructing the system that have their own special kind of challenge of that repeating yourself, right? Design systems, I always joke, are like the intention of them is that you don't repeat yourself. But then you end up repeating yourself 5000 times explaining the design system to people. And then there's those executives that fund it that are like, man, another multimillion dollar check this year that goes into this system.
And so there's almost like three different roles here and you're kind of in the junction of all of them where you have to have a bunch of folks that are building that need to continue to believe in the value and be excited about it. You have a bunch of people that are using it which need to understand it and want it and then you have a bunch of folks that are funding it that you have to continue to justify yourself towards. That's a lot when you think about that conversation at each of those three levels. What changes about it?
Adriana Morales [00:27:09]:
Going back to what we talked about earlier with HCB being a penny for profits business of how anytime we make a major investment in our digital org, that's money we can go back into a new store or into another area. Like H E B is also really mindful about our financial stewardship. We already have a lot of that bought in value to our design system because we have a lot of teams who don't have designers or who may not have dedicated front end developers. The way that we try to prove our value is how much can we help teams be self servicing? How can we help support these teams that don't have like a dedicated designer or a dedicated front engineer? Like maybe you have a backend engineer who's having to do all the different roles like how can we help them? And that's where our value of our design system came in is just the true nature of being a penny for profits business. When we do have people coming to us like why do y'all have so many designers or developers? I don't think teams quite fully realize that design systems are a key piece to the day to day operations for multiple teams because we're also filling the roles of both building the components and patterns but also doing a lot of education like teaching teams how to use figma, teaching teams best practices on like information architecture and things like that. If you were to take away a design system today, you lose a really big piece of education resources and documentation that covers how to build the best in class experiences.
Chris Strahl [00:28:43]:
Yeah. So it's a level up too. I think that's cool.
Adriana Morales [00:28:46]:
Exactly. One of the big arguments too that we make for a value design system is we make all of our components and patterns accessible. We're meeting all of our WebCag AA compliance standards. That's another big value for a lot of engineering leaders is that value of accessibility.
Chris Strahl [00:29:04]:
Yeah. I mean you take a risk to the business off the table.
Adriana Morales [00:29:07]:
Exactly.
Chris Strahl [00:29:08]:
So there is this general value of quality of software that I think that people don't really understand that like that level up comes with a quality bar that is really difficult to then pull back from because everything moves slower, everything's more cumbersome There's a lot more gunk and gum in the works or sand in the gears when you remove that level of quality bar from your organization. And you said one of my favorite things, which is like, what happens if you take the design system away? And you know, for all the people that know how much I harp on adoption, that's actually my favorite metric is the idea of how upset or how much would it change somebody's job if all of a sudden the thing you built went away. And that to me is always like one of the best metrics of justification of like what would get harder? What would you not be able to do without the system? And you take that and you add all that up and that usually represents a body of work that is multiple headcount worth of people to maintain that same body of work. And that to me is a really powerful thing to say to an executive leader that is funny in a design system.
Adriana Morales [00:30:16]:
I think one of the big values that executives don't quite see with design systems is that design systems think laterally so that teams can think deeply. Like a focus for a product team is to innovate. Design systems help curate. And what I mean by that is our goal is to help cut through as much noise as possible when it comes to identifying, codifying and sharing those universal design patterns, those truths, so that teams can really focus more on designing and iterating on solutions for their users unique needs. It cuts through the amount of rework. It cuts through the amount of times that we rebuilt the same button over and over and over. It also helps too for the teams that are building mobile native experiences to understand when do we align with the Apple hig and material to when do we deviate for our bespoke patterns that are really true to our HDB experience and our customers. I think if you were to get rid of the design system, you would just essentially be like almost burning down the Library of Alexandria in my opinion.
Chris Strahl [00:31:25]:
It's a very epic moment right there. I love that. Burning the ships when you come ashore, right? No, that's funny. I think that you kind of translated there. You jumped across the gap and into the idea of like how do you represent that value to the people that are building with it? Because everybody wants, you know, your T shaped developer or your T shaped designer and helping become more T shaped by that idea of design systems work horizontally so you can work deeply. I mean the idea of that sounds really appealing as somebody that has to go to work every day and either code for a product or design for a product or both is this idea that I don't have to think about all this, like, crufty stuff that ultimately represents the typical background noise of a product build. And if I don't have to think about that, it's all codified for me. There's a lot of value in me being able to do the deep work I need to to make the best product.
Adriana Morales [00:32:17]:
Exactly. And I think what is sometimes not quite recognized is that designers oftentimes have to do multiple roles like they're doing, especially product designers doing the work of both visual UX design. You also have developers that are not only building the thing, but also making sure that things are accessible, they're responsive. And so one of the big values with the work that a design system team does is they're thinking about all the things that maybe a product team doesn't have time to think about. How does this component or pattern apply across both web and mobile? How do we balance different platforms? Is this component or pattern following our branding correctly? Also to the accessibility considerations, if you take the metaphor of like an iceberg at the surface level, you know, it's the look and feel and the interaction, but beneath it, it's okay. Can this component scale for the future? If it's an atom, can it be used in all these other different larger organisms and molecules to then like the stability parts of it? There's a lot that I think often gets missed around why design systems provide so much value to a business.
Chris Strahl [00:33:32]:
So one of the big parts about avoiding burnout and frustration and exhaustion is how we celebrate our successes. And I'm really curious how you all celebrate the success of the design system at heb? What are your rituals that represent those markers, those milestones, those mini finish lines or checkpoints along the way? And what do you do when you feel like you cross one?
Adriana Morales [00:33:55]:
This is something that my team and I are actively trying to be better at. There's a really great article that Amy Hooprow called Burn Baby Burnout, where it summarizes a lot of that pain around design system burnout. Where oftentimes when you're building a design system, you're focused on building all those components and patterns that you sometimes forget to pause and celebrate. Even just those small wins, even though small wins are something as simple as we added a new variant to. Hey, I was able to have a really good conducive conversation with a partner that got them to change their mind. We do a couple of different rituals at our sprints. We always have like a retro where we Celebrate the wins. Also call out things that we want to improve in the future.
But I think even just celebrating individual team members wins, whether it's one of our partners completely refactoring our UI kit, that gets really great feedback, like just capturing things that people say about you or the work that you've done is really helpful to even seeing conversations that a designer might be having with another designer around. Hey, I noticed that our breadcrumbs look different in these two different apps. How can we start to make them look more similar? Or my personal favorite is when I actually see someone linking to design documentation I wrote, like, oh, they actually read it. That's wonderful. I think it's just taking those small moments to recognize how people are talking about you capturing them. And then also the team culture aspect of it. Like, we do quarterly planning in person, and I think that's been really great for us to get excited about what we're working on for the next quarter. And also creating space where we can take a break week and go explore things that excite us.
Whether it's, like, new stuff in Figma or if it's like a new framework, I think just creating time where we can play and get back to the work that we really love to do.
Chris Strahl [00:35:59]:
That's awesome. My favorite. Personally, I love it when somebody shows me something they've built and they're like, look, I built this and I made this. And you can see almost like the pride radiating off.
Adriana Morales [00:36:09]:
Yes.
Chris Strahl [00:36:10]:
That glow that they have. And when they feel really excited about that thing that they've built and that was using, like, the building blocks of the system that you had a hand in creating. Man, does that feel good.
Adriana Morales [00:36:22]:
That's a beautiful feeling. One of my other personal favorites, too, is when you have a, Like, a new designer that just joined who they're, like, nervous and kind of scared. And when they start to use the components and the patterns, you just see how much they flourish because they are able to really see, like, how they're thinking deeply. It's just. It's a really cool feeling. I think mentorship is the big piece of like, of celebration.
Chris Strahl [00:36:45]:
Oh. You can almost, like, bask in the mentorship warmth. You know, it's like this fuzzy feeling. There's very few things that, like, give that to you.
Adriana Morales [00:36:54]:
Yeah.
Chris Strahl [00:36:55]:
Well, hey, Adriana, thank you so much for being on the show today talking about this. I know this is a bit of a funny topic that we hadn't really tackled before, and I think you did just, like, absolutely wonderful job describing what it's like for you and for your team. So thank you very much for being on here.
Adriana Morales [00:37:08]:
Thank you so much for having me.
Chris Strahl [00:37:10]:
Hey everyone, this has been the Design System Podcast. I'm your host, Chris Strahl. Check us out at Knapsack.cloud. Thanks so much everyone. Have a great day.
Hey everyone, thanks for listening to another episode of the Design Systems Podcast. If you have any questions, topic suggestions, or want to share feedback, go ahead and reach out to us on LinkedIn. Our profile is linked in the show Notes. As always, the podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. Have a great day everyone.