You can't get very far into a design system before you're talking about naming. Not the clever kind, but the everyday kind: what we call the components in a new system, the tokens, the layers underneath that hold it all together. We've been thinking about this one a lot at Baseline, because every team we work with runs into one of two problems here. Sometimes, both! And in today’s age of AI, it matters even more. But more on that soon.

The first problem shows up before anything gets made. Someone asks how we should approach naming, and the honest answer is that we don't always know right away. The team might still be proving the system matters at all, and naming feels a long way off. So the work waits. A doc gets started, comments collect, a few LGTMs land, and weeks go by. Naming starts to feel like a decision you only get to make once, so nobody wants to be the one to make it. I can't blame them, that's a lot of pressure to carry.

The second problem shows up much later, after a team has agreed on naming. The structure feels good, token and component work kicks off, and it's all coming together. Then the team notices the total count. There are a lot of tokens now, every one of them something to maintain as the system grows with the product. What started as 20 tokens has somehow become 487 variables to keep top of mind, and it only took an afternoon. If you've been there, you know the feeling well.

Think about that stalled team for a second. The decisions ahead aren't easy (they rarely are). What counts as a button? What color should a toast's background be? Those are hard calls. But teams make hard calls like that all the time. A color gets adjusted, spacing is modified, a component is rebuilt or repurposed, and it all feels normal enough. Naming is the one place that same team hesitates. There’s something about picking a name that feels different — it feels heavier. More permanent. Like it’s the one decision you won't get to change later.

And the team with 487 brand new tokens? They're in the same spot, just coming at it from the other side. If names can't be changed, what happens when one doesn't quite fit? We make a new one, of course. A new spacing value here, a one-off color there. None of it feels like a decision, because we're going one by one. But that's exactly what it is.

Maybe these were never two problems at all. One team treats every name as permanent, so choosing one feels heavier than it should. The other treats names as free, so making a new one barely registers as a choice. Different behaviors, but the same belief underneath: once a name is assigned, it can't be changed. But it can.

Now that AI can prototype almost anything, does it even matter what we call things? Figma is still Figma. But if a tool can generate a working screen in seconds, and push it toward production not long after, who cares whether a token is named Neutral/400 or Toast/Background/Default? As it turns out, the tools do. When AI reads through a file, our names carry a huge amount of the context it works from.

Toast/Background/Default tells the model exactly what the color is for. Neutral/400 tells it almost nothing. Our names used to be for us, so we could understand the work and build it right. Now they're the instructions for every tool that touches it. So naming matters more today than it ever has.

So what can we do?

If you're feeling stuck, here are a few small things that have helped the teams I've worked with keep moving. They're small on purpose, and each one speaks to one of the two problems from earlier.

First: name what you need this week, not what you might need someday. I know the worry here, I've felt it too. If we only name what's in front of us, aren't we digging a hole that's expensive to climb out of later? But the thing teams need early is a pattern for how names get made. Agreeing that primitives hold values and semantics hold meaning takes an afternoon, and it gives every future name a place to land. The pattern is the part to take your time with. The names can show up as the work arrives, and they get better once they've been used a few times.

Second: it sounds odd, but make new tokens earn their place. Before creating one, check whether an existing token already fits, or could stretch to cover both its old job and the new one. A rule we like to share with teams: if a value keeps showing up in different places, it's earned a name. If it's only turned up once, it's okay to wait. This one habit is most of the difference between 20 tokens and 487 (or more!).

📝 Tip: Renaming is faaaar cheaper than it feels. Aliased variables push updates right through the system, and bulk rename (⌘R) handles layers in seconds. A rename is just maintenance. Nothing's broken.

And third (my favorite): write down the why, right where the name lives. One quick sentence is enough. In Figma, that's the variable or component description, and those show up in search for the next designer who goes looking.

If your system already has more tokens than anyone wants to document by hand (it probably does), a tool like TJ Pitre's Figma Console MCP can help. Point Claude at your token or variable names and ask for a .csv with a drafted description for each. They won't be perfect, but correcting a guess is far easier than staring at hundreds of blank cells. That's been one of the bigger lessons for me: the corrections are where the thinking gets captured.

