The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive!
If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in!
Stay in learning mode ❤️
All Audio (00:00)
Welcome to episode 66 of the question. Our topic for this episode is the design system learning curve. And I am so excited to welcome you all to the deep dive. My name is Ben Callahan. I'm an author, speaker, facilitator, design system, coach and consultant, and founder of Sparkbox and the Redwoods Design System Community. This week I'm joined by Laura Kalbag She's an author, she's a speaker and a designer developer, as she says, with deep expertise in accessibility. And I know that she has a love for systems thinking.
Laura, will you tell us a little bit about your background and sort of how you got interested in design systems? Yeah, I've been working in tech for about 16, 17 years at this point. And I think I got on board with design systems pretty early because I was a designer developer. And most of what I was doing was at that time, early in my career, I was producing design work for people, but I was also having to code it up at the same time. so design systems made a lot of sense to me.
especially as we were getting into responsiveness. think the first time I wrote about design systems was back in 2012 when I was like, this is the solution for responsive web design. This is it. And yeah, think often I was doing client work and so I wasn't on long-term projects, but most of the work I did was Kalbag to live on long beyond me. And so I think codifying things in systems was a good way of being able to present work.
and people actually be able to continue to make use of it, ⁓ rather than just creating sort of pictures of designs that didn't really go anywhere after initially being launched. So that's really my background in it. And I've accidentally ended up being an educator. I work with Penpot. I have my own not-for-profit small organization called Small Technology Foundation, which I co-founded. But day to day, I work with Penpot.
on creating educational materials for designers and developers. yeah, throughout my career, I've just accidentally keep ending up in education. I think it's because I like to write and talk about things a lot. stuff. That's why I the community. It's no surprise to me, Laura, because I've heard you speak and I've read some of your writing and I've watched some of your videos and you just have such a calming presence when you are in that mode of educating.
I appreciate all the work you're doing to kind of share the things you're learning with the community. Will you tell us a little bit about your book too and what's happening with that? Yeah, I wrote a book called Accessibility for Everyone. So it is about accessibility from the perspective of different roles you might have in an organization. So I cover content and design and development and hopefully introduce people to the concepts and why you should even bother with it if you don't, if it's not something you already care about.
And I wrote that in, yeah, 2017 is a long time ago, but the book is still very relevant and it was published by Book Apart and they folded a couple of years ago, but we all got our rights back as authors and I am going to make it free on the website in the next couple of weeks is really what I'm aiming for. I've spent a long time getting around to making it an accessible website as well. so that hopefully...
will be with audiobook and everything available for everyone. And yeah, I'm hoping it will be useful. It's on a lot of curriculums and university reading lists. So that's cool. I hope that means students can get it for free as well. That's great. Are you reading the audiobook yourself? Yeah, I already did it. Yeah, long time ago. Incredible. Yeah. My brother recorded it for me and he said it's like when I used to read him bedtime stories, but
just about accessibility. That's so good. ⁓ I dropped a link, a few links to things that are yours here, you your website, your LinkedIn, your Blue Sky. If you all are not connected with Laura, please do so. Get connected, find a way to kind of reach out. I've learned a tremendous amount from her and we actually had a chance to hang out when we were in Bristol at Converge and in Madrid at Penpot Fest just last year. So we had a couple opportunities to hang out. I just have really appreciated your friendship and all the work you're doing in the community. So thanks for all your work you're doing.
I'll write back at you. I had so much fun having breakfast with you. Yes, we had a good time. Just putting our brains together. Yeah. ⁓ I also just want to call out really quickly too that there's a link over in the far right of the announcement section there. Laura's going to be running some, I don't know what these like webinar kind of things. Yeah, we call them hands-on sessions. So grab that link if you're interested. I've already sent that along to some of the folks on my team at Sparkbox just to see if we can kind of make that available to our team.
⁓ Laura, thanks again for being here. And all of you, thank you so much for being here as well. If you're new to the question, here's how this works. Twice a month on a Monday, I'm gonna send you a few questions. Anyone who answers by Wednesday at noon Eastern is gonna receive an invite to the deep dive. And that's where we'll dig into the data that we gathered together. These deep dives are recorded and released the following week on YouTube and wherever you get your podcasts. For this to work, we all have to come to this conversation with curiosity.
And that means everyone here has something to teach you and something to teach me. And if we all maintain that perspective, we're certain to have a healthy and productive discussion. Thank you so much, folks who come to this on a regular basis for consistently honoring that core value of staying in learning mode. So we sent this question out to 1025 design system practitioners. got 77 answers. And as always, you can see the raw data yourself.
You can click that link in the Fig Jam. It's also available over on my website, bencalhan.com, under the question. And the question this week had four specific detailed questions that we asked you. Laura and I just kept having these conversations and realized, I think what you hinted at in your introduction is that we're both educators at our core. And so it felt right to kind of start this year with that as kind of a primary topic for us.
And so the first question we asked is, do you feel qualified to be a design system specialist? And follow that up with, how have you learned the skills needed to work as a practitioner in the space? And then we kind of took it in an interesting direction with this idea of standards. So in the world of web, we have the W3C, right? Their mission is to develop standards and guidelines that help everyone build and enjoy a web based on the principles of accessibility, internationalization, privacy, and security.
And so we kind of looked at that as a model and we're asking you, do you believe that we need a similar set of industry wide design system standards and then why or why not? And so we got a lot of good answers. As always, it's really fun to kind of read through the data. If you get an opportunity, please go look at that raw data yourselves and let me know what you see in there. That first question was a yes or no. And of course we give you space to say, you know, other as well, but overwhelmingly folks felt pretty confident. And this was awesome.
75 % roughly said yes, about 17 said no, and roughly 8 % kind of refused to commit to one of those. One thing I picked up in this, Laura, was that even the folks who said yes, they talked about a few things. One, they constantly referred to their peers, to mentorship, to leaders in the space that have shared generously some of the things they've learned. Like they've acknowledged that they couldn't do that on their own, and they...
constantly are talking about their peers and who they work with as like leaning on, you know, other disciplines. And then they also talked about this idea of multidisciplinary backgrounds. That seems to be a common thread for folks who feel confident in their skillset here in the system space. So really cool to see those answers. ⁓ The third question was also a yes, no or other, and that was a little bit more evenly split, you know, so you can kind of see, I don't think we've ever seen data quite like that, where it was almost even between all three answers.
a lot of nuance in these. so I'm really excited. So much. Yeah, I'm really excited to get into those, into that data. Other little things that you'll see in the FigJam file down below, I have been playing with different, you know, different sort of AI models to help with analyzing the data that we get. This is something I took the raw anonymized data and put it into Notebook LM. And it does this mind map thing. And I was really impressed actually with how
concisely consolidated the answers down. if you just want to see kind of a big overview, that would be a fun thing to take a look at. Laura, I'm going to hand it to you. I feel like I've been talking a lot here. Where do you want to start this conversation? Well, I thought of how do we summarize how we're thinking about all these things. And when I'm looking at all the data, what's the question that jumps out at me that I really want to ask people? And what I've written down in my notes here is if a new designer came to you,
asking how to learn about design systems, where would you tell them to start? Okay, I love that as a start. So folks, this is where you all jump in. Okay, so this is not again, like I mentioned, Laura and I teaching, right? This is all of us learning together. So raise your hand in Zoom, you can chat in the the Zoom chat, and you can drop ideas over in the Fig Jam. But I would love to hear from you all that first question. Christine, thank you for breaking the ice. What do think? No problem.
I actually did lot of mentoring for junior designers and students a couple of years ago. This was one of their main questions. ⁓ And I always pointed them to certain folks in the industry, like Mike wrote in the chat, like Brad Frost, Dan Mull, Gina Ann, Nathan Curtis. And I really reiterated with them, a lot of them wanted to go into design systems at a university. And I kind of nudged them to take a step back.
and go into either product or UX first. Because I feel like that experience of actually building products, whether it's through UX, UI, code, whatever it is, that really helps inform us how all of this works together. And I really also nudged them to look into systems thinking as well, because that is the backbone of all this work.
say more about systems thinking like that to me. feel like I think we toss that around a lot without getting really clear on what we mean by that. What do you, what does that mean to you? Looking at things holistically, like for example, um, I'm currently working through an issue now at my work where folks are really, really concentrating on what they need for their, their single product and not looking at other products in their, their space. Um, so yeah, just, just looking at
other products in within a company, for example, rather than just their own and kind of seeing what's common across that all of them, like what's different, all that jazz. Yeah, that's awesome. Thank you. Ismael, what's on your mind, Hey, I think like Christine, you have to do like an IC role before going into the systems. And same as Mike and Christine with all the big names. ⁓
But my other thing would be to, ⁓ to advise this person to get an interest on the product management, like how to manage a product, how to build a backlog, a roadmap, how to like being like managing, a product people serving people, ⁓ and understand that at the end you have some users. And the other thing that is.
maybe too geeky, but I think that it's like the first element of already have been into that IC role is doing some CSS. ⁓ That's interesting. Why CSS specifically? ⁓ It's not just CSS. think it's HTML and CSS to understand the semantic of what you're doing and to understand how you modularize some elements, the styling elements.
And how you, I don't have that one in English, but how you have small element in bigger elements, like the cascading properties, the inheritance that you have in the CSS that is super important. Even if you don't do CSS to understand the dependencies, to understand the inheritance and all these concepts. And maybe a last one.
would be to have an interest on the ⁓ OPS oriented object ⁓ programming systems ⁓ to understand some of the abstractions that you need to put in place to have ⁓ not just a component library, but really a real design system with all the complexity of it. Yeah, that's super insightful. Thoughts on I'd second HML.
is a good starting point when it comes to accessibility as well and introducing people to the idea of making things accessible. it's a very, it's quite a straightforward syntax to get people used to, like declarative language is, it's less intimidating, I think, than a lot of programming overall. Hmm. Yeah, that's a great point. Greg, what are you thinking?
I don't, I don't know if what I'm saying is agreeing or disagreeing with anyone. I'm not even sure it answers your question, but it came to mind when I was listening and I, I was frantically trying to find the article and cancel. I'll have to look later, but I read a good article that was the people who see systems end up being the ones that build them was the quote I took out of that, which I think almost applies here. Like Christine, when you were saying like you you've heard some new people, they're like, I want to get into design systems. I feel like I would almost have the same reservation where
the people I've seen interested in it are people already thinking systemically. They've been writing HTML and CSS systems for years. This is a natural progression, or they've been doing all of this work in functionality. And they're like, I want to make this work broader and across things. And I really resonate with that because I got interested in design systems because I see systems in the work I did as a front of the front end person.
And so I think when people come to me and sort of like this question and other ones where it's like, where did you get into it? It was just sort of a natural step. I was already thinking systemically and there's this place you can do that and it's design systems. And I think you see that across, I think it's why you see a lot of the same people's names get mentioned is that it's people that have followed that path. So you point people to who have seen the systems at these massive organizations or their tiny ones.
they've seen the systems and they figured out how to disseminate all of that down into something reusable and learnable. ⁓ So I always, whenever I send people to the Nathan Curtis's or the Dan Malls, I always include like a little disclaimer that like what you're going to see is like the industry Titans thinking at a massive scale, but at your 20 person startup with three products, you probably have a different system to build.
So like learn from these folks, but you won't be able to apply it directly. So it's like really awesome to learn how IBM does it or Spotify, but that probably won't work for you. So like the conversation for me, when someone's like, I want to get involved, it's here, learn what a design system is, and then come back to me we'll talk about what it means here and what we do with that system. ⁓
It's two sides to this coin too, right? Like folks who see systems are the ones who build them. love that quote. And if you can find that article, Greg, drop that down in the resources bar. I would love to read that. But I also think it's hard to turn that systems brain off, right? And sometimes I think it creates, ⁓ I don't know, it's a bit of a slippery slope for us as systems thinkers to fall into, to burnout honestly, faster than others, because we see the implications of all the decisions that people are making that maybe they don't even see themselves.
We actually did a session on this 50 something, 55 with Lauren Leprette. So I dropped a link down to that in the resources too, if you're feeling a little bit of that burnout. And also there's the risk of codifying too much, formalizing everything, which I think is something we also see in the answers when people are talking about the problem they have with standards, which I think can also be inherent to design systems is
when people that are consuming those design systems don't feel like they have the space to innovate or be creative. And I think that there is the risk of that sometimes comes from us wanting to systematize absolutely everything, even though it might not be the most effective way of doing it. Yes. my gosh. Combine that with like a touch of OCD and yeah, you want to systemize everything, right? So for sure. I know we had some other hands up. Guy, what are you thinking?
I want to continue a bit what Greg said and also Yesenia here in the chat kind of expressed a very similar thing to what I'm going to say. By the way, another great book, if people want to get into design systems, this is Yesenia's book. But if someone comes to me and said, hey, how do I get into design systems? The first question I'm going to ask him is why? What is it that is drawing you about design systems?
What is the, is it the fame and glory you want to get out of working on design systems? And based on that answer, I'll probably go into it. It's going to be easier to sort of direct them. And I might even say, you know what? It doesn't sound like it's the right thing for you, but that can help kind of like direct what sort of like, it more on the code side? Is it on the coordination? it up? There's so many things that you can do on a design system. Another thing is that,
Kind of like what you said, Greg, about if you send people to ⁓ the people who are kind of like, know, ⁓ expressing the mastery of design systems after years of working on different design systems and experiencing them in a lot of different organizations. Just like with AI these days, if you just jump into the the output, you miss out on all the process of how do they get there? Because
your design system and your company is going to be unique to you. And you need to understand it's not just, I'm going to follow exactly the process that Brad Frost is describing. I need to understand how to take that and improvise on it and apply what I need that. And that just takes years of doing to get to that position where you can assess why that worked for Brad and not for me, or how do I
modify that. Yeah, I think there's a lot to unpack there, Guy. And I do think it's really easy. remember in, let's see, Pittsburgh two years ago when we ran Symmetry, Jeremy Keith was there and he said, you know, public facing design system sites, doc sites are like social media, right? Where we only show you the good stuff. And so it's really easy.
when you're out looking at all these things, you're thinking about, my gosh, I'm not doing it right because I'm not doing it like, you know, whoever, right? Spotify or whoever. And so, ⁓ yeah, I think you're, you're encouraging. think that's a really good, you know, sort of encouragement, right? For folks to think about how does this actually apply? What can I take from this? Not to go in thinking this is just the right way. And I think that in some of the responses that we have, where people were saying that they,
especially at a junior level, learn from other people's external systems. But one of the things that that made me think about was we kind of embed our values in the design systems we create. And as someone who, like, want the not-for-profit I have, we're all about creating things that are not big tech. And I don't necessarily want to create a design system that replicates the values of
big tech and I often want to be able to do things differently. So if I'm copying something that has its values embedded in it, am I going to end up sort of taking on values that I don't, that don't actually represent me or what I'm like the product that I'm trying to build for. My goodness. Somebody has got a response to that, right? Like is that, is that going to happen by default, right? If you're pulling from, you know, existing systems, go ahead, Greg.
a call out to Redwoods here actually. I think one of the first things I talked about when I joined was, and I think I noted this in my question response that design systems in my almost two decades of work is the first time I've felt true imposter syndrome. And I think it's because I read all of these, these industry masters. I'm joining groups full of people who I think and I see who have got it, right? They get this and it makes sense. And I mentioned in the chat that
You know, I'm looking at all of these other systems, I'm looking at mine and I'm like, that's just such a better way to do that than I did it. And someone I'd have to look up who it was. And I'm appreciative for this response was be happy. You don't have their problems. So Laura, to your point about sort of absorbing big tech, that was sort of eyeopening for me that I'm looking at all these fantastically detailed, incredibly intricate systems that were born from problems they had. And the fact that I don't have those problems to solve for is a blessing, not that I'm
not doing a good enough job or my system's not good enough. It's not a problem I have. And I think that was a really big shift to how I approached getting into this and how I feel about my own work in this space. I love that. That's so smart. Like maybe the bigger and better your system is, the more wild problems you're trying to solve, guess, right? That's cool. Yeah. Well, and it's a
telling you to focus on the problems that you do have and you can do things that are more interesting and have a much more impact for your own users as well. Austin, what's on your mind?
Yeah, I'll just start by saying I'm definitely one of the ones that answered no to being ⁓ a pro design system. Definitely new. ⁓ but I love Laura's last comment because I work at Bass Pro Shops, which is a huge company, but probably the exact opposite of a big tech company in so many different ways. But all my education, it's so true has been, you know, just resourcing these other existing systems. And there's been so many times that I'm like,
I get that, but it doesn't fit. It doesn't feel right for us and for our org. And it's not meshing with the company and no one's, no one's, you know, getting into it. So that's, that's a huge thing for me to take back. Cause that's going to help a lot. Yeah. I wish that was like a caveat at the beginning of every single article that's out there. know, I mean, there are, there are, I think there's a couple types of.
of pieces that I see that are kind of showing up in the industry. One is like, you should do your system like this because it worked for us. And one is more like, hey, I did this thing and it worked here. The model of thinking that that sort of leads me to is this, right? And that's what I, that's what I want to see is more folks. It takes more work, right? To sort of extrapolate out of your experience, a model that can help people frame the way they think about systems. That's, think we're the real, that's what I think we need more of, you know?
And that actually leads us to an interesting question. We had sketched out a few ideas for discussion, Laura, earlier. And one of those questions was this idea of, that's a little small, on, where are the gaps right now in the design system learning curve? So if we imagine that, like the analogy I like is, if you think about learning as like a chain link, right? And everybody's at a different part, a different sort of moment of growth in that link of chains.
Everybody needs to be sharing the things they're learning in that moment because it's really hard for someone who's just coming in to learn from somebody who's really advanced. We need all those links to complete it, right? So I kind of think everybody has a responsibility to be sharing these things. So where are we missing links? I think is maybe the way I would pose that question. Anybody, Christine, you have thoughts on that?
having teams talk to each other, communication in general, that is a huge blind spot that I am currently noticing. A lot of folks think they can build a design system or just a system in general with one product in mind, but to me that defeats the purpose of it. And what's the point?
Like unless it's product team, but yeah. Yeah. That's so good. I, so many of the folks that I've worked with in terms of client engagements have built a system based on a single product and it's not a system almost in that, in a sense, you know, because it's not serving, it's not been systematized, right? I'm just sending it. do you, go ahead. Sorry. Do have more there? Yeah. I just wanted to say like that. If you're doing it with one product in mind, it's more of a style guide than anything else. Yeah.
Just any thoughts? Yeah, one one that just came to mind for me, which has burned me a lot until I figured it out, was change management. how like so much of design systems is getting people to change something that they're doing and figuring out how change management happens within the organization that you're in and adapting the way that you communicate to that. That has been like the biggest success or failure for me.
But it took me a lot of revs. Like, I feel like this isn't talked about enough. Like, I worked at a company where it was very relationship driven and you had to form good relationships in order to make that happen. And another one that was very, like, storytelling driven. And I feel like if you have a mismatch of communication styles and, like, change management practices, then you're not going to succeed. But yeah, I don't see a lot of conversation about that. Yeah. And we are like...
you know, we're designers and developers and product people, right? We're not like, we haven't been trained in change management and there's an entire discipline where you can go and get a master's degree and a doctorate in how to change a big organization. Like this is not simple stuff, right? I don't know just any, just to put you on the spot, but do you have like some practical advice for people who haven't studied that stuff that have to do it? I mean, there's, I didn't go to get a master's. There's just this book that I,
read, but I can't remember the name of it now. It's something about, it may be called Switch. Okay. But it's like about how, how to appeal to people, like two sides of people, like their emotions and also just the operational side of it. That helped me at least come up with some, some frameworks. Yeah. Yeah. Okay. Yeah. That's the book. I referenced that a lot. Brilliant. Okay. Awesome. Thanks for that. Laura, you have thoughts here? Is this change management side of things? this?
sitting well with you. Yeah. It's interesting seeing how little like it offered the people side of it didn't come up so much in the responses. So much as the sort of, think maybe that was the way in which the questions were leading was more about sort of resources, which, but I think it's such a key point in order. And it takes us back to that whole idea of
think someone said in the ⁓ answer it was if we have standards they should be more around the processes for creating a system rather than for the system itself and I thought that was a really interesting idea. It's often actually a lot of the kinds of work that you do Ben is helping people ⁓ answer questions and uncover the why and the how around their product in order to create the design system effectively.
Yeah. Yeah. It gets, it's the root of what just said, he was just talking about, which is like, you can't change an organization if you don't understand it, you know, and all the motivations that are there, you know? So I think that's, that's good. Austin, did you have something? I feel like I lost your hand there or. Yeah. I just didn't want to repeat, but yeah, I feel like with figma now, especially the design piece, there's so much education, but I, again, working at a, ⁓
big company, it's been really, really challenging to actually get people to use it. And I've reached out to the, probably the most effective learning I've had has been just reaching out on LinkedIn and asking, begging people, like, if I send you coffee, will you please talk to me about how to, how to do design systems? And a few folks have, and, one of them was just a project manager for the design system. And it just blew my mind.
my goodness, have you just had someone to just manage this and I could like focus on the design piece that I actually enjoy. That'd be awesome. But then convincing my org to like actually commit to that kind of stuff. That's definitely the biggest lack in education for me. Yeah. so you're saying two things. One would be education around how to manage a system effectively. Is it like a program or a product, but also how do you sort of manage up internally to your leadership?
convincing them about roles that are necessary that maybe aren't in place. Is that accurate? Yeah, totally. Those are great. Yeah. Taylor. Austin, did you find that you got information that was relevant to what you were doing from these outside people when you were looking for more specific advice? Yeah, I think that effort and talking to folks on other teams, the biggest
revelation was that this is about people. I have a long UX visual design, ⁓ a lot of experience there and that's what I love. But then someone, one of them said, this is about people. And I'm like, that shifts the whole thing. how to like convince others and how to inspire others to want to use it, how to be open to collaboration on it. Like all these things that, and a big
piece of advice was meet people where they're at. And so instead of just being like, yeah, I'm going to hold a design system meeting once a month and no one comes, ⁓ be like, hey, when do you have your standups? I'd love to poke in and see how design system can help you kind of thing. That's been really helpful. So good. That does remind me of one of the takeaways I had from Converge after there's a lot of people in this chat that
I learned a lot from in that event. But one of the things I took back to Pamparts was I said to them, Hey, you know what? Like you can put the tools there and everything. Like it's, can build various features that people want, but really the problem that most folks have is around people. there's not much you can do to facilitate that. Yeah. Yeah. It leaves tool companies like that in sort of like, you know, they're sort of dependent on
really sharp folks inside organizations who are willing to do the hard work of shifting the culture, you know? So that's good point. Taylor, what's up, buddy? I think it's like a meta overlay thing that like I'm just feeling as we have this conversation. And I mean, that is like, right, we're on episode 60 something, right? Like, I feel like we had a similar conversation, I don't know, couple of years ago, I guess, I don't even know when we started this. the reason I'm reflecting on that is I remember like
I still kind of have this sort of stance. like, I've always kind of felt that like systems as a practice, right, are relatively new. Systems from a tooling and a skills perspective, old as the hills, right? Like we're just finally getting a career, you know, acknowledgement of this path, right? And I think we're actually on the precipice maybe of like the next, I don't know, bubble of that. And what I mean by that is like, I think we've had enough people now, in some magical and increment of time, in the IC world.
Right now those folks have then moved into, right, cool. I know how fucked up the last management was. I'm going to fix that this time, right? They've gone into the next quadrant, right? So now we've got where it was like, let's say five years ago, all the ICs trying to drive upward and get people to understand kind of where we are, what we're doing, right? Get that seat at that higher elevation. And now it just simply because of time.
we have people in that next thing, right? Like in this call, we've got directors, we've got leads, we've got managers, right? Where like a year, three years ago, it would have been everyone's designers and engineers, right? Just by nature of the role. So I wonder if part of this too is like, not only has the environment in which we play changed, right? Tools have changed, AI shit, layoffs, whatever, but like we're also reaching a potential maturation point in the design systems arc.
of, I don't know, establishment, right? Forget about the tools, forget about the nitty gritty stuff, forget about the work that we literally have to type all day, right? But like the understanding of the work we do, right? Has changed our role and position in the ecosystem of product has changed, right? So I just, think it's an important layer at some point to go, Hey, at this marker in time, like our conversation may have actually changed a little bit, right? And so we're not necessarily, and there are some folks, for example, still in that like,
first initial IC spot, right? They're like, I don't know what to do with adoption, right? Like thinking it's their first thing to do, right? And that's great because five years ago we were all there and we didn't know what to do, right? Now we've got people in that like phase two, so to speak, the next bracket up, right? They go, hey, I remember what happened when I messed that up. Here's 10 things, right? So we've got kind of built in layers that we didn't have years ago, a couple of years ago, a year ago, right? Just in terms of.
the awareness in the industry of like, these roles matter, we need more than just ICs, putting people in place to do that work, trying it out, and then we've got places like this or whatever to go, hey, yeah, I did that, took a risk, it sucked, don't do that. Or this worked well. We didn't have this before. So I wonder how much this also plays a role in the arc of people starting in. I'm just gonna do silly, shameless thing. I put my article in here, like the thoughts of pursuing systems. I wrote that almost three years ago now.
I still think it fits, but this is what made me think about this. It fits a lot of the categories going down, like education, career, this is meant to be something we build, but even that has changed. So it's an interesting evolution in an increment of time. And I think it's worth calling out because I think it's something that plays a role in all of this. And we're talking about which things matter to what org, which things matter to what team, are we talking about disciplines, are we talking about roles? The world's a little different now. And I just wonder if it's worthwhile to go like, hey, cool, we should...
Think about it that way. That's what I'm interested in is when if your people in that phase two, then how as a community, can you share the things that you've learned that have got you to that phase two in order to stop everyone else who's maybe five years behind you having to go through that five years to get to phase two and what, how do we get people there? Right. And I think that's Ben.
wrote down this idea of, ⁓ and I think his is quite role-based, the idea of learning paths for people going from designer to system designer or developer to system developer or product owner to system owner. But maybe it's not even as specific as those roles, but what are the, I guess, the learning, the material that you can provide people to help give them a shortcut to phase two.
Right, like is it thinking? Is it tactical skills? Like what's the thing they need to adjust, right? Is it just their width of the lens? You know, is it the literal tooling? Like I think to your point, like we now have some folks that have done that and been there in our discipline, which wasn't a thing for years. And I mean, like, so that's, I think that's the cool part.
Yeah. And that idea came from just reading through all the answers, you know, that folks in the community gave, but like, I'm just imagining this, this has got to be a thing that happens in other spaces that I'm just not aware of, but there's so much material out there about this stuff. And I wonder if, you know, putting our heads together, we could sort of say, okay, if you are this person, here's the things you need to learn in order to develop into this role, you know? ⁓ and ref just link out to all the different amazing.
know, pieces of writing and, you know, material, videos, podcasts, all that stuff that's out there, you know? And if we could do that, you know, having a nice place to send folks who are coming into the space might be really helpful. Taylor? Yeah, like what's an article that or a talk or something that changed your mind that taught you something that took you to that next phase? I love that. think.
I'm strongly bullishly opinionated that if we were to curate something like that as like the Redwoods group, which I would be dope. Like, I think we need to have markers in time, phases, increments, whatever. And what I mean by that is like, we have five, six articles that are out there, they're great content, something changes. Doesn't mean that article's bad. We just need to mark that like this was relevant at a different time. Like, so that's, think, part of the challenge. And I know there's some folks from my team on this call. Like part of the issue was like, sometimes we pull up things that are like, this great article from this person.
that was 20 years ago, which the topics are good, the content's great, but the terminology no longer matches, right? So it confuses people internally, right? So it's like, there's more than just the nitty gritty of the topic. It's like the language used and the context, right? And I think it's important if we can, you year over year or like as big ships or whatever, like an increment so we can say this was context of 2025, you know, or whatever, this is 2026. Yeah. Goodness. Yeah, even to annotate.
the article with those updates as well. to be able to say that, yeah. It feels to me like kind of going back to some of the earlier conversation about sort of the types of, I don't know if it's thought leadership or content or whatever it is that we're talking about, but you know, the pieces that last are the ones that do the work to sort of pull out the specifics into sort of those models, you know? And so that's where I would love to see, maybe we could be more intentional about what
makes it into that, you know, have some criteria around sort of the longevity, the value of the longevity, you know, something like that, but super cool concept. Other thoughts here or Laura, any other direction you want to take us in or questions that we didn't get into yet? Well, I do think that and I think the standards question is quite a provocative one. And I'd say that I would not necessarily come down squarely in for or after because I think that there are a lot of
problems with the standards that we have in existence, like who are the people that decide on them, who makes them, what organisations are they building them for? And also the standards exist, but that doesn't mean that the majority of people actually use them anyway. They're just there. But I would love to know if anyone has any thoughts about whether it is specific standards or whether it is
principles that they have learned or is there something that they would say, this is a standard that I think I'd want to tell someone who is new to design systems. Yeah. Thoughts on that, Greg? Yeah. I thought of an example in the middle of you asking that Laura, where I think I don't, I already forget what I answered in the question, which is great for me. ⁓ but I think my answer now would be that I would agree that we don't necessarily.
want or need a standard to sort of my previous comments where we're saying, this is how you make this component in design system. But a topic in the few questions I've been in are how do I convince someone about the ROI of a system? Or like people are saying, what roles maybe make sense to come into or what role should I research to go into design system work? Which if we compare to the W3Cs and the WCAGs are just the sort of when you go and it's here's your introduction page.
And to someone who's been a ⁓ practitioner for years, you're like, yeah, duh. But for some coming in, that really baseline, you need to learn what a screen reader is. Here's where the rules are. And here's who the people in the working group are. But I think when you were asking that question, Laura, there's another side of that. And I'm going to use accessibility because that's the space I occupy most of my time, is the example of the IAAP, the International Association of Accessibility Professionals.
a sort of known standard for how you get certified, but there's reasonable doubt to this organization that takes my money to take an exam and I get my letters, which I have at the end of my name, who are they to decide that I get those letters? And I think there's an interesting balance here too, where if the design system were to get maybe not certified, but it's that same question of who are you to tell me that this is how this starts, reminded me of that.
where there's this organization that people in that space, you're like, yeah, this is where you go. It's where you get certified. This is how you do it. And then the minute someone might ask, but why are they the ones? I don't know if I have an answer. Like, I don't know. They've just been the ones forever. That's who I learned from. And so now I'm giving them to you. But I don't know if I can explain to you why those are the right people to be telling you that this is how it happens. So I think, Laura, you and Taylor both brought up a good question there, where you could
write as many resources as you want until you've documented everything you could about design systems. But that question might still come up and it's figuring out how do you answer that? sort of to be dramatic, what gives you the right to document how a design system should get off the ground or what it means or what roles you should be familiar with to get started? And maybe an approach for that is, I think one of the answers
Someone's talking about how much you learn from the open source culture in that people sharing information. That's how I got into the web. That's what got me into it. think a lot of us are self-taught because people share things. So is there, rather than a top-down approach of dictating a framework that other people can pay to be certified or whatever, but is there something that is more of a community approach that can bring together the framework and where would you start?
or something like that.
Yeah, that just reminded me, along with some of the comments around, the design system that I am solving for isn't for big tech, and so we have different solutions. But right now, I find the only way to surface that information, the learnings, is either through a public open source documentation site, or it's through people's writing. At the same time, we have galleries of component examples, which is kind of funny because a lot of them just look the same. It's like, here's how...
50 teams have solved a form field. But what could be interesting is a gallery that's coming more at the user problem ⁓ and solution. So here's a user problem that I'm solving for, like one that we had at Shopify was users that need to operate an interface at an arm's length ⁓ or in a dark variable lighting. So something like that. And then here's solutions that
different teams have created for those problems. I that could be an interesting community-led way to surface some of the findings from smaller teams that don't have the capacity to just open source their entire documentation site. Yeah, that's cool. Ashley, what do you think in there? I totally agree with you, Yessenia. I'm going to drop it in. This is exactly what you were talking about, Yessenia. I was talking with Casey about this. And we were looking at this component gallery where
Yeah, we'd love something beyond just components, right? We want something of, okay, thinking in the lens of education, like, ⁓ we're all leading the same training essentially about the importance of tokens, for example, or how that enables variables or theming or how we use a certain component. And ⁓ a lot of that can be company or your system specific, but there are essentially
basic templates that everyone could be following. Like this is the importance of a variable. Here's what you can do. And ⁓ if we have some sort of, yeah, open source community contributing space to put that, I think that will be really useful for everyone. And it's essentially like ⁓ all of the templates you can pull from Figma, like their playground files, and they have a lot of their like fig.
Figma files that people are contributing, it would be something like that too, which I was. Yeah. I love it. This is really cool. I'm taking notes furiously here because I want to make sure we don't lose that sort of momentum. A couple more, we have probably just time for a couple more comments. Stephen, what's on your mind?
Yeah, I liked the question, but I'm going to take it just a little bit of a different way because I'm not sure what I would like to see examples of is how people are articulating their shared problems and values across different organizations. Because I feel like that's the part that's ⁓ at least in my experience, it's when we articulate our problems and values and everyone agrees on them, everything else just sort of falls into place.
Adoption falls into place, contribution falls into place, because we all have an aligned sort of purpose as a design organization or as a product organization, however you want to put it. ⁓ So, you know, I think that's maybe part of the disciplines that are also aren't, you know, maybe well explored. think designers in particular are pretty naturally good at, you know, here's a problem, like here we're going to
clearly articulate the problem. So I think that makes them naturally good at, you know, getting alignment on the way we talk about things. But yeah, shared vocabulary, shared way of talking about the problems that we solve as an organization, I think. ⁓ Now, is that W3C worthy? I don't know, but I think there's some gallery of like brand values and examples of how those actually translate into, you know, the various aspects of
design system work. Yeah, that's really cool. Greg, what are your thoughts here? I wanted to dig in a little bit in the more of the space of ⁓ like, so we've got web components, there's standards for that, how you can construct stuff, the work being done there is great, the tokens work is great in terms of standards as well.
What I find as a sort of a weird disconnect is like in the system I work on, obviously there are HTML elements that serve specific roles. And what I kind of see as a pattern in my system is, and I think this exists in a lot of the systems that people make is you have to reinvent
the HTML native component into a new thing because you needed to do something that's not standard. So I'd love to see some of these patterns of how known things can be extended in the actual HTML standard so that we can just apply tokens to them and get the reinventing of the wheel of those things.
move further along. That's kind of the lens I looked through the question at. And in that respect, I think it would be pretty awesome to be able to figure out a better way to elevate the patterns that are emerging as people are building experiences and the HTML standard isn't quite meeting the needs of what's going on today. That kind of stuff. ⁓
But yeah, I think the trying to push systems or answers or standards on folks is, mean, everyone has that sort of visceral reaction when you try to control them type of thing.
⁓ And I think that's one of the biggest challenges with working in systems is like, do you meet people where they are and what they achieve, what they're trying to achieve and you're in parallel and you're working together. And ⁓ where I work, they don't even tell us a number of how many products are using the system because we just have this huge ecosystem. We have all these acquisitions of products that are
different various stages of trying to adopt our design system and all this kind of complexity there at an enterprise level. like, you know, you know, some teams are like, yeah, we'll use the system. Some teams are like, we can't because then we start to adopt and then we're adding all this extra work in terms of testing because now we have to test all these screens that we were done with and we weren't planning to touch and all that fun stuff. So, you know, and some of the change management.
conversation earlier definitely resonated with me in that respect too. ⁓ But those are kind of the places my head went with these questions. But great discussion. I'm glad to be here. Thanks, Greg. That's great. I think a few folks I saw mentioning in the chat too, we had Brad on last year to talk about sort of a global design system, that kind of thing, I think sort of comes to mind. A few folks mentioned that.
concepts in their answers as well. And I hear you kind of saying things that are similar, right? Like a layer on top of HTML that allows us to compose things into more common, more complex patterns, essentially. So very cool, folks. Y'all are amazing. Every week we do this, I'm so excited and grateful for your ⁓ dedication to actually answering these things and really thinking them through and not just sort of flippantly responding. ⁓
I've seen a lot of folks dropping resources in that resource bar, so make sure you check that out. A couple other quick things to note, ⁓ in order to make the question more sustainable, I'm trying to look and find some sponsors for this year. if you happen to know of folks that might be interested, you or your organization or other folks, you can send them here and I'd love to chat with them. I've also got another opportunity for folks to kind of list open positions here. So I'm happy to talk with anybody who might have interest in that.
And then a couple other ⁓ announcements. Redwoods is open. We've been open now almost exactly a year. At the end of March, it'll be one year. I'm really excited. It's been incredible. I've made so many new good friends and just the amount of content these folks are like processing with each other and thinking through and sharing with the larger communities are really inspiring. I'm sure I did not capture everything. So if you're a Redwoods member and I missed your article, Ashley, I didn't get yours in here. So you drop it from you, okay? Add those into this section. And I mentioned Laura's ⁓ web.
event coming up, so please get signed up for that. ⁓ If you want to share your LinkedIn or your portfolio, you're looking for a new gig, drop those over here. We'll get connected. if you have written something recently and we want to see that too, if you've had a release or you're proud of something, drop those things in here so we can kind of celebrate with each other too. ⁓ I think that's all I got. Laura, thank you so much for bringing such a fun conversation. This was a good way to start the year. Thank you.
Thank you for inviting me. Thank you everyone for your insights. I Kalbag a lot from what I already have known from the Redwoods and Design Systems community, but you always surpass the expectations. Yeah, it's so true. And we didn't talk about this, but I put this whole section right here on the tone of your answers because I just was feeling so grateful reading through them. So if you haven't yet, give this little section a read. You all are amazing people.
I feel very honored to be in this community with you. So thanks for being here and thanks for being a part of it. And we will see you all in a couple of weeks. All right? Cheers everybody. Bye bye.