On Theme: Design Systems in Depth

What happens when your system can’t support your flagship product?, with Adriana Morales — #08

• Elyse Holladay • Season 1 • Episode 8

Share episode

📲 Text the show your thoughts!

Adriana Morales from HEB (aka the best grocery store) poses a tricky question for the show: what happens when your design system can't support all your products, or your flagship product? Hashtag enterprise organization problems. Adriana and I explore some of the scenarios where this might occur, the "system of systems" concept, product team autonomy, and pace layers. Don't miss Adriana's explanation of her "ways of working" workshops and thoughts on creating empathy across your org.

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!

Links & References


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Adriana Morales:

I've had a lot of experience working with stakeholders that maybe don't want to budge, or maybe who don't want to hear another side to the story. And one of the methods that I found to be most impactful to get them to step out of their head, and to see something from a different angle, is to get them in a room and doing workshops where they can hear directly from the product teams, building, using those components and patterns, and being able to also hear the day to day experience of the design system team.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28–30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the podcast, I'm super excited to have Adriana Morales. She's a design principal on H E B's mortar design system based in Austin, Texas, where she uses systems thinking and radical collaboration to create scalable design systems, resources, and tools to bridge the gap between design and engineering teams and help H E B build cohesive experiences. For H E B, she worked in enterprise design, in a number of different industries, including at PayPal and IBM. So she has definitely seen a number of big design systems. She's also a mentor to the next generation of designers. She really believes in helping them uncover their hidden powers. And outside of work, she thinks running marathons is fun sometimes. You can find her exploring different parts of the Texas Hill Country and trying to get her dog to lose weight, which good luck, Adriana. Thanks for coming on

Adriana Morales:

Thanks. Awesome. Really glad to be here.

Elyse:

So, Adriana, you and I met in the fall of 2024 at Knapsack's Pattern Summit in Austin, we were both on the panel there, and I feel like we both just really hit it off. We share an alma mater, Rensselaer Polytechnic, which I feel like is just rare to find south of the Mason Dixon line in the first place, but especially another woman. RPI is overwhelmingly male.

Adriana Morales:

Yes. I feel like whenever I tell someone that I'm from RPI, they often confuse it with, Oh, are you from RIT, the Rochester Institute of Technology?

Elyse:

no, no,

Adriana Morales:

like, no, it's similar, but, but different. So whenever I meet a fellow RPI alumni, it's always, oh my gosh, hello, friend, kindred soul.

Elyse:

I knew, as soon as we met that I really wanted to have you on the podcast. I was just starting to record episodes when we met in the fall and I feel like you have some incredible experience with some really, really big design systems. You can have a real design system at any size company. I feel like this used to be a contentious point in the industry, like if you were small and you didn't have, you know, a certain set of like custom doc site things, it wasn't a real design system, and I think thankfully we're past that. But the problems that you face at a really big company, a big enterprise, are really different. You have made your career in this, this niche in this very, very big enterprise space, and, with that, I think you've seen a lot of the big hairy problems, that come along

Adriana Morales:

Yeah.

Elyse:

design and dev at the scale.

Adriana Morales:

Yeah, so I've been in the design system space for about six years so far. I got started at IBM. My roots are primarily doing product design, and at IBM, we were gearing up for a complete redesign of IBM Cloud. We spent a lot of time unifying our backend services, but we needed to spend some time unifying our entire front end because we had different versions of Carbon. So it was a, it was a mess. And that's where we got started with creating what was essentially a middle layer between the Carbon Design System and our product teams, because we had components and patterns that were very unique to our spaces. And it helped create a additional layer where we can provide that support to teams where Carbon, you know, was already tackling all of IBM. And then coming from IBM, moving into PayPal, I've been on both sides of design system practitioner and also a consumer of design systems. So it gave me a great opportunity of being able to see what it's like being both the, giver and the receiver with systems, the pros and cons to it, and they are the trials and tribulations of these past six years.

Elyse:

Yeah. It's a lot, especially when you think about how many teams, and how much infrastructure you're supporting at a company as big as IBM, as big as PayPal, but even as big as H E B. So, I mean, big H E B fan over here I don't live in Texas anymore, and H E B is one of the things that I miss, but for our listeners who are not from Texas, God bless them, tell us what H E B is.

Adriana Morales:

Of course. So HEB is a regional based grocery store here in the heart of Texas. We also have stores in Mexico. H E B is both a grocery store, it's also a major part of the communities here in Texas, because H E B is most well known for how well they responded during the COVID pandemic, where they were monitoring the situation early on, had a lot of their stores well supplied with food, baby formula, toilet paper, because for some reason everyone went out and bought a lot toilet paper. HEB also provides, you know, health and wellness services, pharmacy, so we have a consumer facing side of our company. But we also have an internal, what we call partner experiences, where we build a lot of our own tools in house, especially our tools around like warehousing, logistics, transportation. We build the tools and the applications that our store partners used to replenish the shelves. So we're working on different platforms. Like we have, of course, our MyHEB app , where you can order your groceries through it. You can get your prescriptions. We have that for iOS and Android. We also have our web experience for HEB.com, but then we also support hundreds and hundreds of internal applications that are just built across different stacks.

