Case studyCycode AI Design OpsSenior Product Designer

Design ops, run on AI

I built a set of Claude skills that automate the parts of design work that don't need a designer — microcopy review, design review, documentation, planning, even templated screens. The whole team runs on them: designers, front-end, and PMs. For six months, they helped me cover a Head of Design's workload without a Head of Design.

Product
Cycode — enterprise application security platform. Internal design operations
My role
Senior Product Designer. Built the AI workflow; ran lead-level responsibilities in practice
Built on
Claude skills · Claude Design integrated with the design system from code · MD docs
Users
The whole product team — designers, front-end, and product managers
+15%
more work taken on and closed per quarter, thanks to automation
Team throughput
+4
more design epics delivered in a quarter vs Q1 — same team
Quarter over quarter
53 days
design review cycle, via the Claude review skill
Iteration time
01

The problem

A small design team has a hidden tax: the work that isn't designing. Microcopy passes, design reviews against the system, writing documentation, generating planning tickets, building the templated screens that don't really need a designer's judgment. It's necessary, it's constant, and it eats the hours you'd rather spend on the hard problems.

Then the Head of Design was out for six months. Now add planning quarters, distributing tasks, unblocking the team and answering product managers — on top of the design work that doesn't stop. The honest options were: let quality slip, let throughput drop, or find leverage. I built the leverage.

The non-design tax
Microcopy, reviews, docs, planning tickets, templated screens — hours every week that produce necessary output but don't need a designer's craft.
A leadership gap
With the Head of Design out for six months, planning, task distribution, and cross-team coordination landed on me — in practice, if not on the org chart.
Reviews as a bottleneck
Design review against patterns, the system and internal docs was slow and manual — a five-day loop that held up everything downstream.
A team, not just me
Any fix had to work for front-end and PMs too, not just designers — otherwise it's a personal hack, not a team capability.
02

The calls I made, and what they cost

The instinct under pressure is to work more hours. I chose to build tools instead — and to make them the team's, not mine.

Decision 01
Absorb the extra load — or automate it?

Covering a leadership gap plus the non-design tax, the default move is to grind: longer hours, more context-switching, hope it holds until the Head is back. It's the fast answer and the one that quietly burns you out and drops quality anyway.

What I chose
Build Claude skills for the repeatable work
I built a suite of Claude skills covering microcopy review, design review, documentation and MD generation, plugin writing, and MR creation for code fixes. On the planning side: skills that auto-generate design tasks, epics, and front-end tickets at sprint and quarter planning. And a Claude Design flow that creates raise-the-bar backlog tickets for tech debt — with screenshots, descriptions and links generated automatically.
What I rejected
Just work harder until it passes
Sustainable for a few weeks, not six months. It trades quality and your own capacity for the appearance of coping, and leaves nothing behind when the crunch ends.
What it cost
Building the skills is real up-front time you don't have when you're already underwater — you have to spend hours you're short on to get hours back. And automated output needs a human check, or you're just generating plausible-looking work faster.
Why it worked
Because it was grounded in the design system, wired into Claude from code. The automation references the real source of truth, not a guess — so its output is trustworthy enough to build on.
Decision 02
A personal tool — or a team capability?

The easy version is a private workflow that makes me faster. But the bottleneck was never just my hours — it was the whole team's throughput, and a lot of design-adjacent work sitting with people who aren't designers.

What I chose
Make it usable by the whole team
The skills are used across the team — designers, front-end, and product managers. Because the design system is integrated into Claude directly from code, PMs can produce rough-but-real designs themselves within the limits of Claude Design. Design capability stopped being a single-person bottleneck and became something the team could reach for.
What I rejected
Keep it as my private speed-up
Would have made me faster and changed nothing structurally. The team's throughput ceiling would stay exactly where it was.
What it cost
A team-facing tool is a higher bar than a personal one — it needs to be reliable, documented and bounded, or non-designers produce off-system work. The Claude Design output for PMs is deliberately framed as rough, because the tool's current limits mean it's a starting point, not a finished design.
Honest limit
Claude Design can't yet produce production-final UI — so PM-generated work is approximate by design. I'd rather state that plainly than oversell what the automation does.
03

What I built

The skills

A working set of Claude skills, in real use by the team:

Microcopy review
Checks interface copy for clarity and consistency against our conventions.
Design review
Audits work against UI patterns, the design system and Confluence docs — the skill that cut the review loop from five days to three.
Docs & MD generation
Produces documentation and the MD files that make the design system legible to AI.
Plugin & MR creation
Writes plugins and creates merge requests for code-level fixes.
Planning automation
Auto-generates design tasks, epics, and front-end tickets at sprint and quarter planning — the lead-level planning workload, systematised.
Raise-the-bar backlog
A Claude Design flow that files tech-debt tickets with screenshots, descriptions and links generated automatically.

Design system, in Claude — from code

The key enabler: the design system is integrated into Claude directly from code, not from Figma. That means everything the skills produce is grounded in the real source of truth. It also means product managers can generate rough designs themselves — approximate, within Claude Design's current limits, but real enough to move a conversation forward without waiting on a designer.

Claude Design + design system integration

Covering the lead role, in practice

To be precise about the title: I was never formally made deputy lead. But for six months I did the work — distributing tasks, overseeing a designer, planning the quarter alongside the front-end lead, and handling questions from the team and product managers. The automation is what made that possible on top of my own design work: the planning skills turned quarter planning from a time sink into a generated first draft I refined, rather than built from scratch.

04

Impact

The automation didn't just save my time — it raised the team's ceiling. Same people, more delivered.

Design epics delivered
Same team, quarter over quarter
Q1
Before
+4
After automation
Four more epics than Q1
Quarterly throughput
Work taken on and successfully closed
Base
Before
+15%
After
More capacity, same headcount
5→3d
design review cycle via the review skill
Whole team
designers, front-end and PMs use the skills
6 months
of lead-level workload covered, automation-assisted
What's solid and what's approximate

The +15% throughput and +4 epics are real quarter-over-quarter figures, and the 5→3 day review cycle is measured. What I'm careful about: the PM-facing Claude Design output is genuinely useful but approximate — Claude Design can't yet produce final UI, so it's a starting point, not a shippable screen. And "covering the Head of Design role" means doing the work in practice, not holding the title. I'd rather be exact about both than let them sound bigger than they were.

05

Reflection

Leverage beats hours
Under real pressure, the instinct is to absorb more and work later. The better move was to spend scarce time building tools that gave time back — to the whole team, not just me. Six months of covering a leadership gap would have been survival mode without it; instead the team delivered more than before.
Automation is only as good as its source of truth
None of this works if the AI is guessing. The reason the skills produce trustworthy output is that they're grounded in a governed design system, integrated from code. The AI work and the design-system work are the same story from two ends: build the source of truth, then automate against it.
Knowing the limits is part of the tool
Giving PMs the ability to generate designs is powerful and easy to oversell. Being explicit that Claude Design output is approximate — a first draft, not a final screen — is what keeps the tool trusted. A tool people over-rely on becomes a liability; one whose limits are clear becomes a genuine capability.