Hey and welcome back to a new week!

I've been thinking about the skills that become more useful as AI takes on more of the execution. Design systems are very high on that list, and I don't think that only applies to juniors.

This week, I want to look at how shared components, clear guidance, and thoughtful maintenance can help the things you build feel like parts of the same product.

In this issue:

📕 NON-FICTION BOOKS USED TO BE HARD READS FOR ME - NOT ANYMORE

Most people who read Atomic Habits remember one line: small habits compound. Here's the rest worth keeping:

Shortform breaks down books like Atomic Habits into the key ideas, the reasoning behind them, and how to put them to work. This one takes about 15 minutes.

Then do the same for the next book on your list.

Start learning!

If I were choosing a design skill to invest in right now, design systems would be very high on the list. And I would say that to an experienced designer just as much as someone looking for their first role.

The reason starts with what design systems have always been there to do: help people build a coherent product at a faster pace, with a shared understanding of how things should work.

A designer should be able to find the right pattern without reinventing it. A developer should be able to understand the expected behaviour of a component. Someone joining the team should have a place to learn the product's standards instead of piecing them together from five colleagues and three outdated files.

A useful design system gives those people a common reference. Now there is another participant that needs that reference too: the coding agent doing part of the building.

In teams where developers and designers are handing more implementation work to tools like Claude Code or Codex, the guidance cannot only work for the humans anymore. The agents need a way to find and use it too.

Otherwise, the agent can produce something that looks plausible in isolation but does not really belong to the product. It might recreate a component that already exists, invent another spacing value, or use a familiar control in a way that conflicts with the rest of the experience.

You can correct that screen by screen. But if several people are generating UI, the same decisions will keep coming back. A shared system becomes more useful when those people and their tools can actually build from it.

That does not happen just because you have a well-organised Figma library or a documentation website. Those may be useful for a designer who knows where to look. An agent needs access to the relevant components, rules, and examples in a form it can work with.

And giving it everything at once creates a different problem.

AI models have something called a context window: a limit on how much information they can work with at once. Think of it as the space available for the current task, instructions, code, retrieved documentation, and the conversation around the work.

If you fill that space with the entire design system and all its documentation, you leave less room for the other things the agent needs. The feature requirements still matter. So do the existing code, dependencies, and decisions made along the way.

That is a simplified picture. Some tools can compact older context to keep working, and agents can retrieve information again when needed. They do not all simply hit a limit and forget everything. But the underlying constraint remains: the model cannot use an unlimited amount of information at the same moment.

So a good setup helps it find the relevant part of the system when it needs it. If it is building a form, give it the form patterns, the appropriate components, and their usage rules. It should not need to read everything about navigation, charts, and every other product area first.

This is already a practical concern for system teams. Carbon's guidance on token conservation describes loading relevant guidance as needed instead of injecting the whole thing into every request.

To me, learning how to make a design system useful to agents is a cutting-edge skill right now. You are connecting design decisions to how products increasingly get built. That is a substantial area to explore, whether you eventually specialise in systems or use the knowledge as a product designer.

Before getting lost in AI tooling, understand what a design system is, what it contains, and what it is meant to accomplish.

Typically, you are dealing with several connected layers:

The exact setup varies. But a page of colour swatches is not a complete design system. Neither is a large collection of components without much explanation of how to use them. Those can be useful parts of one.

The value comes from helping people make and reuse decisions. A system needs to be usable in the work. If nobody can understand it, find the right thing, or contribute an improvement, the number of components in the file does not tell you much.

For learning this, I would start with Dan Mall's Design System University. Two good entry points are How to Use a Design System in Figma and Make Design Systems People Want to Use. Both are currently listed as free.

Some of this material predates the current wave of coding agents. That does not make the fundamentals obsolete. You still need to understand reuse, consistency, adoption, and how a system serves the people working with it. The AI work adds another layer to those questions.

Learn that foundation, then explore how to make it work for this additional audience.

I would not wait for one definitive course that tells you exactly how all of this should work. The tooling and approaches are still changing. You can learn a lot by following people who show their experiments, explain what they tried, and make the limitations visible.