Elyse:

I love that overview because , when you're like, I work in tech for a grocery store. It's like, oh, well, like, what could that even possibly be? There's so much

Adriana Morales:

There's a lot.

Elyse:

to manage.

Adriana Morales:

And, and then also too, what's interesting working in the grocery space, is that, we have both our digital experience where, you know, curbside e commerce shopping, but we also have to try to match what our brick and mortar experience is. A great example of this is on our, my HEB app. You can switch your store mode to in store shopping and exactly locate where, a cinnamon spice might be located, or a specific type of flour that you need to use. So we're really bridging the gap between both digital and real life experience.

Elyse:

That's really cool. I would use that feature. I miss H E B so much. So when Adriana and I were brainstorming what we were going to talk about on the podcast, some of these like big hairy problems with design systems at enterprises, one of the things that came up was the situation when, what happens when the design system is intended to be providing design, development for the company, for the brand, for the design language, right? But one of your biggest experiences, one of your biggest projects or applications cannot use the design system. This is such a spicy problem because you know this is happening. And I think this is so interesting because, so often the flagship product is what the design system is built for. That certainly has been my experience in the past, kind of the opposite of this problem, where we built the design system for the flagship application, and then everybody else was like, we can't use it and we want to use it, but you know that the inverse is happening. Walk us through this scenario and how you even got here.

Adriana Morales:

Sure. So this problem has been in the back of my mind for the past couple of years. I personally think this is a problem many design system teams face. When we were at the design system summit here in Austin, Texas, last fall, I found it both eye opening and also reassuring to hear that many other companies were experiencing some of those same problems. I've been in this boat both at places I've worked at, and then also hearing other people's stories where, you know, you're building a design system, you want it to be able to work with almost every product or application across your entire org. It's a fantastic North Star dream, but the reality of it is it's really hard to do that. Especially if you have legacy systems that you have to support, or if you have maybe a hot moving space, like e commerce is a great example of this. Groceries, really great example of this during COVID where everything had to move digitally, where a lot of people had to build things quickly, and so you weren't quite able to build a design system from the ground up. And so some of these things have been retrofitted and try to almost not quite forced to work, but things that just organically happen. And so I wanted to share this all with you of what I've learned over these years so that other people can learn and grow from my experience. But I also would love to open up a larger discussion within our design system community around, how have you all encountered this? How have you navigated through it? And then what are some things that you can share with others to help learn from mistakes that may have been made, or hard learning experiences. I just think it's a really important conversation to have.

Elyse:

And very real because, you know, when you, first ask the question, like, okay, your design system is intended to be your design language, but your flagship application can't use it, it sounds very dramatic. Like can't use it at all, we didn't even think about it. But I think the reality is a lot more nuanced than that. So what are some of the scenarios that you've seen, or that you've heard about, where this is starting to happen maybe a little bit or maybe a lot, where that flagship app is not supported enough? What are those scenarios that you've seen?

Adriana Morales:

Yeah, there's a few different scenarios. The first one I've seen is when it comes to tech stacks. I'll use my experience at IBM to kind of kickstart this, this topic. So I got started working within Z systems, which is like the mainframe space of IBM. We're talking 30 to 70 green screens, applications that were built, you know, decades ago. However, there was a big push to start creating more web based applications, because that industry was experiencing a brain drain, where a lot of the older system admins and operators were at the point where they were retiring, but there wasn't enough of a younger workforce coming in. So that's what drove for a really big push to create web based applications. This is around the same time that IBM design was up and running. So we didn't really have a core design system, a lot of different product teams ended up creating their own style guides or design systems to support their stuff. So within IBM Z, we had our own design system. Carbon, which many of us are familiar with, had its roots within IBM Bluemix, which is now known as IBM Cloud, that's our cloud computing platform. The analytics team had their own. So we had a lot of these organic design systems that were developed over time, until I want to say it was 2018 or 2019, that at the CEO level, it was declared that Carbon is the design system for all different product and teams to use, which is really great. It's really great buy in for a design system team when it comes to adoption. But on the other side, it creates a lot of complexities and hurdles for teams that are working on legacy tech stacks, or who may not be able to completely translate a desktop based application into a React application. So that's one scenario I've seen. When I was at PayPal, I worked on the PayPal Developer Portal, which is more of a productivity based experience, where we have developers who need to reference technical documentation, being able to explore different PayPal integrations, and being able to reference API documentation. The PayPal design system was really well built out for mobile native, and for consumer facing experiences. And what I've found from my experience as a product designer working on more developer based merchant tools, is that we needed almost like a sub design language, that was meant more for business productivity, where you can focus more on like your data dense screens and having a different type of type scale that's used more for documentation. So the way that I've seen these situations happen is due to different tech stacks, different user needs, and a design system team doing their absolute best to navigate varying business stakeholders with different needs, different priorities. It creates a lot of churn and puts a design system team between a rock and a hard place of, how can we cater to the majority? And do our best work, but at the same time too, it's really hard trying to build a one size fits all or super mega design system for everyone. It's hard. It's absolutely hard.

