The question we hear most often right now is some version of: are we ready for this? And the honest answer is almost never about how clean the system is.

Most design system teams are carrying a lot. There's the library to maintain, the documentation that's perpetually behind, the requests that keep coming in, and now a whole conversation about AI on top of it. Nobody has all of that sorted, and we don't think that's what being ready means anyway. The way we see it, being ready comes down to something more specific, and more achievable: knowing what your components actually do.

For us, there's a way of thinking about this that's been helpful. We think of every component in a system as making a promise. Give me these inputs and I'll give you this output, reliably, every time. Engineers call this a contract. It's the same idea behind APIs: you pass something in, something predictable comes back, and everything the component does internally stays internal. Whether or not your team uses that word, your components are already behaving like one.

What this changes is what's useful to document. Most teams document what a component looks like. Harder to write down, and more useful, is how it behaves: what it accepts, which combinations actually work, what happens at the edges, and what it doesn't support. That last one tends to go unwritten the most. And it's often the thing that matters most to the next person who picks it up. Knowing a component breaks with more than two lines of label text is more useful than a screenshot of it looking perfect.

We were working with a team a while back who'd inherited a system with some real gaps. Naming that had grown in a few different directions, components that had drifted from their source. The kind of thing that happens gradually, and nobody quite remembers deciding. What they'd done well, though, was write it down. They had a running document, not polished, just honest: here's where we're solid, here's where things are loose, here's what to watch out for. When they started using AI tooling, that document became the thing they fed in as context. It worked. The output was more accurate, easier to use, less time cleaning things up on the other end.

What made the difference was that the knowledge wasn't locked inside a few people's heads. That's the thing that tends to go wrong without anyone noticing. Someone makes a sensible call, it becomes practice, and three years later nobody's sure if it's a rule or just a thing they do. New people learn it by osmosis, or they don't. When AI tries to read the structure, it finds the same thing a new team member would: a component that exists, but doesn't say much about itself.

A small change in how you ask the question can open a lot up. Instead of asking what this component should look like, ask what it should accept, what it should reliably produce, and where does its responsibility end. A component documented that way doesn't need to be rebuilt. It just needs to say a bit more about itself than it currently does. And once you start asking that, it has a way of clarifying a lot of other things too.

📬 From the inbox

This one came in from a designer who's been actively adopting AI in their work and finding it hard to decode what companies are actually looking for:

I’ve been wanting to move on to a different company for some time now. While I’ve very actively adopted AI in my work and that’s what companies seem to want, it’s getting very hard to understand what they’re actually looking for (when teams are still figuring out new job descriptions as roles merge). How are recruiters and hiring managers approaching this? How should designers be approaching the job market?

A designer navigating the job market

What you're running into is something a lot of designers are dealing with right now. The teams posting these roles are often still figuring out what they actually need.

Job descriptions are being written while the role itself is still in motion. Specialist responsibilities that used to sit across multiple people are getting folded into one, and the language in the listings hasn't caught up. A title that says "AI-fluent product designer" might mean someone who uses generative tools for early concepting, or someone comfortable directing agent-generated code, or honestly something the hiring manager is still working out. The listing usually can't tell you which, and that's not on you. It's just where things are right now. Nielsen Norman Group and Smashing Magazine have both written about it this year, but you probably don't need a report to tell you what you're already experiencing firsthand.

The first conversation is usually more useful than the listing. That's where the actual shape of the role gets worked out, and asking directly what the AI part of the job looks like day to day will tell you more than the posting will. Most hiring managers will either give you a genuine answer or admit they're still figuring it out. Either way, you go in knowing something real.

The other thing that seems to make a difference is being specific about how you actually work, not just that you use AI. "I've actively adopted AI in my work" reads the same as most cover letters. Something like "I use AI to draft documentation and then review it against the actual component behavior before it goes out" tells someone something real about where your judgment sits. 

There's also something worth paying attention to in the distinction between creating with AI and maintaining what you've made — generating something with AI and getting attention for it has become relatively easy, but showing that you've kept something working, improved it over time, and made real calls about when to change it and when to leave it alone, that's a harder thing to demonstrate and increasingly the more interesting signal to hiring managers. Figma's 2026 survey of hiring managers found that 82% said their need for designers has stayed the same or grown, so the demand is there. What's harder to find is someone who can talk clearly about the decisions behind the work, not just the output.

None of this makes the search feel less uncertain right now, and I'm not going to pretend it does. But the uncertainty is in the market, not in what you've built.

Thanks for reading, and see you next week! 👋💛
— The Baseline team