On today's episode of the Design Systems Podcast, we hear from Catalina Manea, Senior Designer at Spelunk, about the crucial intersection of design and development. Catalina shares her journey from graphic design to product and systems design, providing insights into the importance of reusability, cross-functional collaboration, and empathy in building scalable and adaptable design systems. Catalina emphasizes that design systems go beyond UI and consistency—they are powerful tools for enhancing teamwork and agility in fast-paced environments.
Guest
Catalina Manea has been a system designer since the early stages of her career as a product designer, working with both emerging and established design systems. She has collaborated with cross-functional teams to launch new systems from scratch and has contributed to refining and evolving well-established ones across multiple industries. Throughout Catalina’s career, she has enjoyed mentoring junior designers and sharing insights at industry conferences.
Transcript
Chris Strahl [00:00:00]:
Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. 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 generally tell us what you think, go ahead and tweet us at thedspaw. We'd love to hear from you.
Hey, everyone! Welcome to the design systems podcast. I'm your host, Chris Strahl. Today I'm here with Catalina Manea. Catalina is a senior designer over at Spelunk. Welcome to the program.
Catalina Mina [00:00:29]:
Thank you so much, Chris.
Chris Strahl [00:00:31]:
So there's a fun chat that we preplanned, gosh, like, at this point many months ago. And so I'm glad you were patient, stuck around to be on the program, but we're going to talk a lot about the core ways that we think about building applications, and you have some really thoughtful takes on this stuff. So maybe just to get us started, talk a little bit about your background as a designer and how you kind of came to this point.
Catalina Mina [00:00:54]:
Yeah. Awesome. Thank you. So I started in graphic design, I think, like many designers, and I accidentally landed in, like, the design system world back in 2017. I was actually working with a local company at a time, and we had the opportunity to have Brad Frost coming over to the Cleveland area and giving, like, a speech and all the details about design systems. And it was kind of like the AHA moment. At the time, the company that I was working for, they were looking into style guides. So, of course, we started looking at pattern lab and just dabble our feet into this side of the world.
Catalina Mina [00:01:34]:
And funny enough, I think every single company that I have ever worked for, they went through some kind of transition and acquisition. So that company went through a transition like that. Then we lost most of our teams within the design team. So I became responsible for the implementation of the design system. I was partnering with people from marketing, people from product developers, obviously. And I really loved it. And I'm like, I think I can see myself doing this. So then my next role was product design.
Catalina Mina [00:02:10]:
It wasn't like a full time system designer. My role for a system designer was after that. But I've been doing it since 2017, whether as a side thing or mostly dedicated roles. Now that I think about it,
Chris Strahl [00:02:22]:
I think that one of the things that has been interesting about your career is you've got to kind of see from a design perspective, from an engineering perspective, a lot of the ways that people build applications and, you know, as someone that you said is at least somewhat of a self described visual designer, now you're in the systems focused role. Talk to me about the differences there. I think I have an idea of where this would go, but I. When you're talking about visual design, you're oftentimes building for a feature or building for a product. When you're talking about a system design role, you're actually building for lots of features and lots of products. And I think there's a lot of core things about the way that we build that have been shaped by this change in role for you.
Catalina Mina [00:03:05]:
Yeah, absolutely. To clear out, because I think there's some people that will listen to this and it's like, there's no way she's a visual designer. I wasn't like a dedicated UI designer. I think I would always describe myself as a more pure UX product designer role. I started, like, with acture, and I was building conditions in acture, and then I moved into sketch, and now I'm into Figma. I was always addressing design from a perspective of ux rather than pure visual. I think I liked doing visual design, but I was never like a pro at UI per se. I liked system thinking.
I think the first thing that really excited me about was not even the fact that it was the system thinking. It was just feeling like I was closer to the engineers. And I felt like when I was doing day to day product design, I wasn't getting the same perspective. It automatically brought us closer, especially in early stages, when building a system like it just really helped shaping that collaboration between the two different sides, that sometimes they feel very disconnected when you do the day to day product design.
Chris Strahl [00:04:16]:
Yeah, definitely. And I think there's a lot of terminology that gets hung up here, too, right? The idea of UI versus UX, of product design versus visual design, of what's an interface versus what is an experience or a component. And so all this gets really complicated and this crazy morass of how we segment and slice our roles. I think what it kind of boils down to is when we talk about the core way that we think about how we construct experiences, I think it's safe to say that both you and I take a very systems-focused view of this stuff, where we look at it in terms of not how do I solve this one problem for this particular moment, but how do I solve this problem forever across every product in an organization? So explore that with me for a second, when you think about the fundamental issues that arise when you're building out an application, what is it that you look to? And what is it that is in your toolbox or in your mental models that you reach for?
Catalina Mina [00:05:13]:
I would think reusability, first of all. So one of the main things that I've been seeing as a system designer through office hours for design system is always designers reaching out for a very specific problem and use case. And I think product designers tend to think very much so on a single problem that's applied either to a specific workflow or a specific application that might be working on, versus as a system designer, you have to think of these things obviously, holistically, and how it impacts different environments that the component might be applied. So I always look through the lens of, like, can this be used anywhere else? And as cheesy as it might sound, Brad, Frost and denmal, they have like a really cool hotpot theater process and contribution model that they put together. And I always go back and I refer to that. So it's as simple as, like when a designer comes with a request or a question, whether a component needs to make it to the design system or not is a matter of how often will that component be reused. Is it just for one time thing, two times, three times? And where is that documented? Because I think a lot of design systems don't focus as much on documentation or like real life examples, which come in super handy. Also when onboarding new designers or new designers are learning about systems or the system at a company.
Chris Strahl [00:06:34]:
So I love that you invoke the ideas of Dan and Brad and reusability. And I think that there's been sort of this ongoing conversation about how do we measure the impact of reusability? How do we think about reusability as it relates to systems. And I think that there's a lot of power here. One of the things that I think is also really challenging about reusable structures inside of design systems is you end up with proliferation, right? And so you end up in a place where even in that hot potato concept of, you get a lot of stuff that gets added and very few things that ever get removed when you're facing that challenge. The thoughts around how do I think about the application of patterns to be able to mitigate a lot of this component proliferation? I think there's a lot of interesting concepts there. I had a great conversation with Dan not that long ago about this, where the total number of components you should have in your system is maybe 20 or 30 at the most 40. And then you should be able to think about the patterns that you assemble. All those components.
Catalina Mina [00:07:32]:
Exactly. Yeah.
Chris Strahl [00:07:34]:
But then people struggle with the visual design aspects of that. How do you sort of bridge that, like visual design interface, component pattern dance that you have to do to get people to actually understand how these systems work?
Catalina Mina [00:07:45]:
I'm going back to the beginning of our conversation. It really depends on how we are defining visual design here. If the components are predefined and if the tokens are predefined, then I think it's like building a puzzle, right? It's kind of like if you're into Harry Potter and if you're into puzzles, you're buying like these pre defined puzzles. That's kind of like a system versus back in the day, the Legos that I used to play with, they were not coming in those predefined sets. Right. So if you have the tools, then it's easier to build it. So the way I think of components, I think of the actual tools, and then you can create those patterns which oftentimes result into workflows and pages and they can be documented and reutilized. I don't think visual design is as much of a concern because visual design also is subject to be changed.
Visual design can be impacted by obviously, like, trends, it's impacted by branding, heavily branding changes all the time. So if the design system is set up correctly and if we think about it from an abstract perspective, it needs to be able to hold change. I think that's the key for a successful design system. Yes, reusability is one of the aspects, but it's also the power of adapting to an acquisition, for instance. Right. Or like changing brands or two companies merging together or anything like that.
Chris Strahl [00:09:06]:
Yeah. And I think that's what I was thinking about when I was talking about that separation where the idea is that you want any component or any pattern inside of your system to be able to work with any brand, any visual tokens that are applied to it, it shouldn't break the way the pattern works. And so when you think about that separation, there's this kind of decoupling, right? Because in the early days of design systems, if you had multiple brands, you think about, like design system for brand a, brand b brand C. Now the ability to say, like, well, no, it's all one design system. It just has different sets of tokens or different modes or themes or whatever term you want to use in the complicated mix of terms there. But that gives us a lot of power because now what we're talking about is not just a system that serves a single product or a single brand, but a system that can serve a lot of different parts of the organization and persist in an acquisition or something like that. So when you think about the structures of these systems and you think about kind of the approach that we take here, talk to me a little about like the deeper philosophy here, right? And so we've talked a lot about these kind of like tactical ways to think about these systems and some of the fundamentals here. But when you think about like the philosophical side of why you construct systems like this, I love your take on like the philosophy and the approach to these sorts of creations.
Catalina Mina [00:10:23]:
One of the biggest pain points right now that I'm seeing in the field is everyone really focuses on that visual aspect of the design system. If you look at job descriptions, they're literally copy paste. It's the same lines over and over again. And you will always find the word UI design in there, which is very confusing, especially if you're not the UI designer. So as I told you, I was genuinely considering to leave the design system world, as much as I love design system, because I felt like everyone was very focused on this output idea of UI, because I don't think UI is the input in design system. UI is the result of a healthy design system that has good operation and, you know, a set number of components that's enough for the team to be manageable and it tracks all of the updates. So when we talk about the philosophy of it, it's not supposed to be about UI design. Systems are not about UI design.
Systems are about, and they're not about consistency. I think even consistency itself, like I know designers that would say consistency the killer, like it's needed, right? You're building products that need to be recognizable for the users, setting the expectation with your customers. And it's not the killer. I see design systems as a collaboration tool, not a UI tool and not a consistency tool. All of those things are outputs and results. If the design system is built utilizing the right approach and mentality, and if design and development and all of the involved parties work closely together.
Chris Strahl [00:12:01]:
Yeah, I love that take. I think that the idea that somehow the component library is so essential to the design system that it can't exist or can't have value without it, when you think about it in terms of the essence of what you're creating, that essence of what you're creating is about the collaboration. All the other stuff can kind of fade into the background. What you're trying to do is you're trying to make your people's lives easier. You're trying to reduce the friction in the organization. It's not about what Uikit can I stuff into this framework or in this system. And in fact, I think that it is interesting to hearken back to the job description thing you were talking about. You're the second person today that has complained about this.
Chris Strahl [00:12:39]:
Like, how many UI kits have you built? Well, like, does that actually matter if I'm going to be in charge of a design system? You know? Do you have eight plus years of experience with Figma? Well, that's actually really hard when it hasn't been around that.
Catalina Mina [00:12:49]:
Yeah, like, I'm sorry, I'm going to say this. Figma is just another tool, right? Like, I don't think the tool needs to be defined. It's almost, as we're measuring right now, the worth of a designer through the shortcuts that they know in Figma, right? That's not what the design is supposed to be about. I mean, I. I have no idea how many times I've seen designers coming into the office hours with components that are not part of the design system. And if we're telling them to use the design system, they think they're not creative anymore. I'm like, creativity doesn't come from building the UI. Creativity comes from how you're solving the problem.
That's what being a designer should be. And I don't really know where the problem starts. I don't know if it's the job descriptions, if it's the organizations lacking maturity when it comes to design generally, not just design systems. I think more people need to come from design background into, like, higher executive roles to help to push for these and help other people understand the depth and the amount of work that is required to build something like this. And I'm opening a can of worms by saying this, but I think it's also bootcamps, right? Like, it's kind of like a chicken or the egg situation. I don't know if it's the organizations and the corporations that are pushing for a specific type of designer, or if it's the bootcamps that just kind of like, just pushes out those kinds of designs. If I look at case studies over and over again, and when I mentor people, I see the same thing all the time, the same structure. And every single case study almost finishes with the idea of usability testing and with design systems finishes at Figma.
Jared Spool had like, a really cool quote. I can't remember it. Exactly. But he was saying that basically design needs to match the intent, and the intent is always in production. It's not what is in Figma.
Chris Strahl [00:14:38]:
Absolutely. We often talk about that at Knapsack, actually, where the idea of users don't see Figma files, users see HTML and CSS or an iOS app. And in that case, like what you make in Figma. Yes, it's important, but it's an intention. It's not the actual thing that a user sees a lot of. Again, echoes of what I've been hearing throughout the day. When you think about the idea of how design is changing right now, I think that there's this notion in design that you have to deeply learn your tools to be able to hone your craft. Hence their salary is based on how many Figma shortcuts they know.
Like tools are religion in terms of design. It's crazy how like so attached people get to this particular system or this particular way of working and contrast that to say, engineering, where in engineering the frameworks change and the tools change all the time. I think I'm on my 7th or 8th ide at this point. I think that the rise of react has been somewhat remarkable. But there's a bunch of other frameworks and there's a bunch of other stuff that's coming next. The idea of where this is all headed is, you know, design has this challenge that is laid in front of it right now, where people that are going through boot camps, they're going through design school, or going through an early part of their work, like they have a way of working that they've been given. Engineers are very used to. Like, I have this way of working, but I need to constantly be learning new things and new ways of working and trying out new tools, and shuffling my tool stack around and my workflow around design.
I don't know if it's ever had to really do that in this same sense. And I'm curious your thoughts on this, because iteration is happening way faster in design now than it has maybe ever. With AI, with lots of web based tools, with design systems, with all these different structures that are being put in place, that are moving it closer and closer to code. And the reason why it's moving closer and closer to code is we all understand that that's where end users are. But how do designers need to adapt in order to be able to make those transitions? Because the answer can't be like, let's fire every designer and organization every six months and then rehire them once they've skilled up on their own dime.
Catalina Mina [00:16:40]:
I'm trying to think if it's new, right? Like AI is definitely new. But when we talk about design systems or technology and the overall collaboration between design and development, I think that's been around before I was even a designer. Right. So it's not new. I'm not sure exactly how things were done, to be honest with you. And I know, like everyone is very stuck on this idea of agile. I personally love agile as a designer, which I know is very uncommon because designers, they don't like working in sprints because they put a lot of pressure. Things have to move a lot quicker.
Researchers hate working in sprints, and it was very rare when I came across researchers that actually tried to work in sprints because it's very difficult for them to slice up the work. One of the things that I think designers need to do is learn to be more adaptable. There's things in design that we keep talking about and we don't do it ourselves, which I also think is very wrong.
Chris Strahl [00:17:35]:
Like what?
Catalina Mina [00:17:36]:
I'm not a fan of design thinking at all. I don't enjoy it, particularly because we keep bragging on this idea of empathy. And to really feel that level of empathy, that design thinking is stressing it, it means you have to be really close to the user. I don't think we're that close to the user. We don't understand the user. A Persona is not enough. It's a generalization. It gives us a perspective, but it's not the user.
When I used to do like just ux product design, I used to also do some research. I wouldn't call myself a researcher, but I used to do like observational learnings and contextual inquiries. And I loved it because that's what actually gave me the perspective on the day to day and the things that the user needed to go through. And I was growing to be sympathetic through the day to day and the things that the user needed to go through, but I wasn't empathic. I'm not going to say that I've ever felt empathy and felt so sorry for the user that I had to go back to the screen and start designing something right now. I was coming with the data and I was presenting it to the company in a way that they would understand it and it would make sense for the audience. But I personally was never able to reach that level of empathy. So I don't think it's real.
Like when we talk about design thinking, we're starting on the wrong, fought with empathy.
Chris Strahl [00:18:58]:
Big takes like, I don't believe in design thinking are always interesting because there's always, like, an explanation or some, like, you know, deep trigger there that's happened. I think that for this, like, the interesting part of that to me was this idea that, like, you know, oftentimes designers think they're closer to the user than they are. And there's a lot of the ways that this plays out. One of the ways that it plays out is, you know, thinking they understand user needs, but not really. And there's a lot of design systems y stuff we can get into there.
Catalina Mina [00:19:25]:
Yeah. So, like, we are talking about empathy for external users, which is the user that utilizes the day to day products that we're building. Right. When we're talking about design systems, we have two different types of users. We have the internal users, and we have the external users, the internal users. We're talking about design development primarily, but you might end up with QA. If we're thinking about complete design system as a product, we have product. So I think design always wanted a seat at the table, and we always try to sell the story through our perspective and sell our process without fully getting a deeper understanding of what the developer has to go through or what is their environment or what product has to go to.
Even have a project lined up and approve projects for some of these projects. Right. So when we talk about empathy for the user, but we don't have empathy for our coworkers, it really just, I don't like that.
Chris Strahl [00:20:20]:
I struggle with that concept. Yeah, I think it's interesting because it's like the same idea of when Figma releases a really cool feature. One of the first things that I scrutinize associated with that feature tends to be like, what does this look like in code? Auto layout is probably the perfect example. Auto layout still does not behave the same way that HTML and css behaves to some level. That's okay. There's two different mediums. But I think that there's this idea that, like, because I can do auto layout inside of Figma, can't engineers just do that same thing?
Catalina Mina [00:20:53]:
No, they can't.
Chris Strahl [00:20:54]:
It's not the way it works.
Catalina Mina [00:20:55]:
No, it's not. And even our designs, like, we're building the designs in Figma and we want to build, like, really cool stuff. If we're doing it for just like, showcasing things, I think that's fine. But if we're doing it to sell our designs, because we're also sellers, like, essentially, designers are salespeople, then it needs to be translated for the final consumer, which in this case would be the developer.
Chris Strahl [00:21:20]:
So how do you personally approach that? I'm curious about how you look for that empathy inside of the people you work with.
Catalina Mina [00:21:27]:
I'm not going to say that I'm perfect. I think there's times when I could have done better, but I like working with developers as early as possible in the process. I feel like sometimes I struggle if the company culture feels very rigid, I struggle doing the first step. But historically I've been trying to find kind of like team influencers and like the loud voices of the team and try to partner with those throughout my process. It also gives me a level of comfort, especially in remote environments, being able to reach out to someone if I have a question. Through my experience, I came across more pushback where I waited for my design to be showcased at the end where I was done. Kind of like the big bang, right? Shocker for the developer. Where the heck is this coming from? We can't do this versus if I bring them along.
I was lucky enough that when I started indesign, I was part of a team. We used to call ourselves the misfit toys and it was like the most. Yeah, I'm not kidding. Yeah, it was probably one of the most diverse teams as far as roles that I've ever been part of. We had software architects, we had agile coaches and designers. And the reason why we were structured this way is because we were all brought in in the beginning of the projects. And I think that's why I'm shaped this way with the mentality that I have right now. It's because of all of these people that I was surrounded with.
That's why I'm also into agile. So we used to do like impact mappings in early stages of the project, which is kind of like a tool in agile to help you define the problem. And we used to have in the room anyone from product to also development or software architecture just to kind of get a perspective on the problem, the solution, and is it even feasible? And we're not talking solution like pixel perfect. That was again the output. It wasn't the input. The input was the information that we're coming out from that room. I like also to set up frequent checkpoints with the devs as much as I can. And I like working in cultures where like you reach out to people on slack or like any other tool that companies might use and people don't take 24 hours to respond.
I get it, we're all busy, but it's almost as walking to someone's desk, right? Like, you should be able to answer a question and not be blocked the entire day when you have to do something.
Chris Strahl [00:23:48]:
Yeah, totally. I think it's interesting, right? Because so much of this is about that empathy stuff, right? Like, empathy is a two way street, and you having empathy for the people that have to take your designs and transform them into product, and likewise trying to field ways of building empathy for your position. And I think that's a really interesting kind of way of looking at it. I don't know, I'm starting to think that maybe design thinking does have a place.
Catalina Mina [00:24:11]:
I mean, I'm kidding. Yeah. I don't know. Like, I think empathy is such a deep word. I actually have an article about it on medium too. It's tough to reach a deep level of empathy. I like. Even right now at my current job, I'm trying to understand the dev environment as much as I can.
And we're definitely more connected on how we work together than other places where I've been before. But it doesn't necessarily mean that I feel complete empathy, but I understand it, and I understand enough to know when and how to insert myself. And I think that's what's important. I think design thinking would have more feasibility if we somehow plug it into agile and into the devs process and we actually show how it would work. And if we scratch off that empathy word, I don't know, I'm just really hung up on it and I wish we could change it.
Chris Strahl [00:25:02]:
Well, we'll leave it at that. Thank you so much, Catalina, for being on the show. This has been a blast. Really appreciate it.
Catalina Mina [00:25:07]:
Thank you so much.
Chris Strahl [00:25:08]:
This has been the design system podcast. I'm your host, Chris Strahl. Have a great day, everyone. That's all for today. This has been another episode of the design Systems podcast. Thanks for listening.
If you have any questions or a topic you'd like to know more about, find us on Twitter dspod. We'd love to hear from you with show ideas, recommendations, questions or comments.As always, this pod is brought to you by knapsack. You can check us out at Napsack Cloud. Have a great day.