On Theme: Design Systems in Depth
Exploring how successful design systems get built, maintained, and deliver impact for their product teams. Go deeper than tokens and get more detailed than "it depends". Expect aha moments, actionable insights, thoughtful discussions, and spicy takes from accomplished design system practitioners. Hosted by Elyse Holladay.
On Theme: Design Systems in Depth
Help, I'm starting a new design system job! with Amy Ogg — #11
📲 Text the show your thoughts!
This one’s a little bit different than some of the projects and topics that we've had on the podcast so far — we’re talking about starting a new role. I think it's one of the hardest things that we do sometimes as design system practitioners, because the design system is really about changing your organization, changing the way we build UI, and so there's a lot of weight on your shoulders when you come into a new role.
Starting a new job as a design system practitioner can feel exciting and terrifying all at once—but Amy Ogg has some insights to help us navigate the emotional rollercoaster. Amy and Elyse chat about how to spend your first 30-60-90 days, building genuine trust, and why making big changes as a new hire can actually backfire. They commiserate over balancing the overwhelming backlog as a small team, and Amy shares why she thinks cross-training outside your expertise is a must. Plus, Amy shares how her experience as a barista shaped her approach to UX design ☕️
💖 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
- Amy Ogg on LinkedIn
- Desire paths in UX
- Amy’s article on how starting out with research and understanding users can help shape effective design systems on the Design Systems for Figma blog
- Your first 90 days in a UX design role by Christopher Nguyen
- The First 90 Days (original book) by Michael D Watkins
- Into Design Systems Meetups - Seattle, USA chapter
- Will Larson's book Staff Eng
🎨🎟️ 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.
It's counterintuitive, because you want to gain everyone's trust, right? And you think that by being the subject matter expert, or by, I am the person to come to for the design system guidance, I will help you, I will support you. We want to gain that trust, but we can self sabotage, in a way, just by wanting to earn trust and then, I think, trying too hard. By thinking that, oh, they'll trust us if we're the go to person, rather than meeting people where they're at. And you can't really meet people where they're at unless you take the time to learn about them. Really on every level, I think, the way that trust actually can, least how I have seen that it can be gained, is by being human. By being approachable, by being there for people. And by being honest, like when you don't know something, I'll look into this, I'll research this, I'll report back.
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 show, we've got Amy Ogg. She is a Seattle based design system nerd, and coffee lover. She is currently working at Therapy Brands, shaping their new Mindful Design System. She serves as the Seattle chapter lead for Into Design System meetups, Mentor Team Lead at Iterate UX and provides design mentorship at the University of Washington's iMentorship program through the iSchool. In her off time, she goes roller skating along the Seattle waterfront, plays the flute, and makes craft coffee. Amy, thanks for coming on the podcast.
Amy Ogg:Yeah, thanks so much for having me, Elyse.
Elyse:You are so welcome. So, I'm really excited because we're going to talk about something a little bit different than some of the projects and topics that we've had on the podcast so far, and that is starting a new role. I think it's one of the hardest things that we do sometimes as design system practitioners, because the design system is really about changing your organization, changing the way we build UI, and so there's a lot of weight on your shoulders when you come into a new role. So we're going to talk about, how do we get our bearings? How do we understand what needs to be done? How do we set ourselves up for success on a new team? So let's just dive right in. You are about to start, okay, you're not literally about to start a new job. Theoretically, you are about to start a new job. Tell me where you are at emotionally. Tell me what's going on. Tell me the things that you were thinking about leading up to first day in a new design system role.
Amy Ogg:Yeah, oh my gosh, such a good question. I feel like when I'm about to start a new role, it's anxiety. It's anxiety on every corner, all around me. And honestly, it's because we care, right? We care about our work. We care about the people we're working with. We care about the impact, how we're leaving things. I think everyone is coming to a new role from a very different standpoint. You could be leaving your previous job, where you had really great relationships with your manager and your coworkers. And it's that bittersweet, like you're excited for the new role, but also anxious about how you are leaving things. You know, maybe you've been laid off for a long time, so you're excited, but also it's such a big adjustment and change. It's been months since you've been in this routine of things, and regardless, it's a new team, a new culture, new everything to get adjusted to. Also, you could be leaving a very toxic work environment, and just be ready to leave all that behind, and onto new challenges. So I do feel like every time I start a new role, I have so much anxiety, cause I want to do a good job. I want to make an impact and impress people. But also, I want to leave my previous company in a good standpoint. Last June, I started with Therapy Brands, it's practice management software in the mental health space, and I'm building the design system over there. And when I was leaving my old role, I felt all that responsibility of like, I need to prepare documents, and videos and stuff, for the person coming on here, to understand our design system, because there's no one else in place to show this to them, to walk them around. So I felt like all that responsibility, also of course, the excitement of, hey, it's a new space. It's a new problem. It's new challenges. I can't wait. And then also the trepidation of, it was going to be the first time I worked on a massive multi brand design system. And that's very different from white labeling design systems or working on a very established design system. So I felt a lot of anxiety about that, to be truly honest. I was wondering like, am I the best person for the role? Sure you go through the interview process, but you start like doubting yourself. And for me, a lot of this came down to mental prep, and laying out my plan before starting. And it was twofold, that exit plan for my previous job, and also the entrance plan for my new job of, what are the goals that I want to make? What's that splash and impact? And a lot of that was coming from some insights I had through the interview process of the direction this design system is going. But it's so interesting, because like anytime we start a new project, or work on a product, we start with this empathy for the people we work with and empathy for the customers, the users of our design system. But at least for myself, I can lack empathy for myself, and really just push myself into, you have to perform, you have to like, do a a good job and not let them down.
Elyse:And show up in this perfect way.
Amy Ogg:Yes. And I think it was a good lesson for myself this go around, where I was like, you also get to have empathy on yourself, and like, sure, make your plan, but don't push yourself too crazily.
Elyse:I love so many of the things that you mentioned here, all the different ways that you could be feeling coming into a new role, depending on where it is that you've been coming from. And I was just laughing to myself as you were talking, because I was like, I've experienced all of those things. Leaving the toxic job, being unemployed, starting something new and being excited about that, but also very scared because I've been out of the game for so long, leaving somewhere really good and being sad about it. I had a coach one time that would say, the feeling that you want to be feeling, is scared-cited, like it's not just scared. I know. I love that too. That really stuck with me, because it's like, if you're not a little bit scared, it's probably not going to be challenging enough. If you're only excited, it's like, too easy. But if you're only scared, then something is not really aligned. And that moment of scared-cited, where it's like, Oh God, can I really do this? Am I really going to show up for this? Like, hell yeah, I'm really going to show up for this. Oh God, I'm really going to show up for this. The way that I have seen people screw this up the most is, and the way that I have tried, have screwed it up for myself the most, is, I am going to make this massive change on day one. Like I'm going to come in here and I'm going to get everybody doing something different and like, be throwing my opinions around. But that's mostly just a way to alienate other people and stress yourself out and not actually getting anything done. So how, how are you starting? Like it's day one, we've we've got all the anxiety going, but we're really excited. We're scared-cited. How are you actually diving in? Like first day you show up, obviously you set up your computer, you do all the HR paperwork, like blah, blah, blah. When it actually gets into talking to your teammates, talking to your managers, talking about and like understanding the project, walk us through, what are some of the ways that you approach that first week or that first month?
Amy Ogg:Yeah, I think you hit the nail on the head there, of just like needing to set aside that time to listen. I'm somebody who can talk a lot. So I constantly remind myself, be quiet, put the microphone on mute, just listen, just observe. And I love to talk about it as UX-ing the process. Just as like a life mantra, really. But however that is applied, whether it's work, whether it's life, whether it's friendships. That like, in the design framework, we have that understand, observe, research, empathize, as step one. That's how we get our bearings. That's how we understand the problem space, and can be set up well for success, rather than just making assumptions about like, oh, they need this for their design system. This is what I think they should have there because that's what my previous company had or whatever we want to throw onto—
Elyse:That is so, I had a, one of my managers say to me your past experiences are informative, but not instructive. It's so easy to assume, I saw it done this way, or I like this, or I prefer this, or I expect this to be the case. And then just forget to pay attention to what your team is actually in need of.
Amy Ogg:Oh, 100%. And I think it can be hard, because you're in that situation of like, people are looking to me for guidance, so I need to provide guidance. It's okay to set that space aside and just think and make sure you're giving good guidance. And not just giving them what they actually need, not what you think they need.
Elyse:Especially, I think, on a design system role, you are there to give that guidance. And people are going to come to you and they're going to ask questions. And I feel like it's one thing to be like, yeah, here's how to, here's how I do this in Figma, or here's how I do this in styling or CSS or whatever. And it's different to be like, oh, we need to change the way that we do this process, or we need to change the way that this component functions, because that's how I've done it before.
Amy Ogg:Yeah, exactly. Are we just adding unnecessary noise and solutions that don't have a problem? Or are you, are we actually solutioning for an existing problem?
Elyse:What do you think it is that makes us so desperate to do that kind of stuff at the very beginning? It's always the first like month or two or three, right? I think once you settle into the job, some of that kind of settles down, because you get into a better understanding or whatever, but what is it that we are feeling and doing in those first, in those early months, that makes us feel like we need to go throwing our opinions around all over the place?
Amy Ogg:It's counterintuitive, because you want to gain everyone's trust, right? And you think that by being the subject matter expert, or by, I am the person to come to for the design system guidance, I will help you, I will support you. We want to gain that trust, but we can self sabotage, in a way, just by wanting to earn trust and then, I think, trying too hard. By thinking that, oh, they'll trust us if we're the go to person, rather than meeting people where they're at. And you can't really meet people where they're at unless you take the time to learn about them. Really on every level, I think, the way that trust actually can, least how I have seen that it can be gained, is by being human. By being approachable, by being there for people. And by being honest, like when you don't know something, I'll look into this, I'll research this, I'll report back.
Elyse:That's such a great piece of advice. You're so spot on to say that it's about trust. So there's this thing called Benjamin Franklin effect, this is a cognitive bias, and it's basically like, if you ask somebody to do a small favor, the person actually likes you better. Which is so—
Amy Ogg:I love that.
Elyse:—backwards to what we think. We think, oh, if I have the answers, if I am right, if I can show this person, I'm smart, then they're going to like me. But something about that balance of, oh, I need help, or I'm trusting you, I'm showing a little vulnerability towards you. Or just them taking the time to do something, actually produces a lot of positive feeling towards you in somebody's mind. And I just, I love little, I don't even want to say tricks, it's not like a mean trick on somebody. It's just a little psychological awareness that people are complicated. Brains and our interactions are complicated, and coming in and trying to build trust by all these little ways, like asking questions, asking for favors, doing favors, taking time with people, rather than just showing up and trying to be an expert, I think can be really powerful.
Amy Ogg:I like that, the Benjamin Franklin effect. Because honestly, it feels good. We like helping other people. So it makes sense that also they like to help us. It's very human. And I think that's the whole piece of this, is that we're not just robots working together mindlessly. We are, we're humans. In my new job, it is remote first, all of us are remote. And so I think it becomes, really important to foster those positive working relationships, and get to know each other as humans as well. Because we aren't in the office, we aren't next door where we can just chat over lunch. You have to put a little bit more effort into that to get to know people.
Elyse:Yeah, you really do. So little side note on that. What are some actual, specific things that you have done, starting this job that's fully remote? Ways that you're doing that, ways that you're trying to make connections with people.
Amy Ogg:Yeah, I mean, week one, you have all the like onboarding and stuff like that. And it also gives some good time to schedule meetings with people and get to know them. So I met first with my manager and I was like, okay, tell me where things are at. What is the long term vision? What are the problems we're having? Just like, digging in deep into that to really understand, okay, from management and leadership perspective, what is this problem space that I'm diving into? And then I would start taking notes and ideas. And then from there, meeting off with the designers on the design team and diving into, what are pain points for them? What's working well for them? Can they show me around? It was really fascinating to ask everyone, what is the single source of truth for the design system? Because, depending if it's a designer, an engineer, you get a different answer from everybody. But it's insightful because that is their truth, right? Yeah, I mean, after that, I work really closely with the front end engineer. So we're a design system team of two. Small tight team. And so, met with him just, I honestly, we had chats about the design system, chats about life, getting to know each other. I work most often and closely with him. So I appreciated that he was just like so open and such an interesting person. Sometimes it can feel very forced to get to know someone. And we were just like, hey, we have this in common, oh cool, music, oh, cool, like these random hobbies that we have.
Elyse:You're vibing! Because you really don't know. Like here's this person that you didn't get to pick. And you have to figure out how to have a relationship with them. And it's just such a joy when there's vibes and not just like professional, like, okay, you're fine.
Amy Ogg:100%. I mean, I've definitely not always had that luck in my history. So I appreciate it when it's there. Especially like when you're working in such close partnership with people. Sure, it's fine if you just have different relationships in different spaces, and you can still work well together. But when you jive really well, and sometimes you're like, hey, we're just chatting, because we have all these cool things in common. But it really does strengthen that bond, and that working relationship between each other. I really appreciate that. He's, He's the best.
Elyse:Love it.
Amy Ogg:And then I also met with the POs. We don't have a designated PO for the design system only. There's multiple POs, that were managing it at the time, and so met with them to just understand their tools, their workspace,pain points they're having, which were a lot related to process and bugs and prod defects and that sort of thing. So it was really interesting to meet with all these different people and get some ideas of where the primary pain points were for all these different groups. And then I could start outlining a strategy for okay, where should I start with all this? What are good things to put on the road map?
Elyse:Yeah. Yeah. Yeah, so what do you do with the content of all of those interviews that you had, all those conversations? You said you were going to put it together in a strategy doc?
Amy Ogg:Yeah. So, I mean, it started out with just notes, and then I compiled those into a doc, met with my manager to just review things, because at the time there wasn't really a design system road map. So, wanted to align with her on, where does all this stuff fit in? How do we prioritize it? What makes sense? Does this align? Because there are certain things that I'm really excited about that don't necessarily get prioritized. Or something I'll do on my own time to just, get things done.
Elyse:Spoken like a true team of one or two.
Amy Ogg:Yes
Elyse:So that actually was a question that I had in my head while you were talking. You said, at the beginning, the first person I meet with is my manager, and I'm asking them about long term vision. And a lot of the folks listening to the podcast, I think, are, senior plus, staff plus, directors. I think for a lot of us, that long term vision is up to us! And it's very different when you're coming in as a junior person, a junior designer, a junior engineer, on a product team or even a design system team, where you're just like, I'm here. I do design. I do code. What's the plan? What are the metrics? What are we doing? Where's my ticket? Like my PO, my product manager, is going to write me a ticket. How do you approach it when that long term vision is up to you?
Amy Ogg:It's about aligning that long term vision also with what leadership wants. So my manager is the director of the UX and UI program. So she's making a lot of those big decisions. So for me, it's pitching that upward toward leadership of, hey, here's what I'm thinking. Does this align with what you've told me and what's coming? Is there anything I need to be aware of to fit into this strategy? Here's where I've identified as a good starting point, does this make sense for how we are preparing ourselves for what's to come in the next year?
Elyse:Yeah. I've been saying a lot on the podcast, we need to remember that design systems are about serving our product. And, it sounds obvious, but that's what you were just talking about, that's exactly how we do that. And it also sounds obvious to be like, well, of course I'm going to go figure out what the team is working on and, and try to relate to that. But the actual doing of it can be quite challenging, because you're listening to your design director, or your engineering director, your leadership and they're not talking about the design system. They're not talking about components or tokens or the color scheme or the React code. Very unlikely that they're talking about their vision at that discrete and tactical of a level. I'll use our CPO as an example. She's been talking about consumer grade UI. We're building now for consumers in a way that we weren't, a year or two ago. And so how do you take something like, okay, what is we need more consumer grade UIs? Those are the kinds of things that you're going to hear your engineering or design leadership talk about. Translating that into, here's things that the design system can do to serve that, can be a real challenge.
Amy Ogg:I totally agree that translating, that's where the real magic happens. Because they're stating goals, and then you're seeing like designers, engineers, product, all these different areas have pain points. And how do you take the goals and the pain points, and put that together into like, hey, this is highest priority for us. Aligning to some of those company goals helps a lot too, like this has already been standardized, it fits into the performance goals. So that can definitely help give some direction there. We don't have many metrics yet on the design system just because it's new. So we're, setting some of those metrics. For example, we didn't have a governance or contribution model in place. So it was like taking from zero to, hey, now we have something in place. Then putting tooling in place to allow us to track some things like adoption. For example, when I started, I started with some competitive benchmarking of different platforms like Zero Height and Supernova and Fig Mayo, to see about a doc site platform, but also what can we get, bang for the buck, of what it is supporting. We've loved that Zero Height had versioning, and they released their new adoption metric tracker late last year. But yeah, it's been like putting that stuff in place so we can measure. Starting off with some research, so we have a baseline of where we're at now to measure against in the future.
Elyse:Yeah, for sure. And how are you talking to your manager and to your leadership about how those relate to the long term health of the design system, but also to their goals? I don't know if you can give any examples. But I know that this is a thing that people struggle with so much, is, I know that this is important, how do I talk about this, in a way that, you know, my manager or our leadership will really understand.
Amy Ogg:Yeah. One example I can share is adoption across products. So we're multi brand, we have 13 different products, but right now only four are consuming the design system. So like one recent win was getting our fifth product, over in the enterprise space, to adopt our design system. And that aligns to the company goal of unifying all these different brands, and going from the concept of, hey, we're a house of brands, Therapy Brands, to a branded house. Again, going back to what we were saying about trust, some of that also moves upward where, when you establish new processes, and that allows for quicker workflows, and we're able to stay ahead of components and changes, and address bugs, and have all this really serving the teams that are consuming it, those people are also passing that along. Hey, it's working well. Hey, we like this. Usually I see it as a good sign when we get lots of requests for snowflake components. Because the engineering teams are seeing that, hey, this was great. It's all built for us and ready to go, and we love this. Can we do it for everything? So, it's, I think also getting our brains to that long term alignment of, adoption looks really great right now, but how do we maintain this long term, as more and more products start consuming this design system? And we need to support them and we're spread more thin. Also everyone's hyped up and ready, they want to adopt and they're excited and they see the impact. How do we maintain that and support that and not let that die over time?
Elyse:That's such a great connection of adoption to a business goal. It is no secret that I think adoption is an overhyped metric, but that's literally, I think the perfect use case, is like, we have a number of products, they're all different. We're trying to unify them from a visual perspective, maybe from a code perspective. And adopting the design system is a way to do that. That is what the adoption metric is for. At Color, we have a monorepo. And that's like, adoption, I'm like, yes, 100 percent, the whole monorepo. So that's a wonderful example. Okay. So back to our, our little story here, one of the tools that I have found really, really valuable when starting a new role, especially a new role where you're trying to provide some vision, some leadership, is ye classic 30, 60, 90. For those of you who are not familiar, I don't know, I feel like surely everybody knows about this, but if you're not familiar, a 30 60 90 is a little plan that you write up that's like, here's what I'm going to do in my first 30 days, my first 60 days, my first 90 days. The typical framework tends to be, first 30 days is listening and learning. 60 days is starting to contribute, but not trying to press your opinions or make big changes. And 90 days is starting to really move into, here's the direction that I'm trying to set. So, we've done our 30 days. We've done our listening. We started to write that up and we're starting to form opinions. And I think that's one of the things that makes those first 30 days or that listening tour so valuable, is it helps you form opinions. There's a guy, Will Larson, who wrote a book for staff software engineers, this book it's called Staff Plus. I love this book. And in it he basically is saying, at a staff plus level, the opinion is the job. Like when you are in a role like this, the thing that you have been brought on to do is have a really informed opinion. So, Amy, tell me about that moment, when the new job starts to shift, because you have started to develop that opinion, and you can start turning your attention towards actually changing things. Like somewhere in that 60 to 90 days where you're like, okay, like this is what we're gonna do. I'm laying out the plan. When does that balance start to tip for you, and what is that like, and what are you starting to do?
Amy Ogg:Yeah. It's funny because I didn't actually track. Was it at the 60 day mark that the balance started to tip? I had some opinions before the 60 days. And then after 60 days, I still felt like sometimes I was in that 30 day of listen and learn. So there, there Not, exact, yeah. But yeah, I feel, in, in between that, like 60 and 90 days, just, with all the information and insights that you get from your coworkers, your partners. For me, I was setting the roadmaps, setting these different prioritization of like my work and how it's going to align to the product roadmap and the features that are coming out. And I felt like that also shifted. So sometimes you'd be working and rushing to get something ready, and then just kidding, there's a pivot and everything changes. So just the nature of how design systems are supporting the products that are consuming them, I feel like there is a lot of that shift. So sometimes I felt like, I should be a lot more opinionated right now than I am, but I still feel that I am learning and consuming all this understanding, getting my bearings. Also, you start getting a feel for culture, the different personalities that you're working with, and the different problems that you have. I would use like design critique as a testing playground for a lot of my ideas. I actually copied the Figma design system file. And I was doing a bit of an information architecture overhaul and how stuff was aligned there, and tested that with the designers to see what they thought. Do you like version one or version two? What would you recommend changing? What's working, what's not working? And this was all informed by those one off conversations of, what's your experience, and seeing how designers were using Figma. Like literally some people were coming to the Figma file to copy the component. And it's, okay, there's an educational opportunity here for like, how to use assets, how to use instance swaps, things like that. And that kicked off more ideas of, okay, let's get a weekly design system meeting on the books, where people can meet, make contributions, requests, questions, and get help. Our weekly design system meeting is just between designers and engineers. We do incorporate design system stuff with product in other meetings, but for this one, just between design and engineering. And then opportunities for office hours and stuff like that. So, I feel like I'm rabbit trailing here, but that's honestly how my brain was at 90 days. I felt like it was addressing different themes that I was seeing come up, and then testing out these ideas with the team and seeing what worked. It was really cool to see how things would snowball from there. Like the information architecture changes made on the Figma side resulted in an overhaul on Storybook, because product and design were like, oh, we like how things are working over here in Figma. It's really easy to find stuff. But we struggle when we come to Storybook to find, under data display or feedback or input, like where the components are at, and what resources are available.
Elyse:That's very accurate. I do think that 60–90 day period is when all the, all these like windows of opportunity open up, because you're really starting to see not just the big overview, but really getting in the weeds with people. Like, oh, my god, like it very much is because you're opening all these horizons and really understanding, what is it that my team actually needs right now? We touched on this in the beginning. It's so easy to come into the new role and go, well, in the interview, they told me they want to scale the design system to all of these brands. So therefore, we will, do a custom token architecture and we'll do theming and we'll do this and we'll do this. And then when you actually get in there, like the goal is still the same, but the things that you have to do are suddenly like, oh, it's not any of that stuff. That's really the moment where you start to see, the truth. The real dirty laundry.
Amy Ogg:Yeah, yeah, exactly, it's, born out of all that research and digging and conversations. And then, yeah, you really see it for, for what it is. I feel like sometimes when you first join a company, you can be like, oh, things are like set up well, and this is great. And then you pop the hood and look underneath and realize, oh, here's all the opportunity. Here's the challenge.
Elyse:That's a much nicer take than I was like. It's no, here's all the opportunity.
Amy Ogg:Some of it's very, it's very very ugly, but it is that opportunity to make it good. I've worked on design systems that have been really established, and then others that I've built from the ground up, but it was new for me to come into a situation where it's a fairly new design system, but I'm not actually part of it being born from the very beginning. So for me, I'm like, oh, there's components in the wild, okay, cool. Like, it's, it's off the ground, it's in flight. But then you pop the hood and look at the dirty underbelly of, oh, there's variables and tokens in Figma, but those aren't existing in Storybook. Okay, if we want to scale this, we need to get tokens in place. We're looking at primitives first. And identifying like, this isn't working, but you know, what is an educational opportunity and what is something I can fix? I had mentioned designers coming to the file to copy a component instance and pull it into their file. But part of this was because like—regardless if a designer knows or doesn't know abassets—the way that components were named, if you're searching in assets and you can't find what you're looking for, that's frustrating and you give up. Or if library updates are not being published and kept up on, you're going to come to the library to get the most updated version of what you need. So unraveling all those things of, oh, designers have modified their behavior because of this, and here's how I can better serve them and support what they need to make their workflows work better.
Elyse:I love this focus on being like, hmm, what are you doing? Why? Why are you doing that? I'm very curious why you're doing that.
Amy Ogg:Yeah.
Elyse:How do we make that better for you? And sometimes the answer is not by setting it up the way that every Medium post about design systems will tell you to set it up.
Amy Ogg:It makes me think actually of that, meme, you know, of UX. Here's the path, and how the neat little path is laid out, and here's the actual path that two people are taking.
Elyse:Walking across the grass straight to the bench.
Amy Ogg:Exactly. This is the shortcut that they found, and they've created their own path. So it's like, how do you just meet them where they're at? And designers think very differently from engineers. So also trying to be that middle ground person of, like how we're going to name these props and how a component is built in Figma to make sense for engineering handoff, also makes sense for designers. Another opportunity that I had discovered was adding component level documentation in Figma. Like, yes, we have documentation via the specs, and we have a Confluence documentation, there's stuff in Storybook. But depending on, if you are a designer, an engineer, where you're going to go to look for that documentation is really different. And for designers, they're using an instance of that component and then they would come and ask me like, oh, well, what's the details on this? And if we can cross link and make this like an ecosystem of, hey, you can click on this link, hey, it's all there about what you need. It's fun. I love unraveling this.
Elyse:So wise. We are always changing people's behavior when we introduce things. People find those desire paths. They find the ways that make sense to them. They find easy ways to do things. And those are the really juicy parts of design systems in my opinion, because you really want to say sometimes, don't do that. Don't go in that Figma and copy that. That's not how you do it. That's wrong. Here's the process. But the reality is, they're going to do the thing that is easy or that makes sense, or that is functional for them, or that is fast for them, or comfortable for them. And you can't just go in there and say, this is the right way to do it, so now you have to do it this way because I said so. Often design system teams have gotten kind of a bad rep for being just like that. Being like, okay, whatever you are doing now, you've been doing it wrong this whole time. And we're going to come in here and tell you like, here's the new process.
Amy Ogg:We talk about are design systems a product or a service or infrastructure? What are they? Well, it's all three, like, like, sure, it's a product. Also we're a service. Also, we're infrastructure, but like, how can you be it all?
Elyse:And we wonder why we get burned out sometimes. But truly I think that's the beauty of this space, is that it's a very generalist space. It is a little bit of everything. It is not straightforward. I think this is the biggest failing of design systems is that you can read a guide and it makes it sound straightforward. First build tokens, then build components, then shake it really hard and efficiency falls out. And it doesn't really work like that.
Amy Ogg:If only it was that easy.
Elyse:Oh, it would be so boring. No, it would be boring.
Amy Ogg:It would be.
Elyse:Speaking of it not being simple, we were just talking a minute ago about the opportunities, right? Like lifting up that hood and being like, oh, here are some juicy, ugly opportunities that I can, you know, dig my little fingers into. How do you, especially when you are relatively new, I'm gonna say like within your first year. You maybe have already done a lot. You've put a vision in a place. Things are moving. You're shipping some code, you're making some designs, you're doing stuff. But there is still so much to do. There still is so much opportunity. There's a sensation of like, Oh my God, there's so many things and I'm never going to get to them all. And how, how do I, how do I even succeed? How do I actually make a dent in this giant pile? How do you balance that? Cause this is purely an emotional state, right? There's always more work to do. But how do you balance that, like, oh, there's all this opportunity, versus Oh my God, there's so much to do, I'm overwhelmed, I'm failing, and we're never going to actually make a difference here.
Amy Ogg:Oh my gosh, I'm in the throes of this right now. So I'm, yesterday was eight months for me.
Elyse:Congratulations.
Amy Ogg:I am in that first year.
Elyse:Yes, you are in it right now, aren't you?
Amy Ogg:Uh, yes. You're like, that high of like, yeah, we, we made progress! People are liking this, things are going well. And then you hit the valley of like, oh my gosh, the backlog. And the things I keep finding. And then every time you look at one component and then you realize, gosh, like, you know, documentation wasn't written for this component that was existing before you joined and like, this needs to get updated. And you talk with the engineer and they're like, actually that component is using something third party and we need to totally[laughter]. And it just starts like snowballing. And I can say, I, I haven't always handled that the best way. Um, Sometimes I, I work really long days, because I like what I do. And when, when you get to work in like a creative field and it doesn't feel like work because you enjoy it, you find that like, oh, I'm fascinated by this problem, and I just keep working. So for for me, it's been trying to find that balance of when is it good to just say, okay, and that's going to stay in the backlog, and I'm going to go get some personal time.
Elyse:Yeah. There's, some times things just have to stay in the backlog.
Amy Ogg:And it's hard to, it's hard to let the backlog rest sometimes because you see how huge it is. I mean, honestly, I feel like it's different when you've been at a company a while, you can be pretty certain of like, here's what I can handle by myself, versus here's what, like, I need buy in or, uh, this needs socialization, or something like this. I feel like when you're newer in a role, you're not really sure. I felt like I was going so often to my manager and asking, like, here's what I think. Do we know yet? Does this exist? Has it been socialized? Have there, you know, you don't know the history. And sometimes you get nice surprises of like, hey, we have this documentation. Hey, this, this thing happened. Here's the recording, which, you know, it's really helpful. Then you can educate your own self. And then other times it's like, this is a great opportunity. I need to focus on this and it's a big effort on my side. Or it's something that we need buy in across multiple different sectors. But related to that, we were talking at the beginning here of like creating relationships. That's been something, uh, super beneficial for our backlog. Our engineer is my best buddy, and he is constantly asking me if like, oh could we slip this in? He's very aware and working closely with these things where he's like, oh yeah, also, like we have an old prod defect for this. Or, this is some old ticket, oh, should we combine these? So it's been wonderful to have that kind of advocacy. Because instead of just logging prod defects or enhancements and knowing that like, this is never going to ever get addressed, it's like, in the meantime, we're going to fix this focus state or the text wrapping or adding check boxes into the menu. So I've really appreciated that, because you also feel that like, even though yes, the backlog is huge, we are you know, getting through some of that.
Elyse:I love that. And I love that you called out that ability to say, oh, this is actually connected to a bug that somebody filed. Or, the best of all, some team has a bug that you can spot and be like, hey, would you like to also fix this thing over here, which will solve your problem, and it's really high leverage for everybody else, you know, it'll solve everybody else's problem too, who uses this component. The PM's like, yeah, I've been moving this bug, sprint over sprint. Like sometimes all it takes is for you to just dive in there and be like, hey, this is related to this other thing. And if you can put it in your sprint and somebody can pick it up, like I'll pair with you on it. And I'll help you get that across the finish line. This sprint. Let's just do it. But also, I hate to inform you, what is ahead of you, after eight months, at about the 12 to 16 months, is when the things that were too big, that kept getting pushed off, in that first year, that's when they all start to come back to haunt you! Okay, we really gotta finally address one of these five massive things that we kept saying were, like, oh, no, that's too big, oh, that's too complicated. They're all here now, and at some point you have to do them, unfortunately.
Amy Ogg:Oh my gosh, I'm feeling that now. Because like it was a success to get primitives in place. But in the meantime, we've had to keep shipping components and they're just being shipped with primitives. And I know for the long term scaling, I'm like, we, uh, we only have the semantic stuff in place in Figma. It's not in code and it stresses me.
Elyse:You're like, agh, we, you have to, at some point you just have to make a concerted effort. And I'm like, oh, I'm not ready. I'm not emotionally ready for this project. But actually that leads me to, to a question. How do you start to identify for yourself whether or not you are being successful in this role? And I'm not talking about your performance review or anything like that, but just that sensation of, yes, this is working. I'm showing up in the way that I want to show up. I'm making change in the way that I want to make change. How do you identify that for yourself?
Amy Ogg:You know, I feel like this is something that is under change for me. I feel like in the past I identified success by meeting the goals that I set for myself. And those were not always realistic goals. And it didn't matter whether I had company recognition, or an award, or this or that, like all that meant nothing if I wasn't performing to, like, what I thought my standards needed to be. So for me, it's been kind of taking that under evaluation and saying, like, hey, you see yourself very different from how other people are seeing this work. Let's align to like realistic goals. Like I can get very ambitious about stuff, you know, here's, here's what I said my goals for the day were, but internally—
Elyse:The whole backlog. This week, I am going to get to—
Amy Ogg:Yeah. And it's not even like, anything that's been voiced on like standup, or doesn't even align to like actual goals and—
Elyse:Are you me?
Amy Ogg:I, I feel seen.
Elyse:Yeah, that, that, that hurts. So true.
Amy Ogg:It feels vulnerable to actually say this aloud. But it's something that I'm working on personally, to get a little bit more realistic. If I state a goal for like stand up or I set a deadline for this, to not be so hard on myself in my own head, and to judge myself according to something that's not realistic, that I never even set. And then feel like, you know, I am a failure, or I'm not performing up to my standards that are literally living in my head. But it's taken me a bit to get to this point of just identifying it. Now I'm trying to work on it, and totally open to suggestions and recommendations you may have.
Elyse:Well, thank you for sharing vulnerably with us. I'm sure that there are listeners who are resonating with that. And, um, you know, we talk about, systems minded people. And I think that there is, there is some truth to that. I'll use an example for myself. I recently managed to actually ship some, mostly just like polish and gloss changes to our Figma component library. Moving things around, like changing the super outdated, doesn't even match our design anymore, covers, and like documentation pages, and making a graph of what's all in the system. I started that almost a full year ago. And, in my head, I had this vision for like what it was going to be like, and I was going to do all the docs on all the pages and copy everything out of Confluence. And I started this branch on our Figma library. And I got about a quarter of the way. I got an hour here, an hour there, like work late on a Thursday, like just, you know, get it in. And it never, I never, I never got it across the finish line. And finally, I just, I just did, but what I did, was bare minimum to actually, to MVP it, to actually get it out there. Um, and and I tell that story just because it's really fresh in my mind. This was literally just a couple weeks ago, but, it's because we can see in our heads how it could be or how it should be. And so, you know, the ticket from the backlog is like, fix these checkboxes. And you're like, I'm going to fix every checkbox! I'm going to fix every checkbox, and all the radio buttons. And while I'm at it— you know? And it's like, that's what's happening in your head, because you know that it's all connected. And I think that that comes with the territory of being very systems minded. I mean, identifying it is the first thing. Identifying it and being like, hmm, nobody asked you to do that. And for me personally, the key was, nobody asked you to do that, and that is not the standard by which they are judging you. They're judging you by the standard of the things that you put on your roadmap. Or the trust and relationship that you have with them. Or the ways that you're sharing back the work that you're doing. Or your judgment, or your opinion, and whether or not you're able to connect your work to, you know, the values and the goals of the company. All these things, like these are the things that you're actually getting judged on by other people. Not your vision of what a perfect design system should be. And I don't know if there's anything else after that. I think it's just this constant awareness of like, what is, what do other people think is happening right now?
Amy Ogg:Yeah. That's, nail on the head.
Elyse:Yeah. It is, it is really, really tough because, our performance reviews often, I'm not going to say they have like no bearing on like our actual work, our actual sensation of success. But, again, I think with design systems, we have a vision of what could be and identifying whether or not we're successful, we make it so much less about being successful in the company and what other people are seeing and what other people are expecting from us. I would just say for you or for anybody else who's listening, I've been working on this by thinking about what behaviors am I seeing other people do? What things are they saying? What actions are they taking, that make me feel like the thing that I've done has spread out past me? Like, that's the, the way that I'm judging my success now. And yeah, like in my performance review, I write, I put all these things on my roadmap and then I did all of them, and like, here's what did or didn't work. But when I'm thinking about the sensation of success, it's— I'm sure that I've said this on at least one other episode, but there was a moment for me last fall where, I had been working with a couple of our engineers specifically on front end stuff and styling, and teaching them CSS grid and stuff like that. And I remember so clearly the day that I saw one of those engineers in someone else's PR that I was not tagged on, telling them how to use CSS grid and some of these props. That feels really good. That feels like success. That feels like I've made some, you know, pathway of change, some outcomes, some behavior.
Amy Ogg:Yeah. Yeah. And it's funny because it can, it can feel kind of backwards, you know, where people will say, you're not defined by what people say about you. It's what you believe about yourself! For me, I feel like I have to reverse it because, you know, what other people are saying might be a little more close to reality, since that's how they're experiencing changes or collaboration with any of this and, going back to the, uh, the issue of when your systems minded, you're always going to see that opportunity for, oh, I could fix this. I could improve this. Oh, I'm going to do all the things like this is the perfect, like whole new world. And my manager, I'm going to quote her, because she always tells me, there will always be work. Really valuable, for me to get to work on a team where the environment is positive like that, where that's what you're hearing, instead of like, just push harder I think it's helping create that environment for me to not measure my success by my own internal goals.
Elyse:What you were saying about, you know, judging yourself by what other people are saying about you, that's true in your role, in your work, right? In a job like this. Not your identity, not your self worth, not your value as a person.
Amy Ogg:Right.
Elyse:There's always going to be somebody who at your job is like, I thought you sucked. And you can't be like, ahh, I'm a, I'm a failure. I'm a terrible person. Those are two very, very separate things. But I do think in terms of design systems as a service, a big part of success in our role is, what are other people's sentiment about, you know, what it is we're doing and how we're showing up. Again, thank you so much for sharing that with us. We have to come back and talk in like a year and and see, uh, see see how things have changed. One last question for you. I know that you have switched industries a couple of times. You are in design systems now, but you were doing UX design before that. You were freelancing. And then before that you were in coffee. So close us out by telling us maybe some lessons that you have learned from switching industries. Because starting a new job is one thing; switching into a whole new space is a much bigger and scarier project. And I'm sure that there are some lessons that apply even to just starting a new job that you've learned from, from that big big shift. So anything, any lessons to take away from big industry shifts?
Amy Ogg:Absolutely. There are, there are life lessons everywhere. Goodness, where to start? I feel like no matter where you are at, you have something valuable that will cross over into the industry that you want to be in. And then when you're in the industry that you want to be in, you're going to pull upon your past experiences. They influence the direction that you take. I come from a background, actually, um, music performance was my major when I was in college. And it is very systemic. It's about a shared language. It's notation. This heavily influences the design system stuff. It's all about communication. Can anybody understand this documentation? Is it clear what the purpose of this, you know, anyone who is using this? Will it have its own theme and flavor, but also be true to like what the intent was? And my music background absolutely informs. And I find myself pulling from that, though it's been years, and I think that's part of what attracted me to Design Systems. Coffee, it is such a social role, if you will, a job. I worked in the coffee industry for like 10 years. I loved it, and I never thought I would leave that sort of industry, because I loved owning the customer experience. Everything from the accessibility of the menu to the flow and layout of the cafe to the UI of the latte art. Like all the interactions with the customers, meeting them where they're at, you know, some customers, they just want their drink really fast. Others, they want to tell you about their new baby and their child graduating and all these details. And it's very much connecting with people where they're at. And you have the external and the internal users like design systems, in that you have your customers, but you also have your staff. You also have, the internal workings of what is keeping things going, and that whole workflow behind the scenes. and honestly, that very much impacted, me moving into UX design. It was actually a coffee shop customer who said, what are you doing in coffee? You'd be a great UX designer. And I was like, what's that? And I Google searched it.
Elyse:Wow. Serendipitous and they were right.
Amy Ogg:Yeah, they had worked at a, a UX agency. I like Googled it and I was like, oh, there's this whole, like, discipline devoted to the things that I love in coffee? What? I could like, do this at a wider level? such So I was like totally hooked. And I did start with like, freelancing, um, funny enough, a lot of my first projects were design systems. The first project I turned down was a design system because I didn't know how to do it. And yeah, a client had asked for one, and I was like, I need to learn how to do a design system. I never thought I would want to specialize, in anything. When I first got into UX I loved a variety of all the projects. Like it's always a different industry, it's always like different challenges, different clients, different people. And I worked at a design agency, um, some different industries, and all this, like, I feel like it shapes, that direction that you go in. Over time, I found like I'm constantly building and using design systems. And I love them, and then I hate them when they don't work well for me, so I just want to build them. I just want to control it.
Elyse:When you have too many opinions,you have to just do it yourself.
Amy Ogg:Yeah, so it's kind of funny, some years ago I would have been like, I will never specialize. Like I, I love getting to own the whole end to end experience. You know, it was naive of me because design systems are end to end too. We're owning that whole experience. Not just the UI that like the end user is seeing and interacting with, but like that user experience of anyone consuming our design system. So it's incredibly people oriented and all about communication and collaboration. It's all connected. The patterns are just, they're everywhere and we talk about design patterns, but these life patterns, your experiences from your past jobs, your past interest in your hobbies. And I'm a big fan of cross training. When you're in music or performing arts, you cross train. Athletes cross train.
Elyse:What's the design engineering equivalent? It's like working on a product? Working on a design system?
Amy Ogg:Well, for me, it's not just getting better, technically, at my own tools, like Figma. But like that empathy of understanding the tools that my colleagues are using. So, for me being more on the design side, I've been investing and learning more about coding, so that I can better speak the language of the engineers, and when they're talking about things, that I won't have to waste too much of their time asking about what they mean by that, being more familiar. And with the PO's, the tools that they are using, I actually, uh, a few years ago, I got certified in Scrum. And like understanding what they are working with, these different structures and tools and frameworks, it makes me a better collaborator. And you know, it's, the equivalent in the design side of what athletes, what musicians, what all these people are doing. You know, if you're a classical musician, you may cross train in jazz. And you may do improv, and all that like makes you a better version of yourself and also helps you be able to communicate with a broader audience.
Elyse:I love it. I love it. Cross, cross training, an amazing lesson for all of us. I think so applicable, to, to everybody listening. So thank you for that. So it's the best time of the show. Amy, what's your, what's your spicy take on design systems?
Amy Ogg:That was my spicy take on design systems.
Elyse:You're like all of it, the whole thing. You should be cross training.
Amy Ogg:But yeah, I think, more people in design systems should cross train. I feel like a lot of times people are like, oh, well, like I work on design systems, but I'm an engineer. So I don't care about design, like I'm staying in my lane. And designers can feel like I just, I'm going to be an expert in Figma, but I stay in my lane. And it's so important to care about your users, the people that you are working with, and also just, makes you a better designer, or like you, a design engineer.
Elyse:Absolutely. Design systems is such a generalist role. I love that so much. Amy, thank you so much for hanging out with me today. This was an amazing episode. I really hope some, some good takeaways for everybody listening. Really appreciated you coming on the show.
Amy Ogg:Thanks so much for having me, Elyse.
Elyse: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!