It used to be that securing consensus and capacity to build a design system was hard. But today, design systems have become foundational to how software gets built with AI. A design system operationalizes the aspects of user interface design that can be codified; in an ideal world, that would free up human-centered thinkers to work more deeply on people, their needs, and optimizing their journey.
The industry is racing to encode everything
Today, our working stack houses files written for agents to read before they build, including ARCHITECTURE.md for how the system is shaped and DESIGN.md for the design language. Once the most-used prototyping tool, Figma has lost roughly 80% of its market value in under a year as teams build in new ways. Storybook is a solution for building front-end components; they recently shipped an MCP server so an agent reuses your real components instead of inventing new ones. Anthropic just released a Design Skill bundling design-system management, dev handoff, accessibility, UX copy — and user research and research synthesis. Impeccable “gives your agent the designer’s vocabulary”. I’m sure we’ll see more incredible innovations in the weeks to come. But will these materially improve how products get built?
The layer almost no one encodes is the user
Design systems ensure the product is consistent in appearance and underlying front-end code, but I don’t hear enough people talking about how we could do the same for user understanding. A user-research skill will write you an interview guide, but it doesn’t know your users. We also need to encode who you’re building for and the jobs they’re trying to do. That too should be written into the project as context before the build work begins.
Design systems are a great place to start — but not the end game
At the moment there are a lot of voices in UX focusing on design systems, and that’s a great place to start – it builds on years of momentum and ensures we meet users’ expectations regarding the visual consistency of the solutions we ship.
UX researchers make up a smaller portion of the UX community, but we need their voices as well — because the press to do more with AI isn’t going away. If we’re committed to shipping solutions that have utility for our target audience, we need to keep human understanding at the center of how we build. We have to move from isolated research repositories and shared drives to making foundational knowledge about the user integral to how products are built. It means human-centered designers and researchers must learn more about how AI tools and processes work, and find ways to bring that human perspective in.
What encoding the user might look like
A few people have started down this path. Erika Flowers’ Investiture framework (part of her Zero Vector methodology and ‘open-source ecosystem’) scaffolds a project around standardized markdown files including VECTOR.md, which references files with machine-readable personas, jobs-to-be-done, and more. This isn’t about using AI to enable the execution of research. It’s the idea that your team’s knowledge of users sits in the repository as doctrine, and every build inherits it, just the way a design system made every screen inherit your visual decisions.
You can’t set a research skill and forget it
Just because a research skill is available doesn’t mean it will ensure human-centered outcomes. You can’t just set it and forget it as you might with a well-documented design system. Someone must commit to observe and/or speak with users, interpret the findings, and document the results in a way the system can consume. Teams that treat AI as a reason to stop doing that will ship products that look polished but fail to meet the needs of the people they were built for.
What I’m learning by building it myself
I spent a decade building design systems — for a forty-product suite, the slow way. These days I’m working on a side project in Claude Code as part of my Zero Vector homework. I’ve paired Mantine’s public component library for the design layer with Investiture’s structure for the research layer. I’m early in the process, so I’m still refining my VECTOR.md file as I test and iterate concepts. This approach has given me the confidence to dig deep into learning the technology, because I know that the knowledge about my target user base is embedded in how the project is architected. It lets me assume an interdisciplinary, cross-functional lens while ensuring the engineering work stays grounded in user understanding.
Who’s encoding the user, not just the UI?
When AI tools first showed up in design, I told the junior designers on my team that they would be out of a job if only wanted to produce wireframes and mockups. But I believe that designers that care about understanding users always have a role to play. That’s now playing out at the level of how products get built. Design systems are a given; the acceleration that matters next comes from encoding not just the UI, but user understanding. I’m curious who’s balancing building fast with encoding UX research into the SDLC, and the different ways teams are doing it well. If that’s you — or you’ve seen it done well — I’d like to hear about it, so I can share what’s working with the scaling companies I advise.
Leave a Reply