Two people I would follow here are Cassie on LinkedIn and Sil Bormüller, who runs Into Design Systems. They are worth paying attention to if you want to go deeper into where design systems and AI workflows meet.

When you look at a demo, ask what made it work. How did the agent find the correct component? What instructions did it receive? Did it reuse the implementation or just produce something visually similar? What did someone have to fix afterward?

That will teach you more than only looking at the finished screen. You want to understand the setup well enough to experiment with it yourself.

In many roles, your first experience with a design system will be using one that already exists. You may contribute later, but you do not need to own the whole system to benefit from understanding it.

In startups, you may find yourself creating something new much earlier. I have been in that position multiple times. In other teams, much of the work is learning the existing standards and making good decisions within them.

Both are useful skills. I would start by getting comfortable consuming a system, then bring a coding agent into that exercise.

There are large systems with official AI tooling you can explore:

You only need to choose one. Follow its current setup guidance; these tools are evolving, and the right entry point can change.

Then give yourself a small brief. Build a settings flow, a record-management screen, or a simple dashboard using that system's existing components and conventions. Use realistic content and include the states that matter to the task.

The goal is to make something that looks and behaves like it belongs in the product family the system comes from. Resist immediately replacing everything with your own preferred styling. See whether you can work within its language first.

As you build, pay attention to what you need to tell the agent. Which documentation helps? Where does it make assumptions? Does it use the actual components, or copy their appearance? Can it carry the same decisions into a second screen?

You still need to judge the result. A connected tool gives the agent access to guidance; it does not guarantee that every choice it makes will be right. Finding those gaps is part of what you are learning.

Once you have experienced that from the consuming side, building a small setup for yourself becomes a much more interesting exercise.

You could create a reusable starting point for the kinds of prototypes or side projects you regularly build. Define a few foundations, a small set of components, and clear instructions about how to use them. Then work out how your coding agent should find the relevant guidance.

Keep it small enough to use. You do not need forty component types before you have built anything with it. A couple of real workflows will expose much more useful questions: what repeats, what needs a variant, and what should stay specific to that project?

Maybe you want a starting point for take-home tasks too. Where an assignment permits reusable code and AI assistance, that could be useful. Follow the task's rules and be clear about what you brought with you. A personal system should help you focus on the problem, rather than force every brief into the same generic interface.

This can also become a proper side project. In my article on choosing portfolio projects, I talked about the value of something you initiate and build yourself. A small system that you actually use fits that idea well.

The case study could show the problem you wanted to solve, the decisions you made reusable, and how you made them accessible to an agent. Show it being used in more than one small project. Explain where the first setup broke down, what you changed, and what still needs work.

That is much more interesting than presenting a wall of buttons and saying you built a design system. You can show the system doing its job.

You do not have to become a full-time design-systems specialist for any of this to be valuable. As a product designer, understanding the system helps you use what already exists, recognise where it falls short, and collaborate on something better.

When you add an understanding of how agents consume that system, you can also help shape the conditions under which the product gets built. You can make the shared decisions easier to find, apply, and check.

That is why I would invest in it now. Learn the fundamentals. Use an existing system with a coding agent. Then, if it interests you, build a small setup of your own and put it to work.

You will learn about design, implementation, and the relationship between the two. That is a very useful place to build your skills right now.

📚 READING MORE BOOKS IS NEVER WRONG BUT IT DOESN’T HAVE TO COST SO MUCH TIME

What if you could learn from 100+? Shortform distills the key ideas from the books you keep meaning to read, like Atomic Habits and The 48 Laws of Power, into guides you can finish in minutes.

Start learning!

Jenn Choi is a New York-based product designer and NYU graduate who brings technical curiosity into both her main projects and her experiments.

You might recognize Dandi, the Figma Buildathon project she worked on with teammates including Beverly and Queenie, whom I have featured before. But Jenn’s portfolio offers more than another look at a familiar project.

She tells the story from her own perspective and shows a willingness to explore how software, AI, and physical interactions work together. Let’s look at what comes through well, and where she could make that profile clearer.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video portfolio review? Look no more. I do offer these as an async service you can book directly with me here.

Keep kicking doors open and see you next week!
- Florian