Between the Lines: May 2026
Documentation that looks complete but isn't useful. Token foundations under pressure. Slot architecture on a live project.
This is the first edition of Between the Lines, our monthly series from inside the practice. Expect a mix of what we've been building, what's been on our minds, and a few things we think are worth your attention.
If you've been following the newsletter, you'll know that a lot of what Joey's been writing about lately, including You're Not Behind, comes from real conversations we're having with teams every week. This is where we get into more of that.
On our minds
The industry is tired, and most people working in it know it. Designers are trying to do their jobs while processing a constant stream of takes about whether those jobs will exist in recognizable form in two years. Every week brings another confident declaration about what's dead, what's next, and what you're already behind on.
What Joey keeps saying, and what we find ourselves repeating to teams regularly, is that most people are just now getting started. Which means if you're thinking critically about any of this at all, you're early, even if it doesn't feel that way.
What actually helps, in our experience, is pretty simple: one concrete thing, why it matters right now, and what to do with it.
In the work
Murphy has been embedded with a mobile design systems team working through something a lot of teams are dealing with right now: the gap between a component library that looks right and one that actually holds up when engineers, AI tools, and cross-platform requirements all start pulling on it at once. A lot of that work has centered on composability, specifically on slot-driven component architecture and where a design system's responsibility ends and the consuming team's begins. Murphy wrote about the broader argument in Slots and the control paradox, and working through it on a live project has sharpened a few of those opinions since.
Joey has been in conversations with teams trying to get their token foundations in order before the pace of change outruns them. One engagement recently wrapped a two-tier color system, primitives defining the palette ceiling and semantics absorbing all the product complexity above it, and the documentation work that followed kept circling back to the same question: how much of what you're building is for designers, how much is for engineers, and how much is increasingly for AI tools that need to read the system just as fluently as either? Getting those layers right, and agreeing on them early, is still the work. It hasn't changed, even if the audience for it has.
Katie has been deep in some internal projects we'll be sharing more about when the time is right, and has been using AI tools to work through parts of the design exploration process. She's been candid about what that's actually like, which is less 'here's what I figured out' and more 'here's what I'm trying'. We think that's the more useful framing anyway.
Notes from the work
Something that keeps coming up across the teams we're working with right now is documentation that looks complete but isn't actually useful, either to the engineers consuming the system or to the AI tools starting to sit alongside them in the process. The components are described. What's missing is the decision layer.
If you're running into the same thing, start with the decision tree rather than the description. Instead of explaining what a component is, explain when you'd reach for it over something similar: button vs. chip vs. clickable row, alert vs. dialog vs. toast. The cases where a component doesn't apply are often more clarifying than the ones where it does. It's slower to write. It's also what makes documentation load-bearing rather than decorative.
On our radar
Zeroheight recently launched an AI assistant inside Figma, so instead of switching to your docs site mid-work, the guidance comes to you in the canvas. We haven't had a chance to test it on a real project yet, but the problem it's solving is genuine: documentation gets ignored largely because it lives somewhere else. Bringing it into Figma closes that gap in a way that feels more durable than hoping people remember to check the docs site. We’re excited to give it a try.
TJ Pitre, who many of you will know from Southleft, has been writing a three-part series for Zeroheight on the future of design systems, and we've loved it. Part one looks at what happens when the interfaces your system needs to support aren't pre-designed anymore, they're generated, adaptive, and short-lived, and why most systems aren't structurally ready for that. Part two gets into why systems drift, why teams live with it, and why that gap costs more now that AI tools are trying to read your system as source material. Part three makes the case for a diagnostic layer between design and code that validates alignment in both directions and treats tokens and component contracts as the actual source of truth. Well worth reading end to end.
Figma also shipped their design agent last week, which lives directly on the canvas and works from your actual tokens, variants, and standards. We haven’t had a chance to test it properly yet, but the potential for documentation work is hard to ignore: bulk-updating descriptions, component states, naming consistency across a library... a lot of the work that usually gets deprioritized. We’ll report back once we’ve had some real hands-on time with it.
Thanks for reading, and see you next week! 👋 💛
– The Baseline team
Send it our way and we'll answer in the newsletter at whatever length the question warrants.
In case you missed it, our team published a few other things this month. Check them out below!