Elyse:

I think we got maybe a little too focused for a while on the idea that we could, right? That there could be a one size fits all system, and, you know, maybe listeners, some of you out there have gotten to a scenario like this, for this reason, where you're like we built, you know this core stuff, and it was either really, really focused on one particular application or product, or it's so air quote core that it doesn't really actually provide anything special for any of the teams. But the two things that you mentioned, languages, frameworks, platforms, but also just design needs. I think we're really starting to see that you can't just have a one size fits all system that's going to work for every single thing, for a variety of reasons. And you can't always have the same team own all of those needs, which I'm sure we'll get to that.

Adriana Morales:

Yeah.

Elyse:

And what we do about it. But I want to just maybe brainstorm some other scenarios. What are some other ways we think this kind of thing can happen where you get into this sort of support hole?

Adriana Morales:

One of the scenarios where this often happens a lot is when a company acquires other companies. A good example is IBM and Red Hat. Red Hat has their own design system. So there are two existing design systems. There's Intuit is another really great example where they are multiple design languages, multiple platforms. I believe they, their design system supports different areas, but they also have like a system of systems, where you still have your core design system, but you're able to let teams cook to their own recipes, by consuming the main ingredients from that design system. Spotify is a great example of this. Some other scenarios that happen too, is you can have different organizations within a single company, that maybe don't speak to each other. I've kind of experienced this. You know, going back to when IBM Design was getting started, we had all those different style guides and like design systems within the product teams. But we even have that a little bit here at H E B. Like when I joined H E B two years ago, we had a design system that had its roots within our partner facing side, where they were building experiences that were more dashboards, transportation and logistics. And then we had another design system that was built for the MyHEB app, and they did a fantastic job creating the branding and visual expression for HEB. But these were a tale of two separate design systems within a company. So sometimes you have these things organically just happen because you have to, sometimes you have to quickly build something to get it out the door. And that's how those grassroots design systems take root.

Elyse:

But it's great that they take root. And I don't think it's a problem to say that, okay, then we've decided that we're going to roll this up into one bigger system or fund a team to really own that and yeah, there's churn there, but that's kind of what you hope for, right, when you start it from a grassroots perspective. But definitely you can leave some products behind in that situation where they're like, well, we just did this big refactor or, the newly minted official design system team is like, ah, we're not going to support Android or whatever. One that we haven't mentioned yet, but that I have definitely experienced is just the business priorities changing. And I think this is one of the hardest ones because it's not, it's not necessarily like a semi positive interim state. Where you're like, okay, we're moving from like, you know, one, one design system to another, we're, we're making some team changes or moving from Angular to React or whatever it might be where there's churn and there's movement. But when the business is just like, I'm thinking about some of the stuff that was happening at Indeed, like we were focusing more or less on the job seeker versus more or less on big enterprise customers versus more or less on uh, small to medium business. And each of those verticals had their own needs and when your organization is just like, yeah, this team, we're just not gonna like do anything there. It's not a massive layoff. It's not like we're deleting the product. We're just like, sorry, you're not a priority anymore. And that can be really, really challenging. Obviously challenging for the team themselves, but also really challenging for the design system to support them. Or in this case, actually have to say, sorry, we're not going to support you. And I think that this happens a lot because businesses are always changing. The economy and the markets are always changing. Our users are always changing. Our internal organizations are always changing.

Adriana Morales:

Yeah. And that is hard news to process. Change is like the constant variable when it comes to tech and when it comes to design systems. However, I think this is also a good opportunity too for design systems to be really intentional and mindful with how they communicate that hard news of, we're unfortunately at this time, unable to support you, because at the same time too, a design system team needs to set boundaries of what they can support. Especially if you have a team that is already stretched thin or maybe has committed priorities. I think that is perfectly reasonable for a team to set those boundaries. However,

Elyse:

if you're not stretched thin

Adriana Morales:

Yeah,

Elyse:

do everything

Adriana Morales:

exactly.

Elyse:

Especially at enterprise, which I'm really excited to hear some of the ways that you've approached this, the amount of teams, the number of teams that you have to support is so big, and the broad scope of all of their needs is so big, you could never, no matter how bad you wanted to, actually support and do all the things that needed to be done. And so you have to have some way , to set guardrails or boundaries and say, like, this is what we actually manage, this is what we don't manage. These are the ways that we help you help yourself. Rather than a trap. I think a lot of design system teams fall into, which is, yeah, we'll do it. We'll do it for you. And you just, you can't. You, you learn very quickly at an enterprise that you just can't,

Adriana Morales:

