What my portfolio can't show

I'm updating my portfolio and keep running into the same problem: I don't know how to show what the work actually is anymore.

The visual stuff is easy. A brand identity has a logo, a colour system, a set of applications. A product design case study has screens, flows, decisions mapped to user needs. You can look at these and understand what happened. The problem is that a growing part of what I do doesn't produce anything you can look at. It produces decisions. Rationale. Structure. And I have no idea how to put that in a portfolio.

The field has started to feel this. At Into Design Systems 2025, Justine Montgomery from Stripe gave a talk on design systems portfolios and her advice was telling: show your thought process, highlight decisions, record what went wrong. The emphasis was no longer on the artefacts. It was on the reasoning behind them. A real shift. But it still assumes the reasoning was expressed through something visual: a component, a token system, a Figma library. What happens when the primary output is a YAML file?

Nathan Curtis, who has been building and consulting on design systems since 2006, described his 2025 work and it stayed with me. He spent the year in a text editor, not Figma. His team was expressing component decisions as structured data: anatomy, props, variant logic, token references. Designers were auditing code and producing specifications that generated new code. Developers were generating the visual examples designers used to produce. The line between disciplines was collapsing. The artefact left behind was a data file. Not a frame. Not a library. A YAML file that described what a component is, what it can do, and how it should behave across every state.

That is real design work. The decisions embedded in a component specification — what a prop can accept, which elements are always present and which are optional, when a variant applies, what it changes — are design decisions. They require exactly the kind of structural judgement that good design has always required. The format is different. The precision is higher. But the thinking is the same.

The portfolio format for this work does not exist yet.

There is a precedent, though. Information architects faced a version of this twenty years ago. Their primary output was not visual: it was taxonomies, site maps, content models, metadata schemas. The design work happened in the structure, not the surface. And for a long time, IA practitioners struggled to explain what they did to people who were looking for screens. The solution was not to produce fake screens. It was to document the reasoning: here is the problem, here is the structure I chose, here is why that structure serves the people using it. The work became legible through the quality of the argument, not the quality of the image.

That same logic applies now. If the primary output of design systems work is a decision, then the portfolio case study is the decision itself: why this component boundary and not that one, why these props and not those, why this token structure and not the alternative. The artefact is the reasoning made explicit.

Making reasoning explicit is not natural to most design workflows. Figma does not have a field for "why." Most design systems documentation records what exists, not why it exists the way it does. Adobe's Spectrum team noted this directly in a 2024 piece on decision-making: unless decisions are documented and shared, nobody can know what's beyond the visuals, all the choices and conversations that went into building the system. They were describing an internal problem. But it is also a portfolio problem.

The second pressure is AI. Design systems are increasingly being consumed by machines, not just people. AI code generation tools, coding agents, LLM-powered workflows: all of these can generate UI from a design system, but only if the system gives them enough to work with. A polished Figma library with no structural metadata is nearly useless to a machine. A component specification that describes anatomy, props, states, and token references in a structured format is immediately actionable.

Supernova put it plainly in late 2025: the problem is not that AI is bad at design. The problem is that we have not made our systems machine-readable. The requirements for machine readability are almost identical to the requirements for human clarity. Consistent naming. Explicit intent. Documented rationale. Context about when to use something and when not to. What machines cannot do is ask a follow-up. So if the answer is not already in the system, the machine will guess. Often badly.

This changes what it means to build a design system. You are no longer building only for designers and developers who share context, can ask questions, and infer from brand knowledge what a token means or why a component works the way it does. You are also building for a reader with no context and no tolerance for ambiguity. That reader is an AI tool generating production code from your decisions.

The designer who can make those decisions explicit, who can articulate not just what but why in a format structured enough for a machine to act on and clear enough for a human to trust, is doing something the field does not have a name for yet. And no established portfolio format to match.

Back to my own situation. I am updating my portfolio and trying to make the work more visual and legible. The design side is clear enough. The responsible AI specialism is harder to show. Not because the work is not real. Responsible AI work is mostly decisions: which tools are appropriate, which governance questions need to be asked, where the risks are, how to communicate them to a team that is not thinking about them.

It is the same problem. Making decisions legible. Producing outputs that are structural rather than visual. Finding a way to show thinking that left no image behind.

I do not have a clean answer for how to show this. What I have is a clearer sense of what the question is. The portfolio problem is not how to present work that looks good. It is how to demonstrate competency in a discipline whose most important outputs are invisible.