If you're somewhere in the middle of this right now, maybe staring at that naming doc that's been open for weeks, I hope this helps you feel okay about closing it. The questions inside still matter. You just don't have to answer them all today. Pick the pattern, name the thing in front of you. The why can live right next to it, and the rest shows up as the work happens.

And if your team has landed on a naming habit that's worked, or you've got a 487-token story of your own, let us know!

📬 From the inbox

This week's question came from a designer who's in the early stages of their first full-time design role, and feeling the pace of it all.

I'm a recent graduate and recently landed my first full-time job as a UX/UI Designer. I'm honestly very scared; LLMs are improving output rapidly and new tools and features are launching constantly, so I feel like I'm constantly behind. I try to keep up-to-date with the newest tools but it's hard knowing what will stick and what won't, and I also don't want to train myself into being dependent on AI workflows that may not be available later as pricing structures become firmer and we possibly get priced out of tools we used to take for granted. With this in mind, I've been trying to figure out how I can stay competitive. I've been thinking about specializing in design systems, accessibility, or designing for AI, but I'm at a loss as to if that's a good idea or even what I should do to make sure I'm competitive, particularly as someone relatively new to this field. Any words of advice or suggestions?

Avery

Designer

First off, congratulations! Landing your first full-time role is a huge accomplishment, especially right now. I hope you get to take a moment to celebrate it.

And that worry you described, about being far behind everyone else? A lot of people are carrying it right now, whether they'll admit it or not. Companies too. A new tool one week, a new model the next, and the feeds make it look like everyone has it figured out, like the latest model plus a brand new Mac mini has reinvented their whole life. You're far from the only one feeling it. I feel it too, and I know others on our team are in the same boat.

Here's what I don't love about this moment. 

There's a ton that's useful out there, and just as much that's pure hype. And hype costs you something. I came across a post recently that put words to something I'd been feeling: when your feeds are full of people who seem to have completely reinvented their work and life with AI, the small wins you get from learning start to feel like they don't count. You finally get a tool to save you twenty minutes, and instead of feeling good about it, you still feel behind. That's backwards. Those twenty minutes matter. What matters more is that you learned something and didn't let the unknown scare you off. I'm trying hard not to let someone else's highlight reel take away from my own progress.

When it comes to learning today's tools, the best advice I have is to pick a project that means something to you, and use it as the reason to start. For example, I've always wanted to see my blood sugar in my Mac's menu bar (I'm a Type 1 Diabetic), and I had zero idea how to build a native macOS app. After a few weekend mornings at a coffee shop, just talking to Claude Code like someone who already knew how, I've got something that works and that I'm sort of proud of. I can't explain the code and I have no idea how it all works, but it took some doing to get it somewhere that feels and looks good, solves the problem I was after, and has the polish I'd want in an app like this.

On specializing, I don't think you can pick wrong here. If I can offer anything from my own path, it's to follow your interests, not whatever feels most relevant right now. I fell into design systems because I love talking with people, I love building things for others to use, and I enjoy the world of systems-thinking. My brain can't get enough. Twelve years ago I had no idea this would turn into the field it is today. I just enjoyed the work. Enjoying it is what made me better at it, and it's taken me places I couldn't have planned from here.

So no, you're not behind at all. You're right at the start of something, keeping pace, right alongside the rest of us.

Congrats again, and please keep us posted on what you build and where you go next. Our industry is lucky to have you!

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

Incase you missed it

We're growing our contractor bench! At Baseline, we work alongside brand and product teams on the architecture, governance, adoption, and all the messy, human parts of making a design system successful. We care just as much about how teams work together as we do the components themselves.

If you’re excited about where design systems are going, whether you’re building in Figma, creating with AI, writing tokens, bridging design and code, or helping teams navigate change, we’d love to hear from you.

→ Apply here: https://tally.so/r/2EZDK9