And that's where those boundaries really come in. Being able to point people towards like, intake request it was really key for this stuff. Documentation is really great for teams that maybe don't have designers, who need a way of being able to understand, how do you apply a specific component or pattern. Also too, ensuring that your design system is an ecosystem where you have different forums where people can ask questions. Because what I've found to be really cool, like we're not able to support all of the teams, but we may have a situation where maybe there's a team that did a similar component or had a similar problem and how they approached it. Being able to share that knowledge back and forth with other teams, like design systems can also be that connector.

Elyse:

So you get into this scenario, we get into a situation where one of the major, applications or products can't be supported by the design system, either partially or completely. Especially if you have to be responsible for telling them that the design system is going to be pivoting and no longer supporting them, or that the new design system you're working on is not going to ever support them in the future. So, a number of scenarios here. What are your options? If you were talking to a design system practitioner or design system team who was in this situation, what options do they have for actually managing this challenge?

Adriana Morales:

There's a couple of different schools of thought on this. One group would tell you to just serve them, figure it out. Another option is to say that you're not going to change your plans or you won't change the direction of your design system, and let that team become independent and self sufficient. Another option is to find a way to enable that team. It's like the system of systems, where you're able to allow teams to consume the core ingredients of design system, while being able to use whatever tech stack works best for them and being able to modify the design system in the right way to fit their team's unique needs and the unique needs of their customers. I personally find that to be the right approach, where you're not making your design system team spread thin. You're also creating essentially different layers of governance that allow you to have some degree of cohesion across those experiences, but you're not forcing teams to follow a single way of building and creating and designing. For me, speaking as a design system practitioner, like my core ethos is, let teams build in the ways that make sense for them. And find ways to support them to do their best work while creating that foundation for them to build off of.

Elyse:

As you were talking, I was just thinking about, this is one of those places where it is really, really different in a small company versus an enterprise. When you are at an enterprise, you have so many teams, so many divisions, maybe you're global, you have contract teams. The number of ways that you just have to figure out how to let teams build their own stuff in their own way. You cannot avoid needing to let teams be autonomous. I mean, if you have, web and React Native and Android, you already are in a situation where your teams have to be autonomous. Even if you are a highly supported, highly resourced design system team, with C level support, there are going to be situations, rightfully, where you're gonna say, we're not going to support that framework. But I'm thinking about at smaller organizations, I'm thinking about at Color, like if we decided that we were going to build, say, a React Native app. We're small enough that part of that conversation would be okay, we're going to have to figure out how to do that as an organization. We're going to have to figure out how to hire people who have React Native experience. We're going to have to figure out how the design system can support that. And so it's kind of flipped almost. Like the business need is like, oh, we're gonna have to figure out how to do that, so the design system is going to have to figure out how to do that. Whereas I think at the enterprise level, you have at some point to say, these are the things that we support, and we are going to let teams have autonomy sometimes in ways that we cannot support.

Adriana Morales:

This was something that I had a chance to experience firsthand this past summer. I hosted a series of workshops with our consumer facing side of HEB where components and patterns were a symptom of some larger issues. What it's really tricky with working in both the digital space, but also working in groceries is that we're a penny for profit business. So we have to be really mindful about our investments in our digital org. And so with these Ways of Working workshops, we want us to be able to understand what's the root cause behind these problems? Is it components and patterns? Is it design language? Is the design system team not being able to support those teams in the ways that they needed? But we actually ended up finding that engineering has a foundational team where, you know, you have one team that manages the components for the web experience, another one for Apple, and Android, but you don't have that side for design. Like being able to find ways, how do we organize design engineering around common work? And that's where a lot of that system of system stuff came out. Like that Ship Faster by Building Design Systems Slower article validated so many different things that we were experiencing over this past year.

Elyse:

It sounds almost more like Design Ops.

Adriana Morales:

Yeah, in a way. Well, our design system team sits within our enablement space, which includes DesignOps, and design systems do have some overlap with DesignOps.

Elyse:

Not to go off on way too much of a tangent, but I'm really curious. How are you working with the Design Op teams? Like what are those overlaps?

Adriana Morales:

Yeah, so our overlaps are around a few different things. First one that comes to mind is education. When I joined HEB a couple years ago, there was a need to be able to disambiguate design systems because we had people coming from different companies who maybe had experience with design systems, or no experience at all. So working with DesignOps, we've put together different trainings, educational series around, how to utilize Figma variables, what exactly are components, being able to do a lot of training around accessibility. So there's the education side of it. There's the other side when it comes to tools and resources, like our Design Ops team manages Figma, they manage a lot of the templates that our design teams use for wireframing, prototypes, et cetera. A lot of those resources also live within the design system space. Our Design Ops team also is responsible for putting together the processes and practices for different design teams. And that's where design system has overlap with it, cause you kind of need a design system in order to, you know, create your wireframes and prototypes. So we're kind of kind of go hand in hand.

Elyse:

