Redefining what one designer can ship with Claude
How I rebuilt my design workflow around Claude as a collaborator, using written skills to generate production-ready components, and expanding my output without expanding the team.
I'm the sole UX designer and researcher at Voxpopme, responsible for the full product experience on a product that kept outgrowing what one person could ship. Rather than hire, I changed how I design, building a library of written AI skills that encode my design decisions, accessibility requirements and the reasoning behind them once, so Claude can generate consistent output from them every time. That shift, from designing components to designing the instructions behind them, is what lets one person operate at team scale.
From designing components to designing instructions
The conventional response to a product outgrowing one designer is to hire. I took a different route.
Because if Claude can generate production-quality output then the bottleneck stops being execution and becomes the quality of the instructions. So I started treating skills the way I'd always treated design systems, as reusable references that encode a decision once and apply it everywhere, which means I write a skill once, Claude generates from it, and the same file reliably produces chat components, presentations, UX copy, and charts and diagrams.
The practical effect is that almost everything about my week inverted. Rather than building each component by hand in Figma, writing copy separately and pasting it in, and re-explaining the same design rules every single time, I now encode the decision once and let Claude handle execution while I handle the thinking, so my output is limited by the clarity of my reasoning rather than the hours in the day.
The skills I built, and why
A skill is a markdown file that encodes design decisions, accessibility requirements and the reasoning behind them, so writing one is a design act in itself, since the decisions are expressed in language rather than pixels.
Claude reads the relevant skill before generating anything, and I maintain a library covering the full range of Voxpopme outputs, from the platform agent design system and the presentation generator through to the copywriting voice, the chart selection rules and the customer archetype identifier that maps a user's language to the right product positioning.
## Colour, teal text on light backgrounds
Brand teal #58B999 fails WCAG AA at body size. ← the reasoning, not just the rule
Map teal text on white to Dark Teal #2E7D60 instead.
## Anti-patterns ← negative examples are the best guard rails
Never put white text inside sentiment-coloured chart bars.
## Brand tokens ← one source of truth, reused everywhere
--purple: #341C4C --teal: #58B999 --teal-text: #2E7D60A fragment of one skill. The comments mark what makes it reliable: it encodes why, names the anti-patterns, and points at a single set of brand tokens.
What makes a skill actually work
Skills fail for the same reasons design systems do, either too vague to act on or too rigid to handle variation, so the interesting work is in what makes one reliable.
The first principle is to encode the reasoning rather than just the rule, because a rule that also explains why is one Claude can apply to edge cases it never anticipated. The clearest example is accessibility: rather than "use teal for text," the skill states that the lighter teal fails WCAG contrast at body size and should map to a darker variant, which holds up everywhere rather than only in the case I happened to write for.
The rest follows from treating skills as living design artefacts. I keep the stable rules separate from the ones that evolve, because things like voice and visual identity change rarely while component patterns move with the product, so separating them means I can update one without breaking the other. I lean heavily on anti-patterns, since a rule like "never put white text inside sentiment-coloured chart bars" only exists because I'd watched it go wrong, and negative examples turn out to be the most reliable guard rails. And I treat every skill as iterable, which is how the platform agent skill went from having no accessibility constraints in its first version to automatically handling contrast after an audit surfaced the failures.
What this enabled
Skill-driven generation changed what actually fits in a working week.
A fully formatted Voxpopme deck, with the correct layouts, sentiment chart system and typography, now comes out of a single session, so what used to be half a day is 20 minutes of review. The platform agent design system covers 53 chat components, which would have taken weeks to build by hand, however writing the skill took two days and every component since has stayed consistent without me touching it. And UX copy for Compass, from loading states to error messages to onboarding, is now produced in the same session as the layout, because the copywriting skill applies the voice automatically, so I review rather than write from scratch.
What this says about how design is changing
The question for a hiring manager isn't whether a designer uses AI, because everyone soon will, it's whether they understand it well enough to build reliable systems with it rather than treating it as a faster Figma.
Writing a skill forces you to articulate every design decision you'd normally make implicitly, which forces a kind of clarity, so a designer who can do it understands their own work at a deeper level and can hand that understanding to engineers, product managers and stakeholders far more effectively than someone who keeps it all in their head. The output of this workflow isn't just faster design, it's design that's documented, consistent, accessible and transferable, and that's the real shift.