| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 066, deep dive hosted on January 15, 2026 with Ben Callahan and Laura Kalbag. There are 77 answers. The question this week was: ----- It’s 2026 and time for the first episode of the year—number 066! I can’t even express how excited I am to have my friend Laura Kalbag joining this week as my co-host. We had a chance to hang out in Bristol last year and hit it off immediately because we share a personal value of life-long learning. Which explains why, as we were chatting about possible topics for this week, we kept coming back to the idea of learning. Deep down, Laura and I both consider ourselves educators. Throughout our conversations, one idea kept rising to the surface—the learning curve of design systems. So…what does that mean? It’s fascinating for me to understand how people stumble into this specialization. Nobody got a Bachelors of Science (or maybe art?) in design systems, that’s not a thing. Which means there is a scrappiness to the folks (you and me) who find themselves doing this stuff. Contrast this with the fact that we’re reaching a point where most organizations have some kind of design system effort happening and you begin to wonder if there needs to be a more clear path to follow for individuals who want to specialize in design systems. This week we want to explore what that would take and what it might look like. Welcome to Episode 066 of The Question! Do you feel qualified to be a design system specialist? How have you learned the skills needed to work as a design system practitioner? In the world of the web, we have the W3C: “The World Wide Web Consortium develops standards and guidelines to help everyone build and enjoy a web based on the principles of accessibility, internationalization, privacy and security.” Do you believe we need a similar set of industry-wide design system standards? Why or why not? | |||||||||||||||||||||||||
2 | Question 1: Do you feel qualified to be a design system specialist? | Question 2: How have you learned the skills needed to work as a design system practitioner? | Question 3: In the world of the web, we have the W3C: “The World Wide Web Consortium develops standards and guidelines to help everyone build and enjoy a web based on the principles of accessibility, internationalization, privacy and security.” Do you believe we need a similar set of industry-wide design system standards? | Question 4: Why or why not? | ||||||||||||||||||||||
3 | Yes | Yes, I’ve got a background in design but have been engineer for going on 15 years, so I can reason around both to build robust solutions and systems. There’s always more to learn and do, but it’s at least a solid base. | Maybe | Some very base-level constructs maybe, but solutions are often slightly unique given the nuances and requirements of different businesses and products, so I don’t know how much can be generalised whilst remaining useful globally. | ||||||||||||||||||||||
4 | Yes | Through learning about Product Management for the organization, strategy, communication etc... And by reading and discussing a lot all these subject with various people, from design to dev, passing through devOps, PMs, QAs, etc etc | No | I don't think we need one, because each DS has its own frame : brand, goal, needs, peoples, etc. And W3C is about one medium or support, Design System answer as many as we want to and has to be very elastic with what we want to do with it. I find it already a bit too limited just around component, and not enough about people, their real problems, the processes and all the frameworks and guides that it should contain (like research plans models or Product Rituals) as I think that we should consider more the terms in Design System : The System of conceiving something inside a compagnie | ||||||||||||||||||||||
5 | Yes | lots of self-learning. knew there was a need for a system. had to teach self how to do it in sketch, then figma, then with all of figma's evolving updates. so...i feel you need to be willing to reach out or dive into tutorials and read many articles to get up to speed and keep up. DS work seems to change fairly frequently, so it seems like you have to be dedicated to continuous learning. AND be adept at keeping up with/transitioning to new software/tools. another key skill is collaboration w/ your partners. so as a designer, i have to be best friends with my developer partners to make sure we put out the best holistic DS thing. some other disciplines can get away w/ silo-ing a bit better, but i feel like silos are a total fail for DS. so, you need to know how to talk with your counterpart and make decisions together. for designers, i think there needs to be a balance of UX and UI skills. our company prioritized "Design Strategists" for awhile, which were often folks w/o a strong design, visual UI foundation and i'd say our products suffered for it. and i see that issue heightened in the DS space. | Yes | sure! seems like it would be helpful - clearer sources of truth are always helpful | ||||||||||||||||||||||
6 | Yes | Early on, a lot of learn by fumbling through ideas. Very thankful others are so generous with sharing their knowledge, experiences, and creating talks / courses to continue learning from as I've grown in my career. | Yes | I believe some sort of standard / base would be valuable for all of us to create a better, usable experience for all. Especially the patterns that seem to exist everywhere. Forms! signing in / signing up, addresses (localized), etc. | ||||||||||||||||||||||
7 | No | From great partners who have helped educate me. | No | What industry would we be setting design standards for? I feel like there are just so many different use cases it would be difficult to set design standards that aren't already covered by WCAG. | ||||||||||||||||||||||
8 | Yes | By trying, failing, and keeping on trying. Supported by the community and their willingness to share their own experience. | Maybe | I like what the W3C Design Tokens Community Group is doing, and I think it makes a lot of sense for tokens. But I haven't spotted more use cases. Those might exist, though. | ||||||||||||||||||||||
9 | I am very knowledgable on design systems and I am the go-to designer for design systems in my organization; however I am not a dedicated resource since my organization still uses a federated model. | Personal research and learning (via books, courses, free webinars, and free conference video recordings), and hands-on experience without an internal organization dedicated design system resource or any sort of mentor. | Unsure | I'm unsure because on one hand it would be helpful to reference a set of industry standards, but on the other I'm just not confident how those standards would be so different from WC3. Isn't the rule of thumb already to incorporate W3C standards into ones design system? | ||||||||||||||||||||||
10 | Yes | Through "doing". | Yes and no. | "Need" isn't the word I would use. I think the community would benefit from some lightweight structure, and formalization. But with anything rigidity is a double edged sword. We are still in the beginning stages of digital product Design Systems, and we don't want to stifle innovation. | ||||||||||||||||||||||
11 | I consider myself qualified for playing my role as a member of a greater team. I don't consider myself an expert for all "parts" of design systems. | I've gone to conferences, read many blogs, watched many videos, talked to many clients, researched other systems, read books (eg. thinking in systems, atomic design, pattern language, etc), been a member of the Redwoods community, and meet with other design system teams. | I think it makes sense for certain aspects and we should test it. If we can't find success for a single standard, it'll be a tough road. Start small and keep expanding. | It would be hard to believe that we all couldn't benefit from standardizing some things. | ||||||||||||||||||||||
12 | No | I have discovered design systems while working in a branding team. I was attracted by the systematic way of creating and started contributing to the DS and reading about design systems. Now that I am leading a design systems team, I am continuously learning from making my own mistakes, from other people, and from internet articles and courses. | Yes | it would be better to stop reinventing the wheel where possible, and start building system starting from a good foundation. We already have design token specs from w3c which help tremendously. There will always be a level of customization froma design pov, as well as operational specificity, but at least we will stop designing buttons from scratch and wondering what is a pattern vs a component. | ||||||||||||||||||||||
13 | Yes | By working on various design systems for the last 4 years of my career. | Perhaps | Depends on what those standards are. When it comes to how components are used, I think we all try and stick with the standards. Official standards would be nice on naming and general usage of components. There could also be standards on icon usage to keep the same language across products. However, different industries come with their own complex and unique problems. Even being in one industry you may see various problems to solve. Being a enterprise system for a company with 100s of products, I have found difficulty standardizing because of the unique problems our designers solve everyday, and get challenged almost everyday for decisions we make. I find designers already feel so restricted from design systems and have gotten the sense they feel restricted by WCAG / WC3 (even though I find these standards VERY important). If we create a set of standards, how do we balance standards with designer's creativity? I found as I grow older in design systems, I tend to "police" less and provide more flexibility. | ||||||||||||||||||||||
14 | Yes | By following people (like you, Ben) Brad Frost, Nathan Curtis, Jina Ann... Reading good books about design systems, listening to podcasts and watching YouTube videos. But mostly, working with a beautiful team on our design system since 2020. | Yes | Well, we already have the Design Tokens Community Group; it would be a good idea to have something similar, but for design systems. It would be a good idea so everyone could learn from previous mistakes (like federated governance). | ||||||||||||||||||||||
15 | No | The concept of "design systems" is entirely self-taught for me. I've watched webinars, joined communities, and participated in remote conferences, but all self-managed and taught at this point. While my work and background align heavily with design systems work, it still feels like I haven't fully absorbed what I've learned and it's the first area in my years of professional work where I've felt true imposter syndrome. It's an interesting experience to have so much time and expertise behind me yet still feel as if I'm unqualified to be in this space. | No | I think we're getting there. Ideas like OpenUI and the Design Token Community Group feel like fairly well established steps in the right direction, but they seem to only be known to niche groups, wheras the W3C is a pervasive, industry-wide "oh I know them!" group. Much like how design systems and their concepts aren't globally known, I think folks are still having to naturally "find" the spaces versus there being an established, defined "this is what system standards are across the board" understanding, like WCAG or the W3C APG. | ||||||||||||||||||||||
16 | Yes | Courses and lots and lots of experience including Lead of a DS | No | I feel like a lot of what we do is already covered in other standards, though I do have industry-specific standards that does require things like WCAG. | ||||||||||||||||||||||
17 | No | I learnt to play with UI libraries and Figma variables on a website redesign project prior to my experience as a design system core designer. Everything else came from exploration on my own. Also took the nielsen norman DS training but it wasn't very productive 9 months into creating my own | Yes | We need space for creativity and open creation but it's essential for everyone to be able to access information and live as much of an ordinary life as possible when going about a product, a physical scenario (product or environment) | ||||||||||||||||||||||
18 | Yes | By being in tech since 1997 :D First as a developer, then as a designer. Working on building websites and apps for years, and seeing the connections and the infrastructure that drives them. | No | You can have foundational stuff (a design system of design systems) but the strength of a good design system is that it fits the org's ecosystem and the specific needs and requirememnts they have. Industry-wide principles? Yes for sure. | ||||||||||||||||||||||
19 | Yes | On the job. I started as a designer noticing inconsistencies in the way different apps with similar designs were being built. that led me to create shared stylesheets, the. shared components. the next step from there was design systems. it felt like a natural evolution. the question now is where to go from here? :) | i don’t think this is possible | i don’t think it’s possible to get everyone to agree on enough things. design language is one aspect. we will never all be on the same page enough with terminology of things like component feature properties or specific design token names etc. the specs we have now for a11y and design token names etc structure are probably as close as we can come | ||||||||||||||||||||||
20 | Yes | context and visibility into as many product teams at a place as possible. My path into design systems was to bounce around and help out wherever people needed help; if there was a task that someone needed something, I was there. Eventually, that evolved into my being the person who had the answers with regards to design standards and components. Not that I held office hours, but people would come with me with questions that I had answers to. | Yes | Sticky subject, for sure. I think it would need to be clear about what it was. The big thing about design systems and the components they contain is that they're dumb; they're not intended to to anything specific, you're just talking about a straight button or text input. The idea behind a design system is that it's baseline and anyone can pull it in and use it within their app, but there are no fancy bells and whistles. | ||||||||||||||||||||||
21 | Yes | I'm a four-time college dropout (just wish I had been smart enough to stay dropped-out the first time!) and everything I know I learned from internet self-study and from being on the job. With zero qualifications, I convinced people to let me build brand identities and websites and social media accounts for years. Eventually, we moved from a very rural area to a city for my husband's job, and I blanketed every agency in town with resumes until someone took me in as a contractual production designer for an investment management firm. Two years later, I landed a full-time gig in production design on the marketing team at an EdTech. I was there for six years and left with the title Principal Product Designer, Design Systems. Myself and one of our very talented graphic designers convinced leadership that we desperately needed a design system and we were allowed to "try" building one as a side project. Once we had the foundations in place, we got buy in and were allowed to make a formal team where that became our dedicated work. Fighting for the reclassification to "product designer" helped immensely when we both left the company and went on to run design systems at other institutions. I've always loved seeing patterns and systems and being the kind of person who proactively tries to plan for future roadblocks, which has made design systems work feel like the best niche I could have possibly stumbled into. | No | Every design system needs to be so flexible and customized to suit the team, it's product(s), and the industry in which they sit, that I think the ideal of a "standard" DS is ridiculous. The "right" way to accomplish something is incredibly objective so I don't see the point of creating additional barrier to entry. The things INSIDE your DS should already be conforming to standards and best practices for things like accessibility and security, but I don't think it's desirable to force strict guidelines on what a design system must or must not include, or how it's structured, as long as it works for the team that uses it. | ||||||||||||||||||||||
22 | Yes | I learned the skills to work as a design system practitioner through a mix of courses, communities, and tutorials, but mostly by building systems in real products and collaborating closely with engineers and product teams. The theory helped me understand best practices, but the real learning came from dealing with constraints, trade-offs, and adoption challenges. Working hands-on forced me to think beyond components and focus on governance, scalability, and how the system actually supports teams shipping software. | Yes | Yes. What we actually need is something closer to standards for how design systems behave, not how they look. With the constant evolution of technologies, frameworks, and tools, there are many moving pieces that make systems fragile and hard to maintain. A shared set of tool-independent, open standards could help lock down the fundamentals, things like accessibility expectations, token semantics, interoperability, and governance patterns, while still allowing teams to adapt visuals and implementations to their own context. The goal wouldn’t be uniformity, but stability and alignment, so teams can evolve their systems without reinventing the basics every time tools or platforms change. | ||||||||||||||||||||||
23 | Yes | Lots of self-learning, practice identifying patterns, learning how to abstract concepts, thinking in systems of things, iterate. | No | Every org is unique. I think a standard set of components would help, but I would't consider that to fully be a design system standard. | ||||||||||||||||||||||
24 | No | My skills have developed through a combination of informal training, hands-on experience, and ongoing self-directed learning. A foundation in design education gave me underlying visual and communication principles, and years of working in website design and development have deepened my practical understanding. I mostly continue to learn by exploring articles, podcasts, webinars, and the insights of industry experts. Staying engaged with the evolving conversation around design systems has been key to inform both my technical approach and strategic thinking. It helps that my personal value is also life-long learning, something I really enjoy. | No | While I see the value of shared principles (particularly around accessibility, inclusivity, and interoperability) I also appreciate that design systems are inherently contextual. Their success often depends on how well they adapt to a team’s unique environment, needs, and constraints. Broad guidelines and community practices are incredibly useful, but rigid standards could unintentionally limit innovation or create the impression that deviation is failure. A more effective model might be a flexible framework of principles rather than prescriptive rules. I like that most resources provide conceptual alignment themes while allowing for strategic adaptation. I acknowledge that this makes a clear learning path extremely difficult, but I also think everyones unique experience is what helps create individually-suited solutions. | ||||||||||||||||||||||
25 | Yes | On the job! I’ve worked on 2 design systems teams - one was at a startup where we were standing up the design system from scratch and currently at a large enterprise where there were a few iterations of the design system before I joined. Two very different situations, but both have been incredibly valuable in my design systems journey. | Yes | I think it makes a lot of sense to have some industry-wide design system standards. No matter what that nature of your company is or what tech stack you’re using, you’re generally building the same core set of components (form elements, content elements, etc) with common attributes. Having formal standards in place would make it easier for new teams to establish and build out their design systems, and in our AI world, could be a source of context for LLMs to quickly generate standards-compliant code. | ||||||||||||||||||||||
26 | Yes | Mostly through 15+ years of professional career. Seen many things out there, started to standardize/systematize and componentize before it was "cool". I think the mindset and the skills develop over time, but industry experience helps you identify patterns (as in "what systems are and how they are utilized somewhere" you can work from to level up the organization. | No | I think ARIA APG (https://www.w3.org/WAI/ARIA/apg/patterns/) already provide a great baseline for system work. It's more about expanding on those and being more active in W3C through working groups like design tokens that improves our industry than coming up with another set of standards (RE: xkcd standards punchline :). | ||||||||||||||||||||||
27 | No | I've read a few books and did some outreach for mentorship on LinkedIn, which proved helpful but difficult. But a vast majority of my education has been trial and error, building our system at Bass Pro. | No | I feel like every organization is too different, and forcing a system to abide by not only web accessibility standards but also some other layer of standards sounds like too much. | ||||||||||||||||||||||
28 | Honest answer, no. But that's part of the beauty of it, I'm figuring out as I go. I'm confident in my design foundations and communications skills, but I'm figuring out all the technical things. | Totally on the job. Learning by doing. Figuring out out as I go. I'm a natural curious person and love asking questions. I'm the type of person that will fill the awkward silence in a meeting with a question, because I never assume other people totally understand everything. | No | In a way we already do, it's the technical constrains and boundaries inherent to Figma. I think each design system can and should be as unique as the company they exist within. Because that system is solving for the problems of that organization. | ||||||||||||||||||||||
29 | Yes | I started off by learning at work. My company started a design system, and I learned a lot from the other designers and developers as I contributed to the system. I also read books and online about design systems to try to learn more, and took a React coding class. Over time, things started to go bad with our system, and I didn’t know what to do, so I started seeking out more design system education, and that’s how I got to the Question. This community has helped me learn a lot. | Maybe | That sounds potentially nice, but I’d want to learn more. | ||||||||||||||||||||||
30 | Yes | I got put into this job and learned everything by doing. The skills I have from doing consumer facing work is transferrable: understanding user problems and solving them. | Yes | If the product we build using design systems share the same standard, I don't see why not the infrastructure should be treated with different standards. | ||||||||||||||||||||||
31 | Yes | I've always been passionate about the space between design and engineering, so my focus on learning has often fallen into this space. Working on a design systems team directly has also been a core way of up-leveling my skillset in this space. | Yes | As an Engineer, I would say yes -- standards for development have led to stronger implementations and more accessible experiences, so I think that a standard for systems too would have value. | ||||||||||||||||||||||
32 | I've had the opportunity to work on ~6/7 design systems over the past couple of years, learning from practitioners with far more knowledge than me. At the same time, I'm acutely aware of my lack of experience, especially with much larger systems. | I was previously a web engineer, now working in UX design and development. I've learnt everything else on the job over the past few years. Working closely with people who have far more experience, combined with exposure to so many different systems in a short space of time, has massively accelerated my learning. Every system has different constraints, cultures, and maturity levels. You quickly learn there's no single "right" way to do this work. I also make a conscious effort to learn from the wider community online and seeing how other teams talk about their systems. That mix of hands-on problem solving and learning from peers has been far more valuable than any formal training path could have been. | No | One thing that makes the design systems community strong is the lack of a rigid, predefined path. Most of what we learn comes from experience, from each other, and from dealing with real constraints. That scrappiness is a strength, not a weakness. It would be too easy for us to become a slow to move monolith as systems level projects often are by their very nature. Design systems never exist in isolation — they sit on top of the web, apps, and other platforms that already have well-established standards around accessibility, performance, semantics, and usability. As practitioners, we should already be following those. In that sense, a lot of the "standards" we need already exist. I worry that introducing strict, industry-wide design system standards could pigeonhole the practice and slow down progress. There's also a risk of becoming overly system-focused — arguing about things like token naming conventions — rather than focusing on the intersection between the system and the end user, which is where the real value lies. That said, I do think there's huge value in better education and visibility around the standards we should already be following, and in sharing patterns, principles, and lessons learnt. I'm just hesitant to frame that as a rigid or prescriptive set of standards, because that could raise the barrier to entry and make the field less open than it is today. | ||||||||||||||||||||||
33 | Yes | Through direct experience | No | Recommendations, sure. Standards, no. | ||||||||||||||||||||||
34 | Getting there. I know the design side of things but not the code side. | By being on a dedicated DS team for the past 2 years and having a great boss/mentor (shoutout Taylor Cashdan!) | Not sure | I'm not sure on this one! | ||||||||||||||||||||||
35 | Yes and no. Imposter syndrome is such a difficult thing to navigate, especially in a space that is constantly changing. | The foundation is 14 years in design, combined with development experience, which taught me to think systematically before I even knew what design systems were. In both roles, I naturally think about patterns, reusability, and how decisions cascade through products. And that systematic thinking influences all my design work, whether I'm explicitly building a design system, or just designing features. In the earlier years of system work, a lot of learnings came from analysing what broke, or what didn't work. When developers couldn't implement components consistently, I learned about clear documentation and token structures. When designs diverged across teams, I learned about governance. When accessibility issues emerged, I learned to bake WCAG compliance into the system itself. Now a lot of it is by asking myself 'How can this be done better?'. A lot of writing, researching, and experimentation. | I'm not 100% convinced they do. I'm leaning closer to no. | The W3C works because it standardises infrastructure – how browsers interpret code – not design decisions. Design systems exist to encode the organisational opinions, brand expressions, and contextual choices that web standards deliberately avoid. Standardising component names or interaction patterns would strip away the flexibility that makes design systems valuable in the first place. Where shared conventions genuinely help – accessibility requirements via WCAG, token interchange formats via the Design Tokens Community Group – they already exist. The useful standards operate below the level of design intent. I don't think we need a governing body to tell us what a modal should do; we need teams empowered to make those decisions for their specific users and contexts. | ||||||||||||||||||||||
36 | Yes | Decades of the industry experience blended with three grains of mentorship, and boatloads of grit as a self-taught designer’s 😄 | Basing your system off of fundamentals, yes. The rest should be tailored to use cases. | Every system has different needs. | ||||||||||||||||||||||
37 | Yes | Self taught | Yes | Standards make it holistic | ||||||||||||||||||||||
38 | Yes | I learned meeting management, facilitation, and teaching from my undergrad studies (Technology Education). Color theory, layout, and typographic scaling from graphic design work, specifically on newspapers in high school and college as well as freelance projects. I learned about getting buy in and "selling" what I was working on from being the only graphic designer at a consulting firm (my first full time job). I learned systems thinking when responsive web and multi-surface branding kicked off--things HAD to work systematically, or they broke! I learned pattern recognition from years of personal trauma (lmao). And finally, I learned that all of this was "design system" work when my employer hired EightShapes to help get our act together; I was between projects and needed work to do. Almost 6 years and 3 systems later, I found my (current) niche! And I'm sure it'll become something else in a few years, as the industry (and myself) evolves. | No | We would have to agree on what a design system "is" and "isn't." I no longer thing that conversation is productive or fruitful. Systems need to be contextually relevant to the systems they need to operate within--and that's not even talking about design systems in particular. The idea that we need universality starts to feel like the anti-thesis of how we actually do our work (that it's so context-aware, and people-specific, and culturally driven). | ||||||||||||||||||||||
39 | Yes | I've been lucky enough to work with leaders who recognized my strength in systems thinking through regular product/web projects. In the process I met a singular mentor who was generous with her knowledge and empowered me to implement, and learn more. In the process, I've learned that the design systems community is close-knit and cares deeply about their specialization in a way that is more open source than gatekeepy. As a result, continuing education has consisted of attending conferences, reading articles, and following consultants who publish like Ben and Nathan Curtis. In terms of system adoption, my background in community design/urban planning has taught me how to effectively work with people to instill change — in a way that's more "deigning with" than "designing for." | Yes | It seems like a natural step for a specialization focused on codifying rules and encouraging broad adoption. Something of this scale would inevitably require a select group of industry leaders with proven experience, but it should also require a deep engagement/input process. We'd also need to make sure the overarching goal is articulated clearly — is the philosophy like a legal code, like WCAG or building code? Is it more of a community contract? How could it be distinct, and how could the meta design itself demonstrate best practices for systems? How would it position itself as something global? Would it come with libraries? Who maintains it? | ||||||||||||||||||||||
40 | Yes | Just through the grind, I wish I had the opportunity to be part of a large organization with a full design team, but that hasn't been my reality. Just me and a designer usually. | No | Design ideologies move to quickly for an industry standard system. But I guess I could see some sort of standard patterns of implementation for design tokens maybe? idk | ||||||||||||||||||||||
41 | Yes | Learned on the job, from ‘doing the doing’, learning from colleagues, whether that’s designers, developers or anyone in product! | Yes | To have standardized naming and building conventions to components and processes inside a/your design system. This is so you’re not starting from scratch or having to change things each time you start a new DS job/role/contract at a new company. It’s a mostly systems based job, so let’s get a more systems based global approach to as much of it as we can. That way a DS Design role can build, develop and grow… hopefully! | ||||||||||||||||||||||
42 | Yes | I am learning them in my current role. | Yes | To ensure that digital experiences serve humans well. | ||||||||||||||||||||||
43 | Right in between yes and no. So maybe. I still don’t get when people say they have 10 years of design system experience. But I’m still learning more about design systems everyday and still look forward to a career where I can continue to learn and grow. | Reading, the question, mentoring with Ben. Sleuthing the design system chats. | No | Would that make it far too constrained and cause systems to lose creative freedom? | ||||||||||||||||||||||
44 | Yes | Through working first as a DS consumer and then join a core DS team full time. During this time I also started reading books, articles, going to conferences and connect with people in the community to discuss topics. It has been a lot of learn by doing but also learning from other people that have been in this space for longer than me. | Yes | I think this could be helpful, many things about systems and how to approach them tactically can be standardized I think. It is something worth exploring. | ||||||||||||||||||||||
45 | Yes | Reading books like Atomic Design by Brad Frost, Expressive Design Systems by Yesenia Perez-Cruz, and InVision's Design System Handbook. Reading articles by subject matter experts like Brad Frost, Dan Mall, Jine Anne, Nathan Curtis, and others (including Ben Callahan). Studying open design systems like Material, Spectrum, Carbon, Lightning, Polaris, and many others. Trial and error. | No | I don't think we _need_ one, though I am intrigued by Brad Frost's idea of a global design system maintained by the W3C, so thousands of organizations aren't all building the same twenty-five or so common components. | ||||||||||||||||||||||
46 | Yes | Most of the transferable skills are simply building on those acquired at earlier stages of my career - Design Systems work just ties them all together, but wrapped up in a neat bow of the front-end UI development world which is the new part for me. | It's not clear to me exactly what this would entail. | Part of the reason companies have their own systems as opposed to simply adopting third party ones, is to get the ability to customise it for their requirements, so any set of standards would need to be sufficiently generic to account for this. There are also fuzzy borders to what a systems team should be doing, relating to the size of the organisation, what platforms or tooling are needed, and which other teams are implicated in this work. | ||||||||||||||||||||||
47 | Yes | (I'm a designer) The bulk of my learning about DS has been on the job. I have learnt a lot from peers in my team more experienced than me in the field. When I was "getting into" DS for the first time, I was learning about it through side of desk projects. When I got my first "proper" DS job, I learnt loads and certainly experienced a lot of imposter syndrome to begin with, especially when the more experienced designer left, leaving me flubbing my way through things a bit! There are no juniors or midweights in my current DS design team - it is only seniors, leads and SMEs. My perception is this is quite common, and I sometimes wonder what DS teams could be doing to help juniors get "into" design systems earlier. Do you need to have a good chunk of experience in design FIRST before you specialise in this niche? Do you need to learn how to fish before you help others to fish? On the other hand: in my experience this isn't the case so much in development, where grad schemes etc seem to ensure that juniors/midweights are exposed to DS or other niches early in their careers/learning so they can get a taste for everything. This sort of culture doesn't seem reflected in design. Should it be? | This isn't something I've thought deeply about too much so don't want to give to concrete an answer: but my instinct's answer to this is that: as design and code become closer, and AI tools take the lead on how we build experiences with a DS, I suspect this will become more necessary than ever | This isn't something I've thought deeply about too much so don't want to give to concrete an answer: but my instinct's answer to this is that: as design and code become closer, and AI tools take the lead on how we build experiences with a DS, I suspect this will become more necessary than ever | ||||||||||||||||||||||
48 | No | I have learned through exploration of other design systems and professional development coaching | Yes | Honestly, don't think I can define why, but I do recall that Brad Frost was in favor of it and I defer to him! | ||||||||||||||||||||||
49 | Yes | Learning by doing. Understanding the fundamentals of HTML and CSS, how design decisions can be shared between things. | Yes | to avoid reinventing the wheel for common things and for better compatibility across tools, frameworks, systems, companies etc. | ||||||||||||||||||||||
50 | Yes | Trial and error. | Maybe | Standardisation is a critical tool in compatibility and equality, and is necessary for such a diverse set of protocols and implementations as is found in the web. Whilst there are areas within design systems that would benefit from improved interoperatbility, standardisation would likely also bring with it constraints, and may hinder innovation. The trade-off is harder to balance. | ||||||||||||||||||||||
51 | Yes | The closer I am to engineering, the more I understand how to set up components, tokens, and the processes to ensure the org can adapt and use what we build. I also feel more confident learning from public resources and testing what I’ve built with my consumers. | Yes | For global components and shared foundation structures, I see a real need for this. Teams, including mine, often end up rebuilding the same things from scratch, not to add new features but to fix what was missed previously. For components shared across industries, having a standardized foundation would let us focus on product specific features while also understanding the standards for how components and design foundations should be used. | ||||||||||||||||||||||
52 | Yes | I've been in charge of several large website migration projects as both the designer, the developer and marketing lead. I learned a tremendous amount about inventorying assets and components, consistency, branding, infrastructure and navigation. As I had full accountability, I learned about organization and tracking of the details. It has stuck with me as I moved from website design to UI Designer, Product Designer and now Design System Lead. | Probably only for a subset of UI component or patterns. | I feel like there are too many different types of systems and priorities, discrepancies, tech debt, design debt mean every project has to work with compromises. There needs to flexibility. | ||||||||||||||||||||||
53 | Yes | In terms of my own experience, “on-the-job training” is the best way to put it. The skills I have now weren't developed overnight. I dove headfirst into a systems-specific design role because of my admiration for style guides and brand systems. From there, I just put in the hours: talking with users, collaborating with engineers, maintaining components, writing documentation, and reading PLENTY of articles and books. | Yes | We've reached the point where we could build the standard UI components using an architectural baseline. A shared skeletal system doesn't seem like a bad thing. It's the visual layer that distinguishes one product from the next. | ||||||||||||||||||||||
54 | Yes | Working on a design system for multiple years, seeing it's growth and change | Yes | That we we have something to measure impact towards, what success looks like, etc | ||||||||||||||||||||||
55 | Yes | Slowly, over time. As a web designer back in the day, learned strong foundations in web standards (HTML, CSS, accessibility) and UI design. Read lots of articles about interaction design and sweating the details. Created CSS style guides. In the UX/product world, thinking more in systems and patterns. Learned Figma. Learned to communicate with different functions and prioritize design system decisions. Absorbed good software design principles from developers. Worked on two failed design systems and one okay one. Read blogs from the likes of Brad Frost, Jina Anne, Nathan Curtis, Dan Mall, etc. | No | I haven't really thought of it before, what would the benefit be? There are some things that could be standardized across systems, but those standards are mostly relevant to the people building and using them than end users. Most design systems are internal tools built to suit the needs and tech of a specific company, so that might be a hurdle to standardization. But maybe there is something I'm missing. | ||||||||||||||||||||||
56 | Yes | mostly on the job, supplemented by consuming articles and talks, and connecting with others in the industry | No | design systems still feel so specific to the org they operate within, so while its helpful to have best practices, i think the content and communities out there already cover most of whats needed to understand the varying approaches. they also are evolving rapidly with AI and i have doubts that an org providing standards would be up to date tbh. | ||||||||||||||||||||||
57 | Yes | On the job. Lots of watching what has worked and what hasn't. Reading articles. Applying general knowledge of design and technology in specifics contexts. | No | Not every design system consumer has the same needs. The W3C defines building codes to keep buildings safe and stable for everyone; they do not define the details of how the building floor plan and decoration is laid out, that is customized to what's suited to those living and working in the building. | ||||||||||||||||||||||
58 | Yes | I've learned on the job, self-taught, by learning from the precursors of design systems. Books, blogs, tutorials, talks, interviews, etc. There's an overwhelming amount of knowledge to take in, the skills to be learned are not just technical (craft) but also social and psychological, because design systems are about people (soft-skills). | No | No, because there are so many nuances that is best not trying to package what a design system standards are. There's an organic aspect to design systems, and what works for an organization might not work for another, so there's no one size fits all. Something similar to when we hear that every person story is unique. | ||||||||||||||||||||||
59 | Yes | I like to joke that I didn’t find design systems as a career, design systems found me. Coming from a background focused on user experience, I just showed a lot of passion for how components operate, accessibility, and patterns that govern how these things come together in an interface. Every time I have tried to leave design systems, I somehow always end back up in the space, much of it has been self learning, but I’ve also worked with some amazing design. System leads over the years who have helped me absorb and learn a lot. | I’m having a hard time visualizing what the standards would be specific two design systems. I feel like much of WCAG is applicable to what we already do and care about. | I’m having a hard time visualizing what the standards would be specific two design systems. I feel like much of WCAG is applicable to what we already do and care about. | ||||||||||||||||||||||
60 | I feel qualified to be a design system specialist. However, I've found that the constraints of organizations (technical, experience, definition of quality) challenge me in terms of how/where/if I'm able to apply my experience into the system. | Becoming a design system practitioner was a long journey, starting as a print designer, shifting toward web and applying learnings from project to project and client to client. Eventually, I felt confident in my skills and experience to move toward design infrastructure roles. | Yes | What we currently have as industry-wide standards is often informed by a small set of larger organizations. If a designer or design system practitioner sees solution in Material Design it's viewed as a canonical and correct solution, which might often be not be the case (think the float label pattern for inputs). This makes our job as DS practitioners more challenging when we suggest that a given solution might create challenges for our customers. | ||||||||||||||||||||||
61 | A difficult question! I’d say now more and more, considering my knowledge and experience gained, but I still learn how much is still ahead of me. Definitely, when I started building the design system I own today, I didn’t feel qualified at all. | I had a mentor, a specialist with huge experience in building and managing design systems, who also shared learning resources with me. I relied on content from Brad Frost, Romina Kavcic and other experts in this area and consumed much open source content on my own. I also reached out to the other team within my company who already run an established global design system to consult them and look up to their libraries and patterns. To add to that, I loop AI in my workflow to learn more. | My first thought would be yes, however it happens in terms of design systems that waht works for one company, not necessarily does for another, so standardisation could be hard to achieve. However, I believe there still could be areas covered with standards, especially considering accessibility of design systems. | As mentioned above | ||||||||||||||||||||||
62 | Yes | Practice and from other design system professionals and other systems thinking books not related to design systems | Yes | Standards increase consistency. And isn’t there one of our main goals as design system practitioners? | ||||||||||||||||||||||
63 | No | Trial ( and so much failure 😅). Hiring coach to help me learn and bridge my larger knowledge gaps). And more trial and error. | Yes | At the very least,I can’t think of any good reason not to have a minimally viable set of accessibility standards. | ||||||||||||||||||||||
64 | Yes | Through brute force, and on the job training | Yes | global accessibility is so important, and there are less accessibility-focused design systems out there, and we need more. | ||||||||||||||||||||||
65 | Yes | Yes | Yes | W3C accelerated the web via standards, for the basics, by showing pros a path. Having something similar to accelerate the next level would be helpful for the pros to level up their work even more. | ||||||||||||||||||||||
66 | Yes | I didn't start out in design systems and only arrived here in my first design systems job 4 years ago. But all my previous roles helped me build a foundation of skills that lend themselves quite well to this role. My ideal work environment has always been partnering closely with engineering and guiding design intent through the process of implementation. Along the way I've learned quite a bit of front-end development skills especially in HTML and CSS. I think it is extremely useful to understand how the code works and how products are built in order to design a better experience. | Yes | I think it would be amazing if all the common permutations of functionality were standardized for commonly used components which we could then theme with tokens. With design systems we are trying to drive consistency of experience and this would go a long way in saving teams time and not having to reinvent the wheel constantly. This would free teams up to build the more complex components and patterns that make their system and products unique. Not to mention go a long way in establishing even better starting points for a11y in our systems. | ||||||||||||||||||||||
67 | I come from the brand side and consider myself a specialist in creating a visual language and design system for marketing collateral. I'm in the process of learning how to do the same in the digital realm. I routinely design in Figma (websites / product reskins) but work agency side so I don't typically have the opportunity to create a system that extends to all internal teams for a client (marketing + product). | Learning mostly on my own. | Unsure | Don't UX best practices cover a lot of the framework needed? I may be thinking too narrowly on this. | ||||||||||||||||||||||
68 | Yes | Yes. | Maybe | I can see the benefit of having standards for accessibility, but I worry about how we can innovate with an excess of standards. There's a balance in there somewhere. | ||||||||||||||||||||||
69 | Yes | In the early days (before I'd even created a DS), my company sent me and colleagues to Brad Frost's multi-day design system workshop. After that, it was all on-the-job learning (along with reading articles and regularly attending community events and talks, like this one). | Yes | I'm always an advocate of standards, even if they're somewhat loos and have wiggle-room. | ||||||||||||||||||||||
70 | Yes | Lots of self guided research and practice, plus on the job training, mentorship, reading, personal practice, shadowing, courses — and through the question & redwoods | No | I love those resources and look to them for baseline guidance but honestly have gleaned more from the open source culture aspect of design systems. There's already a tendency to follow standards from the big players (Carbon, Material) that arent always the right fit for every system/organization/team. But who knows — those open source resources are getting locked down a bit now, not sure what the future looks like. If orgs start hiding their documentation behind SSO, then maybe the emergency of industry-wide design system standards could fill the gap. | ||||||||||||||||||||||
71 | No | I've gained some DS skills both by direct experience and learning from the experience of actual design system specialist via books, courses etc. | Yes | If Design Systems become standardized, there would be many more teams/orgs that adopt it as a practice. | ||||||||||||||||||||||
72 | Yes | Working on guidelines pre design system gave and strong preference to work with internal teams gave the base. But coming from print design background I had to learn the code / tech side on the go. | No | DS standards depend on the org and agreements within the companey. | ||||||||||||||||||||||
73 | Yes | Started in graphic design, specifically branding and marketing that gave me an early intro to systems thinking. Brand suites, books/brochures, and websites with their style guides were my starting points. Then I did various bootcamps in front-end dev and UX design to get more technical skills. | Yes | Yes, BUT those standards should just be a starting point for any DS, not a prescriptive checklist. By having the standards be a basic starting point, this’ll allow teams to customize it to what they need for their products and consumers. Everyone will have the same basic standards, but add their own flavour to it. | ||||||||||||||||||||||
74 | Yes | Focusing on being a 'front-end' focused developer meant that at some point or later I was going to be introduced to the concept of design systems. One company I worked at in particular stressed the process of thinking from a design systems perspective when building a UI, after that I basically kept chasing that line of work in some form or another. | No | I'm saying no mainly because I'm having a hard time imagining what those standards and guidelines would really look like. It sounds like a lot of overhead to govern design systems on a 'world wide web' level. It already feels like there's a lot of noise on the internet and introducing a set of standards maybe feels counter productive. | ||||||||||||||||||||||
75 | Yes | just getting dropped in the ocean and swimming for my life, lol. That and just research and trial and error. | Yes | It's often a lot easier to get leadership to believe something matters when there is an official organization in the area that I can reference. Prevents people for looking at things as "just my opinion". | ||||||||||||||||||||||
76 | No | Reading books, watching videos, learning through real projects | Unsure | I’m not sure what this would entail! | ||||||||||||||||||||||
77 | I do, but there are degrees to this and I don’t like to put myself in with others I *know* are specialist specialists. | On the job. I am fortunate to have worked alongside skilled professionals that have been generous with their time and expertise. | Yes | This is obviously a nuanced subject and opinion will be divided about what constitutes best practice on a number of items. There would be heated discussions verging on conflict about calendar pickers, I don’t doubt. But an unbiased, informed base upon which design systems could structure their components and guidance would imo be a net positive for digital products. Even the (expected) think pieces dissecting everything that is wrong with them that follow their publishing would be good, I think. Get everything out in the open for the community. | ||||||||||||||||||||||
78 | yes & no. as an individual contributor, yes. still working and learning on the business values for a DS, that part, not yet | experience, articles, examples, mentors/coaching *cough* | again, yes & no. | design systems are made of pieces to help solve problems.. and it's THOSE parts that can have the standard (accessibility on a button).. | ||||||||||||||||||||||
79 | Yes | Yes | Yes | My answer is a “mostly yes” - and in a way I think we already have an “informal” set of standards as an industry with design systems. At least at the atomic — or even molecule — level, we have the “Big Design Systems” to look up to: the HIG (Apple), Carbon (IBM), Material, etc. At this point in web design, it would be very unlikely for any system to require a fundamental differentiation from the standard best practices set by those systems for something like a button. I may venture as far as to say even button groups, drop downs, menus, etc., have for the most part, been “solved.” However depending on an organizations needs and complexity larger molecules and organisms likely need more attention. Think: data tables, calculators and certainly templates. There is also the aspect of documentation and governance which I would love to see a bit more agreement in the industry on what belongs in component documentation vs. what belongs to content and accessibility teams. If I was in charge I would love to see enterprise design systems teams - working with product teams to source use cases to link in ZeroHeight - collaborating with a11y to write a complete accessibility section - work with content to advise on application - for as long as components live in Figma, a help section on how to use properties/ variables/ section on responsiveness or breakpoints That level of detail in documentation is far from standardized still. | ||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||