I love that. I'm sure you're making lots of people jealous right now who are like, ah, I wish we had Design Ops. Because a lot of the things that you named are very much falling under the purview of design system teams. Especially education, I know that's been a hot topic in the design system community of like, how much are we responsible for teaching designers on product teams, how to use Figma? Or how to understand code or, you know, how to prototype? When you start to see the problem not being about the components, but about, this product team needs help organizing their design and engineering process. And like, you can't put your hand in every pie. But that's in a lot of organizations, what Design Ops helps do.

Adriana Morales:

I always think of the metaphor of the canary in the coal mines, where our office hours are kind of like the canary in the coal mines, when it comes to how teams maybe are struggling to build the right experience, or are struggling with building the right tools and applications, cause we have many teams that don't have designers. And so our office hours have become a way where those teams come to us because they have just genuine questions about the components and patterns, but it actually ends up turning into bigger conversations, where maybe there's larger information, architectural problems with the app, or just problems around not using Figma correctly. Design systems sometimes can become a catchall for a lot of those larger systemic problems when it comes to practices, processes, much needed design support that's just not there.

Elyse:

Yeah, definitely. So how are you supporting them when they come to you and they're, they're saying, you don't have what we need, or I can't use the components that are available. I'm kind of going back to our original scenario of like, if you've got a team that's coming to you, you know, not having design resources is one thing, but really coming and saying, Hey, what about us? Do you have any political pitfalls, things that went wrong, in your experience or like tricky inner political, inter organizational problems?

Adriana Morales:

I think the first step it always starts with a conversation to dig deeper and understand their needs. Whatever we have today, how can we support them? The first step is gathering that information, understanding where they're coming from. And then working together towards, well, okay, if y'all aren't able to use our, say we have like web components, y'all aren't able to use that. What are you able to use from the design system? Where there's maybe some things that we can start to automate? Like maybe they could use our color tokens and our spacing tokens. Maybe they can leverage some of our foundational design patterns. Maybe it makes sense for that team to have a design language team that supports them and stays in close contact with us as the design system team. This is also something that I am still actively figuring out, because it's a very fluid situation that really depends on the needs of that team, the tech stacks, to the priority of the business. I've had a lot of experience working with stakeholders that, maybe don't want to budge or maybe who don't want to hear another side to the story and one of the methods that I found to be most impactful to get them to step out of their head, and to see something from a different angle is to get them in a room and doing workshops where they can hear directly from the product teams, building, using those components and patterns, and being able to also hear the day to day experience of the design system team. I actually find that to be a really great way of being able to win people over. Especially when you're all in the same room for eight hours. Like we have to, we got to talk about the hard conversations and work through this stuff together, otherwise we're going to stay in the, same pile of misery unless we make a change.

Elyse:

What are some of the workshops you've done? Tell us a little bit about. What kind of exercises and like, what do you do in these workshops to really get people actually opened up and talking about it?

Adriana Morales:

Yeah, the first type of workshops that came to mind were like, I call them these little mini design jams that I did , usually when I'm first working on a new design system. It's these design jams that are focused around a specific component, so, buttons are a great example or cards and reaching out to different teams to share examples of like, how are y'all using buttons in your experiences? What are some rules and being able to have teams share the decisions around why they maybe create their button hierarchy this way, or why they design their buttons. You start to extract some of the commonalities. And it's also been a good way to get teams who've maybe have never talked to each other before. Talking whether virtually in a zoom room or physically in a conference room. That's been one way of being able to break the silos between teams. The other workshops I've done, which I mentioned a little bit earlier on the call were the Ways of Working, where we wanted to understand what is the current, designer and developer experience building experiences for web on like HEB.com. Like, where are there frustrations that designers are experiencing when it comes to the designer dev handoff? Where are developers raising concerns? Where is their disconnect? Why is the design system team being the catchall for some of these problems? So those workshops have been great at being able to really get a clear narrative around, okay, these are the pain points. This is what's happening. And here are the underlying causes and how we can fix it. And through things like playbacks. Playbacks are essentially, uh, points of reflection during your product development and life cycle, where you bring all of like your stakeholders together to essentially play back the work of what you discovered and what you've done to have a collective conversation around how do we move these things forward and making sure everyone has their input brought in. Like those playbacks are really key to being able to share that work and being able to start to have that cultural change.

Elyse:

I love that. So you were saying before that the system of systems setup is something that has been working for y'all at HEB. So I'd love to hear a little bit more about that. Can you give us sort of the TLDR of what a system of systems setup even is, for maybe anybody who's not familiar?

Adriana Morales:

Yeah. So the system of systems ties back to this pace layer where, you know, as a design system, we generally move slower because we're building key infrastructure that need to be stable. On the other side, you have product teams that have to move very quickly because they are responding to the needs of the business, the needs of the market. They need to get things quickly out the door. And so the design system shouldn't be a bottleneck for those teams. Cause oftentimes we've been in situations where a team might come to the design system team and say, Hey, I'm doing X, Y, Z, your component maybe gets me 50 or 60 percent of the way there, or it doesn't exist at all. Do I wait for a design system team to build this component or can I get autonomy to build it myself?

Elyse:

my head going, no, no. Because we, I think a lot of teams, and I mean, I certainly have been in this situation, you go, yeah, we'll do it, we'll, we will update it. And as soon as you start down that path of, we are now responsible for product delivery. Like pain, there's just only pain on the other end.

Adriana Morales:

Yeah.. It creates a lot of maintenance, especially with teams that maybe have a very bespoke component, like you don't want your design system to become a junk drawer. Don't put crap in the system. You really want your design system to curate the innovation of what product teams have done. And so with a system of systems, you have your larger design system, think of it as like the sun. And then all of your different product areas are their own planets that can orbit around the sun, where they are able to benefit from the foundational pieces like color tokens, type scale, maybe stability checklist, maybe some components and patterns they can use, but you give them all of the right ingredients, where they can create their own UI patterns and components that are very specific to their space. They can own it and they can manage it. They're still benefiting from the core stuff of the design system, but then the design system team isn't burdened with having to maintain hundreds and if not thousands of components and patterns.

Elyse:

So what I'm really hearing you say is finding ways to support teams, that maybe are not supported a hundred percent of the way by the system, right? So, like, let's say you've got a team that's using Angular or Vue and your core design system is in React, instead of just being like, sorry, you're screwed, or yes, we will also build all of this in Angular and also maintain all of that. Let's just go hire an Angular developer. You know, finding some other ways to be like, okay, what can you copy? Can you maintain your own layer of Angular things? Can you just reuse these visual styles? Are you seeing this primarily on the engineering side with like different languages being the blocker, or is it more of a design problem?

Adriana Morales:

I see it being both a design and engineering problem, like for design, especially when you're a design system that's supporting multiple design languages, it's ultimately the product teams that should be responsible for managing the design language. The design system is like the maintainer or place where that design language lives. On the other side with engineering, I definitely do see that with like the tech stacks. Like for example, our, our design system uses web components. Web components can have a bit of a trickier learning curve for developers who aren't familiar with it. And you might have some teams that prefer to only use React or only prefer to use Angular. So we found ways where those teams can at least consume our core ingredients and they can just build their components to whatever is best suited for their needs.

Elyse:

So let's, let's talk about some of the more emotional or political elements of this. I think a lot of people listening are probably really familiar with some of the technical ways that you might deal with a problem like this, like we were just talking about, but, I think one of the harder challenges is how you actually manage this internally in an emotional way. In conversations, in interpersonal, interpolitical, interorganizational disputes and debates. I mean, even just like, you get somebody in your office hours or a product manager or a lead on a team that's coming to you and going, y'all are just leaving us behind. And that can be really, really challenging. So, what are some of the the ways that you're handling those conversations or some of the scenarios that you've had to work through.

Adriana Morales:

Well, this is a really good question. Because I think what sometimes isn't talked about is the receiving end of how the design system team feels when people come to them with disappointment, frustration, sometimes anger. And the way that I've always handled situations is to, one, remember, don't take things personally, especially, you know, with design systems, they're very service facing. And oftentimes you will experience a revolving door of different people who may be coming to you at different points in life, or maybe they are trying to meet a really tight work deadline, and something just breaks and they are tired, they are frustrated. I have also been on the receiving end too, where teams feel like they were never heard or listened to. And one of the key pieces to working through this stuff is to create spaces where people can share with you those frustrations. Whether it's anonymously or directly, tailor that method of feedback in ways that make people most comfortable with. But also going on a listening tour and interviewing those teams, who maybe are frustrated, or maybe feel like a design system completely skipped them. I find that to be both really insightful for design system teams to think about how they maybe want to approach their strategy in the future, or how they can service these teams. But it also helps those teams to be heard, seen, and feel like they have, and do have, a direct influence in the design system. Because at the end of the day, design systems are for the teams and for the end users who are using those experiences. When it comes to stakeholder management, I often go back to this philosophy or mantra that one of my design leads at IBM did. Where he had 4 PMs, maybe 5 PMs, he had a report to. On a good day. He can make one or two happy. I think that's a realistic expectation, is that you won't be able to make everyone happy. But being able to manage stakeholder expectations, being able to create that space where they can be heard. But also being able to be a really strong storyteller and tell a compelling narrative to help them understand the challenges that maybe you as a design system team face, the challenges within like the company space, and then providing solutions and frameworks and like how to solve that. Part of it is also being empathetic and kind. No matter how exhausting it can be at times, especially when you have a design system team, feel like everyone is coming at you with daggers and such. Um, and then also reflecting and remembering and celebrating those moments where people did tell you they did a great job or that they really appreciate something that you did that made a huge quality life improvement for them. It's all about balance.

Elyse:

