| 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 053, deep dive hosted on May 16, 2025 with Ben Callahan and ToniAnn Drenckhahn. There are 61 answers. The question this week was: ----- Hello, system thinkers! Alright, we’re gonna have some fun this week. We’ve been at this for over a year now—this is our 53rd episode! I was chatting with this week’s co host (hey, ToniAnn!) about how much has changed in the last few years. We thought it might be really fun to have an episode of The Question where we take away all the constraints and imagine what the design system of the future might look like! Here’s your task between now and Wednesday: tell us what you think tomorrow’s design system will or should look like. The sky's the limit. Dream away. We’re looking for some idealism this week so that we can all broaden our perspectives, look up from the grind a bit, and remember what we’re really trying to accomplish with this labor of love we call design systems. If you could take any approach, knowing what you know now, using any technologies or processes or tools, what would you do? Also—and don’t miss this part—The Question deep dive for this episode will be on FRIDAY at Noon Eastern (not on Thursday). Here we go! Describe your ideal design system of the future. (Remember, no constraints, use your imagination, dream a bit, and have some fun with your answer! If you’re a visual thinker, draw a picture and add a URL to the image here!) How long have you worked on design systems? How many people are dedicated to design systems in your current organization? | |||||||||||||||||||||||||
2 | Question 1: Describe your ideal design system of the future. (Remember, no constraints, use your imagination, dream a bit, and have some fun with your answer! If you’re a visual thinker, draw a picture and add a URL to the image here!) | Question 2: How long have you worked on design systems? | Question 3: How many people are dedicated to design systems in your current organization? | |||||||||||||||||||||||
3 | I imagine the future of design systems as more of a marketplace. The design systems team manages and maintains the foundation, while other teams contribute based on their needs. It becomes its own ecosystem that shapes how we all work. Of course, I also see AI playing a role... but used more strategically, especially to support documentation and keep things up to date. And ideally, there's full leadership buy in, with teams aligned on shared goals and using the system in a consistent way. Integration just happens naturally. | 1–2 years | 11–20 people | |||||||||||||||||||||||
4 | The ideal design system of the future to me is creating an organization an culture that truly understands the line between the system, acknowledges it's utility and limitations, and has an internal marketplace where core tokens, core systems, and components are extended in a 'inner sourcing' model. | 6–10 years | 2–4 people | |||||||||||||||||||||||
5 | My ideal design system in the future is one where the systems technical aspects are deeply embedded in the company large language model in order for people inside the company to be able to work together with AI in generating ideas, crafting prototypes, code solutions, track analytics, analyze users feedbacks all in a seamless and accessible way to most people working on the product. From a less technical perspective I envision the future design systems to be embedded deeply in the company culture at each discipline and acting as some sort of backbone to a company overall UX strategy. | 6–10 years | 5–10 people | |||||||||||||||||||||||
6 | Boilerplate customizable by chatbot and canvas combination. | Less than a year | None | |||||||||||||||||||||||
7 | You will be able to define a component’s rules, props, and actions at a high level and utilize AI to create the component into a friendly version for all the frameworks you support. Think of a documentation first approach where the documentation becomes the prompt the AI uses to create the components. | 3–5 years | 5–10 people | |||||||||||||||||||||||
8 | code based, with design details and documentation integrated, robust request process and version management. | 3–5 years | ||||||||||||||||||||||||
9 | One with adaptable components that intelligently suggest themselves based on context and user needs. | 3–5 years | 1 person | |||||||||||||||||||||||
10 | Just having more buy in. Having a system that people wanted to use and saw the advantages of. Being able to make system wide updates that helped everyone and didn’t break things. | 6–10 years | None | |||||||||||||||||||||||
11 | Standard taxonomy and naming conventions, starting with the Universal Palette System. Much like rail gauges in American in 1880's, we need to create a single standard. It could be an independent standards commission such as W3C or an industry alliance - to allow us to merge two or more companies into one system seamlessly. | 6–10 years | ||||||||||||||||||||||||
12 | Some gamification tools built in for designers to access the information they need and use interactive decision trees as they go during design sprints or product brainstorming sessions. Design Systems should be built on the same platform as the products themselves and be built as a product with front end tools aligned with design tools. Drag and drop actual components while you design and build at the same time. Access documentation inline while you design anytime. Validate patterns as you go with direct access to other uses of that pattern. Additionally while designing, have a different settings on the pattern validation for "keep me in narrow guardrails", "I want to try a variety of patterns" to "blue sky - create new experiences". Design Systems shouldn't be static, they should be interactive and always provide details on where components and patterns are currently in use. | 3–5 years | 1 person | |||||||||||||||||||||||
13 | components still exist... but mostly for the computer. components are a combination of atomic elements, UI-generation prompts (see link below), and large-scale patterns that include frontend/backend concerns personalized, generative UI is here; DS work around building components is more about building systems of components that can work together to be generated in real-time. (this actually seems like MUCH more challenging design work!) DS work shifts more towards managing process and design quality than writing components views into components/patterns is automated, no need for docs sites or it's automatically generated docs/props tables designers split more into UX or visual - wireframes can be turned into product, or if hi-fi designs are needed, variants can be generated INTO figma or as screenshots out of code devs interact w/ components more via automation (not necessarily "AI chatbot" but partially generated code, autocomplete, or patterns/code-gen) example idea: https://www.designsystemscollective.com/how-ai-integrated-design-systems-and-generative-component-libraries-work-a060897b8abb | More than 10 years | 1 person | |||||||||||||||||||||||
14 | Ideal system of the future is seen as a creativity enhancer, not constraint by its users and the design system builders and maintainers are seen as partners to get things done. But in reality the design system is so easy to use that you don’t need them. Everything is straightforward and there are so many great examples of how things can be done, when the system user is engaging them it’s more to connect the dots on what other system users might be doing and get ideas or suggestions. Spinning up a prototype using the various customizable components the system offers is quick and easy and all the accessibility considerations are easy to grasp and implement as needed. The design system team acts as a customer success service and has people on the team with those skills that can take you from start to finish of a project providing cross functional support to all the stakeholders, ensuring the system user gets consistent information in a friendly and supportive way and they avoid any mistakes throughout the project delivery. | 6–10 years | More than 30 people | |||||||||||||||||||||||
15 | My ideal design system of the future is a living, intelligent ecosystem - one that not only supports product teams but actively collaborates with them. It’s seamlessly integrated into every stage of the product lifecycle, from ideation to delivery, and is powered by AI that understands context, design intent, and user behavior. It’s adaptive: rather than offering static components, the system evolves based on usage data, accessibility requirements, and brand needs. Components aren’t just prebuilt - they’re generative, capable of reshaping themselves based on constraints like screen size, content type, or regional design preferences. It’s universal but personalizable: the foundation remains consistent across brands or platforms, but customization is effortless. Teams can toggle between styles, layouts, or even interaction patterns based on specific needs, and the system ensures design cohesion and compliance in real time. It’s invisible yet powerful: rather than designers needing to search through libraries, the system appears where they are, suggesting patterns, flagging inconsistencies, and automatically updating designs when the system evolves. It's like a co-pilot—quiet when not needed, proactive when it is. It’s also deeply human-centered. Beyond visual and interaction guidelines, it encodes principles of ethics, accessibility, sustainability, and inclusion. Every component comes with intentional defaults - color palettes that consider color blindness, motion that respects vestibular disorders, and copy patterns that avoid bias. And finally, it’s self-sustaining. Feedback loops are built in - designers and engineers can submit insights, suggest improvements, or rate experiences directly within their tools. The system learns, adapts, and grows alongside its community. This dream system doesn’t just make building products easier - it amplifies creativity, ensures inclusivity, and empowers teams to design with confidence and purpose. | 3–5 years | More than 30 people | |||||||||||||||||||||||
16 | One that is truly adaptive and usage blurs the line between roles so that design and dev can truly collaborate. | 6–10 years | 11–20 people | |||||||||||||||||||||||
17 | My ideal design system of the future would give content guidance at the component level rather than being an outside page that users have to navigate to and read all together (this is already being done in some cases, Material comes to mind as one that at least includes brief content info per component). But even better, I'd love some way that when users drag a component from a Figma library, it exposes exactly the content guidance they need to write for that component in a way that's obvious and easy to implement. Bonus if this could somehow be tied to other documentation systems so that changes to one populate in the other automatically rather than having to be manually considered. | 3–5 years | 5–10 people | |||||||||||||||||||||||
18 | Been experimenting with AI past couple weeks: - Documentation easily produced with a prompt and the help of AI, in text, image and video form - Design system help GPT or AI chatbot to help answer questions - Plugin for Figma or whatever tool that reviews designs to give design system feedback on working designs In general, think AI can help with scale (serving more designers than design systems people). But the people element of design systems still needs to be there. At least in our team, the decisions in design systems are still made from designer need, and with consensus from the team. The posture/interface of the design systems function would be too cold if it was purely AI-powered. | 3–5 years | 2–4 people | |||||||||||||||||||||||
19 | Using existing files • all of DS is automated with parameters automatically created. • It is optimized for current and future platforms/frameworks. • LLMs work in conjunction with visual / tech parameters • ... but we still all have jobs, though we 'pull different levers' | 6–10 years | 11–20 people | |||||||||||||||||||||||
20 | Business-agnostic components (modals, accordions, etc.) would be fully accessible, standardized HTML elements from the W3C that can be fully styled to match a company's design language. This would enable DS teams to focus on building business-specific features that drive real impact instead of diverting focus on the same old components over and over, while ensuring minimum usability for all users. I don't want these business-agnostic components to be a 3rd party library that creates dependency maintenance for the team, which can create significant bottlenecks and issues with long-term support in mature systems that have been scaled across the company/products. Regardless of the front-end tech stack, they would be supported in every browser/device. Design Systems would focus on the developer/designer experience for adoption and contribution as they create a consistent bridge between disciplines, understanding and supporting the deadline pressures of individual teams while creating a space for collaboration and stability for others. Updates in the system and product leverage automation, making it effortless for teams across the organization to remain in sync with each other. | 6–10 years | None | |||||||||||||||||||||||
21 | Design systems need to grow beyond today's static models. Smarter, Adaptive Components Design elements should adjust automatically based on real-world use. That means factoring in: * User behavior * Device type * Accessibility settings * Personal preferences Like how your phone changes display settings for accessibility—but applied more broadly. Context-Aware Design Tokens Design tokens (the building blocks of design systems) should respond to: * Lighting and noise conditions * Device capabilities * Local cultural norms This would help make designs feel more natural and relevant across different contexts. Built-In Learning and Documentation The system would produce it's own documentation in context. With: * Live, editable examples * Clear explanations of design choices * Guided onboarding for new team members No more out-of-date documentation or steep learning curves. Documentation would adjust to your learning style and use case, giving you only what’s relevant, when you need it. Inclusive by Default Every component should be tested to support: * A wide range of accessibility needs * Neurodivergent users * Diverse cultural perspectives Ethical by Design The system should warn when a design pattern: * Might mislead or manipulate users * Could exclude certain groups * Risks violating regional laws (like those banning dark patterns) It should also suggest more transparent and respectful alternatives. With built-in adaptability, the system wouldn’t need version numbers or scheduled releases. It would evolve through use, respond in real time, and grow naturally alongside products and people. Not sure what this means for the future of design system designers! But maybe instead of maintaining static libraries, we'd focus on planting the seeds—setting principles and patterns—while the system expands and updates itself over time. | 3–5 years | 2–4 people | |||||||||||||||||||||||
22 | Good balance of foundational and composable components, flexible semantic tokens, and clear correlations to code APIs = ultimate AI UI generator with compliance and prototyping built in (Figma Make for your DS) | 3–5 years | More than 30 people | |||||||||||||||||||||||
23 | - Spending time on maintaining documentation sites is gone in favor of accurate AI responses. - Tools recommend existing components instead of potentially creating anything from scratch. - Cosmetic choices are less curated and more influenced. | More than 10 years | 5–10 people | |||||||||||||||||||||||
24 | My ideal design system of the future is alive. Not just technically scalable, but biologically intelligent. Not just a library of buttons, but a language of care. It adapts in real time to both internal and external change. It knows when consistency builds trust and when it erases context. It evolves with the product, the people, and the culture — not in spite of them. This system has four essential traits: Cultural fluency It listens to language, identity, and nuance. It supports inclusive defaults, but allows space for voice, tone, symbolism, and interaction that meet people where they are, not just where the brand is. Behavioral feedback loops It tracks how users actually engage and adapts guidelines based on real behavior, not assumptions. It learns. It retires what isn’t working. It surfaces what’s thriving. Cross-functional resonance It’s built by designers, engineers, researchers, writers, and ops — not handed down from one discipline. It reflects shared values and goals, not just visual alignment. Embodied values It doesn’t just express how something should look. It reinforces how something should feel. It reflects emotional cadence, sensory experience, and the tone of a company’s inner culture. You can feel the care, or the lack of it, in every interaction. In short: It’s not just a system for production. It’s a system for meaning. It scales clarity, not just sameness. It listens. It grows. It lets things die when they need to. That’s the kind of system that can keep up with the world we’re actually living in. | 6–10 years | None | |||||||||||||||||||||||
25 | composable parts, tokens, mise en mode, devs building it correctly, designers using it correctly and contributing. | 3–5 years | 2–4 people | |||||||||||||||||||||||
26 | I imagine building products looks very different. The live code is the source of truth and a design tool isn’t the starting point. Business logic and personalized user data are part of the design system (just system at this point), since there will be design decisions, interaction model decisions, and even parts of the user flow that are dynamic and depend completely on the individual user and what the system knows about them. In this world it’s all about foundations and connected systems. Some brands will control this more and see the value of a tight, consistent visual brand. Some brands will find that the value is delivering on user preference, almost like an OS. Tokens will matter more, theming will be crucial, and larger more complex and dynamic systems will all be connected. We’ll move from tending a garden to something that feels more like managing large, regional forest ecosystems. | 6–10 years | None | |||||||||||||||||||||||
27 | I will admit when I think of the "future" I'm only thinking in the near future (1-2 years). I love the direction of design systems being more integrated between design and engineering. I imagine a helper agent sitting in between the two roles. This LLM understands the design system, both from the design and engineering sides, such that when a designer describes the proposed interaction, the agent suggests suitable component(s). The agent then writes enough code to allow the engineer to hit the ground running and customize as needed. When changes are needed, the helper agent facilitates between design and engineering to fill in any gaps and suggest fixes. | 3–5 years | 2–4 people | |||||||||||||||||||||||
28 | I'd love to see how AI and design system component demo apps could play together and give designers and developers a more "realistic" way to see their designs in action. Wouldn't it be cool to use AI to prototype experiences without developers needing to put in the legwork to actually create the experience before we can all test it? AI could utilize coded components and build it out to quickly let us to play around with the suggested direction(s) for an experience and possibly get user feedback too! | 3–5 years | 2–4 people | |||||||||||||||||||||||
29 | Headless and modular. AI enabled to improve parity and accuracy across design, documentation, and code. Multi-platform to adapt to varying interface experiences and on any screen/device. | 3–5 years | Not currently working on a design system. | |||||||||||||||||||||||
30 | system of systems basic stuff owned by 1 enterprise team more specialized libraries building off the basic library leads for each of those libraries that work together to create a helpful network of components for designers and developers so, the dream is an organizational structure that suits the DS structure and helps to inform how experiences are built at the organization aligned humans, aligned components, aligned guidance, aligned code no egos! | 6–10 years | More than 30 people | |||||||||||||||||||||||
31 | Intuitive system to find the right UI, sped up by shared language between design, engineering and product. DS team spends more time collaborating with consuming teams to find patterns and commonalities, automation/AI takes over more production work and library maintenance tasks. | 6–10 years | ||||||||||||||||||||||||
32 | You know the Seinfeld episode where Kramer become Movie-phone guy? He says, "Why don't you just tell me the name of the movie you selected?" I'd love for users of a design system to be able to say "Here's the problem I'm trying to solve" and the design system would compile a UI with DS components for the user already laid out and ready to hook up to the back end. "My user needs to track their workflow of these steps and phases in this order" and the design system would create a usable and accessible layout using DS components. I'd also love if a user tried to customize a component but it was being incorrectly used or created an accessibility issue, they'd be given a warning, "Don't do that, it creates an issue for screen reader users." I'm sure AI can do this or will someday but I think supporting that at scale will become an issue as AI will need very good training to do that right and the DS team will have to ensure AI is correct. | 3–5 years | 11–20 people | |||||||||||||||||||||||
33 | I imagine a design system that’s more than just a library of components. It’s a UI platform, designed from the ground up to be multi-platform, fully declarative, and deeply composable. It would generate consistent, accessible interfaces across web, native, and even design tools, all from a shared foundation. The system wouldn’t just cover layout and style. It would express patterns, behaviors, transitions, and flows. You could build everything from a button to a full onboarding journey using the same core primitives. These primitives would be themeable, tokenized, and portable. Rather than asking product teams to build UI from scratch, the system would provide a host rendering model. Applications would declare what they want to render, not how to render it. That responsibility stays with the design system. No custom markup or styles, just intent passed to the runtime. To keep things flexible, the system would support sandboxed extensions. These would be isolated renderable units, written in a constrained DSL or built visually through an editor. They’d allow teams to introduce custom views or logic within guardrails, without giving up consistency or accessibility. Each extension would be reviewed, versioned, and shared through a marketplace that helps teams discover and reuse patterns. It turns consumers into contributors and makes reuse a first-class part of the workflow. Extensions would have access to a well-defined set of APIs: tokens, slots, host context, event hooks, async data. Enough to enable real creativity, but with the boundaries and support that help keep a system cohesive over time. This kind of design system isn’t just a style guide or a set of React components. It’s an ecosystem. It has a runtime. It has governance. It has telemetry. It learns and evolves. And most importantly, it gives teams the power to build great, on-brand interfaces quickly, without reinventing the wheel—or breaking it. | 6–10 years | I'm currently between roles. At my previous company, it was more than 20 people. | |||||||||||||||||||||||
34 | 1) A technical answer: Styling will be more abstracted from code than it is today. Components will resemble primitives a bit more, and much of design intent will happen in another layer. This allows styling and themeing changes to happen at runtime, thanks to AI. Allowing for much more personalization than today. Design System teams will become smaller, but more skilled as architects, instead of "component factories". 2) An organizational answer: AI-enabled Design Systems will become the "currency" for modern product design & development. It will be a catalyst in the collapse of the traditional EPD three-legged-stool, giving rise to new merged disciplines such as the design engineer. It will create new career pathways and optionality for those who choose to go into "product design", which will necessitate new education and training. Design Systems as a practice will thrive but likely live under the umbrella of a larger function that is part design, part front-end. 3) The random hot take: Ref sites will largely go away, with documentation made accessible via LLM-driven chat interfaces and assistants as well as other programmable end points. This is Gen Z and Alpha's preferred mode of info gathering, though some companies will keep their ref sites around as an accessibility measure for slow-adopting millenials. 4) The futurist answer: Metaverse and spatial computing will finally catch-up in the late 2020s, product surfaces will multiply, and design systems will enter a whole new era with multi-modal, audio, haptic, and 3D interfaces to account for. Teams will become more multi-disciplined than ever. The term "design system" prob won't even exist or have the same connoation anymore. By the mid 2030s, Figma will become a multi-purpose enterprise design & engineering ecosystem, and will acquire Adobe in a total reverse power move, which will not be blocked by the govt bc Trump shuts down the FTC as one of his last acts in office. | More than 10 years | We're an agency / consultancy | |||||||||||||||||||||||
35 | Design languages will play a pivotal role when design systems get more complex and companies have a multitude of design systems and asset libraries to cover their needs, but also taking into account that prompts including design language cues will be essential to generate code for components without losing cohesion with the whole, and feeding something "human" into the systems. | 6–10 years | More than 30 people | |||||||||||||||||||||||
36 | The design system of the future is a creative partner that understands intent, not just input. Anyone, regardless of role or skill, can describe what they want to build using whatever method suits them best: a sketch, a voice note, a signed explanation, a few bullet points, or even a PowerPoint. The system interprets that intent and brings it to life as a fully formed experience, grounded in consistent design, accessibility, and brand integrity. It removes the barriers between idea and execution, making creativity and contribution truly open to all. | 3–5 years | 5–10 people | |||||||||||||||||||||||
37 | Modest and obvious themes. 1. Meeting users where they are The ideal future is a system that better meets consumer where they are. Today, consumers need jump out of Figma of VS Code to visit one or two different documentation sites to understand the opportunities or limitations of a given component as well as the correct usage. In the future, consumers shouldn't need to leave their tool of choice. Whether via plugins, companions or whatever, design systems should embrace C.O.P.E. (Create once, publish everywhere). Guidance should be syndicated universally. 2. Doubling/tripling down on guidance past individual components Design system should get more comfortable extending guidance past atomic components and even past patterns. I've typically preached the idea that a design system can/should be the "style guide" for the organization. This can be CSS authoring, HTML authoring, token naming. In my experience, there's the craft that the design system brings to code, then there's product team development. Today, there's a shrinking rationale for a differentiation in quality. Co-pilots can help guide (enforce) engineers toward higher quality. And for designers, it can guide them toward better color usage, smarter hierarchy, etc. ... all things you might see when feature team designers decide to "get creative." 3. Empowering more prototypes, fewer static designs. Designers spending months iterating in Figma, recreating existing standardized interfaces has never seemed like a great use of time. We'll like start seeing this as Figma rolls out Sites (ignore the div soup) and Make. | 6–10 years | ||||||||||||||||||||||||
38 | - prompt to mockups using design system components & tokens - automated linting of screens and code for system discrepancies - real time system feedback from user (detached component -> prompt feedback) - automated tracking of snowflake component performance and iteration - shared ownership of the system across Product + Eng - sub-systems and supporting teams per audience/product lines | 3–5 years | 5–10 people | |||||||||||||||||||||||
39 | It's invisible. It /Just Works/. I'm speaking to the AI integrated future that, with every passing day, I am more and more buying into. This brings more questions than answers right now. For example, in an "AI" first organization, what do the interfaces and UX goals actually look like? We may not need a lot of the design patterns we've come to rely on for "moving data around in an interface built for humans by humans." This may be HCI's Jurrasic Park and CGI moment. We're watching the industry change, but we still need the expertise of our UX and Engineering pros to shape it into something real and exciting. Is everything a chat bot? I don't think so. Does everything need the AI middle-man? Probably not. Is this peak "data-driven design" where we're allowing an AI, fueled by LLM and databases, to create for us? Maybe this raises the impact and value of "designing from instinct" that's been pulled out of much of the practice. As I said above, I sense we are on the verge of a new HCI era similar to the "Web 2.0" spark that shifted what users were capable of achieving through the new paradigm of interactions with the web. | 3–5 years | 5–10 people | |||||||||||||||||||||||
40 | A system that everyone has a Framer like experience and are able to drop components right into what is being developed and have it full of template pages already to drop in a starting points as well with an demo mode you can switch to seamlessly. | 3–5 years | 2–4 people | |||||||||||||||||||||||
41 | No pictures needed :) future design systems emphasize the SYSTEM part. They are structured, self-reflective, and capable of learning - and GUIDING - future pattern evolvement. They close the gap between design intent and modern AI-enabled design tools by ensuring a structure that machines can use to transform intent faithfully. They're designed with this use in mind, and tooling to support them facilitates the granular analysis need to drive truly intelligent systems | More than 10 years | 2–4 people | |||||||||||||||||||||||
42 | deeply adaptable, personalized, and collaborative, leveraging AI | 3–5 years | 5–10 people | |||||||||||||||||||||||
43 | Built in and simplified for non-technical users, accessible, tested and updated regularly, super easy to implement and deploy (and hopefully customize within reason) | 6–10 years | 2–4 people | |||||||||||||||||||||||
44 | Dedicated design systems teams in organizations being the norm. Truly platform-agnostic design systems across devices and ecosystems (Think of VR). Full-stack practitioners who can leverage AI and emerging technologies to deliver fast and impactful value for internal users. Design systems for other media, for example, to customize storytelling in TV and Movies. | 3–5 years | 1 person | |||||||||||||||||||||||
45 | I'd like to think this is a near-future thing! ◉ A global design system exists that provides rock-solid meat-and-potatoes UI components with the ability to skin/theme them to our hearts' content. ◉ On top of that, orgs would have their own custom components and recipes at their disposal. ◉ On top of that, tooling that makes it effortless to build product high-quality experiences . "Make a new login flow" and "Make a homepage" would quickly! accurately! faithfully! use the design system infrastructure to create these experiences. I wish I had more time to paint a fuller picture, but those are some pretty accomplishable near-future things. | More than 10 years | ||||||||||||||||||||||||
46 | The documentation of the future will be beautiful. Not only because we'll have AI (hopefully) to lend a hand in building it, recording our design decisions, letting us know when maintenance and updates are needed, finding inflection points, but because product design will begin to rely on Dynamic UX and that can only come from robust docs. I also think design systems of the future will focus much less on visual cohesion (how a product looks) and more on experiential cohesion (how a product feels). If AI can grok a design language, look is in the bag. What we'll need to index on then is instead experiential cohesion across platforms, endpoints, languages, etc. | 3–5 years | More than 30 people | |||||||||||||||||||||||
47 | My ideal design system of the future leverages AI to directly translate visual designs and interaction specifications into production-ready, accessible frontend code in real-time. This empowers designers to effectively become the frontend developers, focusing purely on user experience and visual fidelity, as the AI intelligently assembles interfaces from adaptable, system-defined components and tokens. The design tool itself becomes the primary interface for building the final product. | 6–10 years | 2–4 people | |||||||||||||||||||||||
48 | I hope we can get to a place where everything is contextually aware. This is already happening to an extent in some design systems with modes, but I hope we can continue to extend and improve it. For example, we have light and dark modes or device modes, but what if we had different persona modes or accessibility modes? We want to apply the majority of accessibility features across the board for all users, but are there extremes that it might be helpful to turn on only for those who desire or need them? Utilizing AI to tailor UI elements, helper text, etc, for the occasional user vs a power user. Utilizing AI to warn when design and development files are out of sync, accessibility requirements aren't met, a state or use case is missing, etc... | 3–5 years | None | |||||||||||||||||||||||
49 | My ideal design system would probably run like infrastructure: quiet, stable, and literally everywhere. Syncing across Figma, code, docs, and tokens automatically. Change a token or adjust a core component and everything updates without breaking. Components would be smart and flexible. They'd adapt by brand, theme, or region without needing a dozen overrides. Contribution would be guided and lightweight, and documentation would build itself with built-in standards and accessibility. It would scale globally, work across platforms and team structures, and give clear usage analytics so we can spot what’s working and what’s not. Governance would provide just enough structure to keep things moving, but still be restrictive enough to not turn things into a free-for-all and feedback would be collected and analyzed frequently. I'm sure theres many more "cool" features I could bake in - but this right now is our ideal state. Find the core, then build more. | 6–10 years | 1 person | |||||||||||||||||||||||
50 | Maybe I'm just unimaginative, but I think we'll always have design systems in the current incarnations. Hopefully there is more convergence as today it is a little like having different steering interfaces for cars between brands. We've kinda seen troubles with car interfaces lately, as every car company thinks they can reimagine basic controls. The future is probably more nuanced. We'll still have the basic manipulation design systems, but as we incorporate AI into more apps, there is an opportunity to redefine what common interactions are. Thus, design systems will just evolve for new modes of interaction. | 3–5 years | 1 person | |||||||||||||||||||||||
51 | Documentation: Automated documentation updates dynamically with components, tracking usage to improve unclear content. Role-specific content adapts for different users. Interactive tutorials, natural language Q&A, and in-context help replace separate documentation sites. AI suggests components while users work. Adoption & Organizational Buy-in: Automated integration with all design/development tools within existing workflows. Automation converts non-compliant designs to system standards. Real-time ROI reports demonstrate stakeholder value while automated updates keep teams informed. Framework-Agnostic Components: Components deploy across any technology stack without translation. Universal architecture accommodates future frameworks, protecting organizational investment. Maintenance and Quality Assurance: Predictive reporting identifies expansion requirements before needs arise. Self-diagnostic components alert to bugs and potentially self-correct. Invisible version management handles compatibility automatically. The system adapts to organizational culture, generating consistent naming conventions and resolving conflicts. Design-Code Synchronization: Design and code exist as one entity with instant bidirectional updates. Visual and code editors show the same truth, eliminating design-to-development disconnect. Context-Aware Guidance: Intelligent detection guides component variations versus new creation and identifies consolidation opportunities. Real-time validation adapts to skill levels and roles, preventing misuse while maintaining flexibility. | 3–5 years | 5–10 people | |||||||||||||||||||||||
52 | An automatically updating and documented design system. | 3–5 years | 5–10 people | |||||||||||||||||||||||
53 | flexible, dynamic, automated and intelligent. Combination of automation and custom precision. For example: A) you started making a product without thinking too hard of what the system is. “It” intelligently analyzes your product and defines the set of guidelines and principles based on the existing product. “It” then seamlessly codifies existing and creates new assets based on what exists, as well as offers to generate additional components and UI flavors either via “auto-suggest” or based on a basic napkin sketch. B) As a designer, you can define a set of principles written in human language or via image references - how do you want the product to feel, look, what kind of interaction principles it should follow, etc. You can then turn your “napkin sketch” into a fully fleshed out “storybook” + interface using that set of principles. C) of course a designer would be able to change a component in their “Figma” and it would be updated in product. D) never think about “auto-layout” ever again. | 3–5 years | 2–4 people | |||||||||||||||||||||||
54 | Combination of components, layouts, and AI agents. | 3–5 years | 5–10 people | |||||||||||||||||||||||
55 | My ideal design system would include the following: Color: • Color palettes that offer text/background/border combinations/options that pass contrast without the painstaking work usually involved • Provide built-in color tokens • Provide built-in light/dark mode Components: • Allow user to drag/drop them into either preset positions or anywhere • Offer standardized meanings/functionality - no more confusion or overlap in usage (e.g., tags vs. chips vs. badges vs. pills, etc.) • Provide built-in accessibility • Provide built-in responsiveness Containers for everything: • Allow user to drag/drop them into either preset positions or anywhere • Allow user to use, create, customize their own desired layouts via AI • Allow for the addition of various combinations of components/content Tokens: Provide pre-built color, elevation, sizing, spacing, typography, etc., tokens. Analytics: Provide built-in tools for measuring ROI, etc. Finally, being able to "apply" the design system to an existing product in a test environment, noting all areas where issues may occur if implemented, would help product teams visualize and predict the amount of changes/updates/time needed to adopt the system before actually doing so. | 3–5 years | 2–4 people | |||||||||||||||||||||||
56 | My ideal design system would begin with a series of questions based on a decision tree. It would evaluate your role, your skill level, your need, and your available tools. It would use all this information to determine what kind of assets you likely need, their optimal format, and how many constraints are inherited in the collection presented to you. This means someone with expert skills and tech tools would receive a more robust and flexible library than some with limited needs and skill level to leverage the assets. It would create a tailored system to the user, while remaining cohesive and faithful to the larger system as a whole. | 1–2 years | 2–4 people | |||||||||||||||||||||||
57 | - interactive, break-apartable interfaces that are kind of like Nintendo’s switch 2 manual game where you can traverse an interface and its inner workings as it relates to design systems - tactile experience to learn and build with a DS - AUTOMATED DOCUMENTATION - components that take the form you need when you drop them into an interface (i.e, put an input in a form, it becomes a dropdown with all the right options auto populated) | 1–2 years | 1 person | |||||||||||||||||||||||
58 | Somewhere where design systems give freedom to experiment with different patterns and allow for creativity to flourish rather than restrict. | 6–10 years | 2–4 people | |||||||||||||||||||||||
59 | I think we’re going to dive a lot deeper into 3D and interactivity in the future! With the rise of AR, I see components mimicking tangible objects. It would be cool to live in a world where we can have things like Tony Stark’s JARVIS set up. | 1–2 years | 5–10 people | |||||||||||||||||||||||
60 | I imagine a future design system that’s deeply automated at its core. The foundational structure -- including tokens and logic -- would be embedded within an AI model, making rework practically obsolete. This would free us from the repetitive, manual parts of the job, allowing designers and developers to focus on what machines can’t do: being truly imaginative. The system would be dynamic and personalised by default. Each user would experience an interface tailored to their unique needs -- whether that’s enhanced accessibility or content delivered in the format they’re most likely to engage with. In this future, the design system wouldn’t just be a static library of Figma files or code snippets. It would be a living set of principles and instructions -- something equally usable by humans and AI. A collaborative blueprint that says: here’s how we build things, now go make something extraordinary. | 6–10 years | I'm a consultant so I work with a few design systems in different companies | |||||||||||||||||||||||
61 | A supercharged way of delivering product experiences. Reliable. Simple. Automated. Fast. | 3–5 years | 5–10 people | |||||||||||||||||||||||
62 | -Designers and developers trust the system that is ever-evolving and participate collaboratively while still remaining autonomous as a system. -Removes barriers to creative expression -Solving beyond accessibility compliance | 1–2 years | 11–20 people | |||||||||||||||||||||||
63 | - dependency graph between tokens, functions, components and ”closely related components” - built in tracking, not just number of instances in code/Figma but also rendered instances, and user interaction with instanses - auto-discover of potential needs, e.g. multiple teams building similar UI components (based on visual and/or code) - global state tracking, so that when an error occurs for a user the exact state (and the previous states that lead up to the error) can be reproduced - built in customization for users, e.g. allowing color token value changes (some prefer lower/higher contrasts), allow change of space to make a ui spacious or compact to some extent (some users prefer as much info as possible on the screen especially in finance) - some things are rather difficult to change some times, especially in CSS, since circumstances in a given context can cause a broken ui, I wish there was a more robust way to work with these changes. | 6–10 years | 5–10 people | |||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||