It really can be so hard when the majority of what you hear from the design system consumers is frustrations and complaints. I'm not at all going to dismiss the emotional, challenge. That is very, very real. And at the same time, I love that you would call this service facing. This is a role in a team that is meant to help all of these product teams get stuff done. And especially , when you have at the top level, they're like, you have to use this, you have to do this. You know, they're coming to you and going, okay, like here we are, like we have to use this thing. And it's not working for me. And I have a deadline. And I'm just trying to get this thing done. I need support and I need help. We've all had this experience where you go on like a, a forum for something you're trying to build, or like, your appliance is broken, and you're like trying to read the, you know, support forum or whatever. And you get a response that's like, sorry, you're just screwed. It's rage inducing. Because you're like, will no one help me? I think it's very hard sometimes to put ourselves in those shoes because we're like, you don't understand all of our problems. And like, you don't understand any of my problems. And it takes a little time, you know, a little like, oh, okay. Like we gotta how do we get on this together? Yeah. One of the things that I think has worked really well for me in this hard space, as you were talking about, you know, teams that don't trust you or feel like the design system has let them down, has really just been going to them and going, yeah, we did, we screwed it up.

Adriana Morales:

Yeah, taking ownership.

Elyse:

We didn't hear you, we are not supporting you right now, and we really want that to change. It's so scary to admit that you are wrong or that you can't do something. And I think a lot of people in design system teams really want to help, right? We really want to make this thing good for our—

Adriana Morales:

Mm hmm.

Elyse:

—teams, and then you're in a situation, whether it was your fault or not, like the business has told you don't, don't support, we're not supporting that vertical anymore. Like that's legacy now, don't build anything new for them. And you have to go then and be the messenger and say, sorry, we're not gonna, we're not going to maintain these components anymore. We don't have time for design support for you anymore. Whether that's your fault or not, you have to go then deliver that message. And imagine like what that feels like on the other side to some team, who's like, they've got deadlines, they've got customers, their customers are going, why is this broken? And they're like, I just need support and I need help. And. You know, I don't know where I was going with that other than at the end of the day, we're all just people trying to do a good job, trying to make the thing go. It's easy to forget,

Adriana Morales:

As a design system in order to help others, you have to first take care of yourself, before you can take care of others. I think there's a really great point you brought up earlier, about a design system team owning up to past mistakes that they made. I think taking that ownership and being responsible for it is a really big sign of growth, and also helps to create transparency. And also build more trust with maybe that team that got burnt on the other side. Especially if you want them to suddenly like be working with you or like using the thing now. You have to go back and kind of grovel a little bit and be like, okay, like, we're gonna, we're gonna be different this time, we swear. And you can understand why they don't necessarily trust that. Yeah. Not necessarily quite groveling, but really just having a candid conversation—

Elyse:

—I was, I had to grovel. Yeah.

Adriana Morales:

No, I understand. Yeah, it's like just having a candid conversation and just being really authentic with like, okay, yeah, we understand something, something screwed up, like, let's, let's have a retro on it. Let's dissect what didn't go well, what we can do differently. We did that a lot with these listening tours over this past year, and I think that was, a really great step with us building more trust between a team that just felt like they weren't heard or listened to.

Elyse:

I want to go back to kind of our original question, especially about what happens when one of your major projects or your major products is not supported. As painful as it may be, it's very different when you're like, okay, this vertical of this product is legacy, we're decreasing support, we're no longer investing in that in the business. That's one thing. It's another thing when you're like, for, for whatever reason, one of our core flagship teams can't be supported by the design system.

Adriana Morales:

Yeah. I think I'll go back to IBM where, you know, we have Carbon, which is used for all the product teams but there's also a version of Carbon that's very specific to IBM.com. I don't have the full story, but I think this is a really great example of where it's okay to have more than one design system. Especially if there's like those different tech stacks or just different needs for, for various reasons. What's interesting with between Carbon and IBM.com is that if you look at them and experience, you know, an IBM cloud application or a page on IBM. com, it feels like IBM. The branding, the design languages, are all consistent, it's a cohesive experiences. So kind of going back to that earlier question we posed, if your design system isn't able to be the design system for every application, experience, or product, it's okay for there to be multiple design systems. Which I'm sure might sound like a spicy hot take in the industry. But really, at the end of the day, is being able to build really great experiences that meet people's needs. And also have a good designer and developer experience, when it comes to building it. I think that's something that often isn't thought about is the designer and developer experience when it comes to consuming a design system or system of systems.

Elyse:

Yeah. So what are y'all doing now, to work through this at HEB with your system of systems? I know you had mentioned before that there were a couple kind of more grassroots systems that had come up, one that was kind of more consumer facing, was really like brand focused. And y'all have rolled all of that up into a single system, into Mortar. So what are some of the ways that you're managing this system of systems to kind of like help support all of your consuming teams?

Adriana Morales:

Yeah, I will be transparent, we're still in the early stages of this. Like we've spun this up within our CX, our customer experience side. Where they have the CX design language team where they are managing the system for HEB.com and the MyHEB apps. We're also in the stage of building mobile native components for both iOS and Android. And that's moving us into an interesting space where we have to figure out, okay, what exactly does it mean to maintain platform parity with the Apple HIG and Material, versus, component parity for teams that are designing across web and mobile native. We're having some early conversations right now with like, how could this system of systems look for other design languages and those different product teams. So we're still building out the system, but what is really great to see is a higher level education around like designers and engineers thinking more about the collective experience that they are all supporting. Like a team that maybe works specifically on the checkout, versus a team that looks at, savings and coupons, or another team that's building out the pharmacy side. They're thinking about a lot of these things collectively as a whole. So I've been seeing a lot more of like that overall systems thinking which ties back into design systems.

Elyse:

I love that. we always want that, we always want our product teams to be like, how does this make sense across the whole experience? It's very easy to get in your little bubble. Even for design systems. So let's sum up a little bit. If you, were going to give some advice to a design system practitioner who's in this problem, unable to support one of their products or, needing to pivot, the organization's pivoting, design systems pivoting, whatever it is, they need to be having some conversations with consuming teams, and just say like, we can't support that. Sum up your advice. Like, how would you tell them to manage this? How would you tell them to talk to their consuming teams about the situation, assuming that, sure, we'll just build all of those components for you is not the actual available choice.

Adriana Morales:

Yeah, the advice I would give would be, this is almost advice I wish I could give myself a year and a half ago, is to first stop, breathe. Remember it's all about balance, balancing the work that you're able to realistically do as a design system team. And then what's actually going on with the business, the direction. Being able to sit down with that team and understand, you know what are their needs? Maybe trying to find a middle ground of how you can support them or how you can at least set them up for success. And being able to maybe raise or escalate concerns that you as a design system team have to leadership. Or for that team who's impacted by the design system being able to not support them, they can escalate it up to their leadership, so at least there's a conversation around, okay, how can we start to get these things in the right place? So that'd be my one step is like, breathe, talk to each other, understand why things are the way they are, maybe see if there's a path to escalation, whether on the design system side or on the product leadership side. And then maybe even looking at putting together your own system of systems. Or looking at ways that that team can maybe consume some pieces of the design system. I think, you know, I would essentially say, start with the conversation and go from there, I know it sound so simple.

Elyse:

And be like, talk to each

Adriana Morales:

other. Not that simple

Elyse:

But it's not.

Adriana Morales:

But it's the first step in the right direction though.

Elyse:

It really is. Thank you for all of that. I know that, we've talked about this problem at kind of a high level, but there are so many ways that this issue shows up, right? The issue of support for design systems, the issue of what you actually can build or manage or maintain as a system team. So for everybody listening, I hope some of this resonated, in one way or another. We would love to hear your particular situations, ways that you've managed this, the scenarios that you've gotten yourself into, or out of. So don't forget that you can text the show. There's a text link in the show notes. You can send me a message on LinkedIn. You can look up Adriana on LinkedIn as well. I think we would really love to hear the scenarios that you've been in, and chat with you. Really broadly, if we think about the design system space right now, we are realizing, like we said at the beginning that there is no one size fits all. I think, a number of years ago, five or so years ago, I think there really was kind of a belief that if you could just build all the right core components, that you would finally solve UI for everybody. And I think we're realizing now that we need to figure out multiple different ways to support multiple different kinds of teams with different tech stacks, with different design needs, with different customers, and, and figuring out as a, a group of practitioners, how we do that in a way that is maintainable. So Adriana, thank you for sharing your experience there.

Adriana Morales:

Yeah, thank you so much for having me.

Elyse:

You're so welcome. So to wrap up, I ask everybody who comes on the podcast to give us a spicy take on design systems, so, so let's go.

Adriana Morales:

Yeah. So this isn't so much a spicy take, but more of some hard truths that I've learned over the course of the six years working on design systems that, that are really important to me. And the first one is like, design system teams should touch grass. And what I mean by this is that every so often, I think it's really important for design system designers and engineers to step outside of the realm of design systems, and do some product design or development work. My reasoning for this is one, you don't lose your roots in product, and you're also able to be on the receiving end of a design system. Essentially, this means eat your own dog food and being able to see what the actual product teams are doing and being a consumer of it.

Elyse:

Nothing will make you realize you are way too in the weeds in your Figma set up or whatever, then going to try to like actually build something with it. And you're just like, what? Is this mess that I made?

Adriana Morales:

Exactly. And I think my second spicy take is that I mentioned this earlier, you know, design systems are service facing. I think it's really critical for a design system practitioner to have a good level of emotional intelligence, and to be kind, especially since you are going to be servicing a lot of people who be coming to you at different points of their life and their journey. Be kind, be empathetic, and just be mindful of how you communicate things.

Elyse:

A hundred percent. I will give the even spicier version, which is if you want to work in design systems and you're not willing to be a good listener to people and be empathetic, if you just want to go off in your corner and build components, you don't need to work in design systems. Like that's not what this space is about. And I know that some people don't want to hear that because it sounds really fun to make components and make systems, but this is a people space more than it is anything else.

Adriana Morales:

Exactly. Well said.

Elyse:

Well, thank you so much. It was such a pleasure. I really hope that everybody listening got something out of this. And again, please share your thoughts with us. We'd love to hear your experiences and what you learned. Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!