Case Study

Built an AI-assisted design practice the whole product group actually adopted

Alma · 2024–present · A designer's week of work now takes one or two days

Problem

AI design tooling is everywhere and mostly unused. Pilots stall, adoption stays with the enthusiast, teams drift back to old habits.

My contribution

Built the tooling across four architectural generations, led its adoption, and now mentor other teams building their own.

What changed

A whole design and product group changed how they produce features — by choice. QA changed how they build tests. Other teams asked to build their own.

Role: Built the tooling and the practice around it; led adoption. Member of Alma's Core AI team, representing UX and product design alongside one other design lead — two people covering design across a conglomerate.

Scope: Daily use by design and product staff across two enterprise SaaS products. My materials serve as the worked examples other teams across the group build from.

Timeline: Mid/late 2024 → present. Four architectural generations; agentic workflow at v2.0.

Origin: Started as a sub-project of my own inside the DMS work, then outgrew it.

Diagram — "Skill architecture and evolution", 16:9

Four generations, and where each one hit its ceiling.

The bet

Useful AI-assisted design has to be built around a specific team's real workflow, and adoption is a change-management problem, not a tooling problem. Neither half works alone — tooling nobody trusts goes unused; enthusiasm without fitting tooling goes nowhere.

The technology was never the hard part. Three separate groups each had a good reason to resist it.

Success, defined up front: other people using it by choice, on production work, as a normal part of how features get made.

Four Generations and Three Kinds of Resistance

1 · Rebuilt at every ceiling

Python scripts against Azure AI APIs (mid/late 2024) — converted outdated specs and structured meeting notes into PRD candidates. Failed on: fire-and-forget black boxes, fixed steps in fixed order, slow, opaque when wrong.

Custom roles — a genuine dead end. A role gives a persona, not a process. The AI kept forgetting where it was. Abandoned quickly.

Claude Projects, template-driven — the first real leap; templates kept the AI on track without pre-determining every step. Failed on: the full PRD process was too much for one context. Projects were hard to share without collisions. Run several features through it and drafts pile up until both AI and user lose the thread.

Skills — the project framework decomposed into small, single-purpose, shareable skills: Confluence search, uploads and updates, impact analysis, PRD creation. First version failed on skills too large, workflows too long. Fixed by decomposition. This is when it became flexible: start from any angle — new PRD, update an old one, view specs from PRD and flow, or flow from views and PRD.

Agentic workflow (current, v2.0) — composes those skills into five roles: design manager, product designer, UX designer, prototype designer, design auditor. Takes a PRD draft to a working interactive prototype.

Every generation failed for a structural reason — rigidity, statelessness, content bloat, over-long workflows. Every fix was architectural, not prompt-tuning.

2 · Designers and product owners — fear of replacement

Constraint: Product owners and designers worried AI would take too much of their work. Quieter but just as real: fear they wouldn't know how to use it.
Decision: No argument, no mandate. Co-working sessions using the skills together, in the open, on real work.
Reasoning: They needed to see that decision-making and creative judgment stayed with them.
Trade-off accepted: Let each person adjust on their own schedule. Much slower than a rollout.

People adopt tools they've watched themselves stay in control of.

3 · QA — a legitimate technical objection

Constraint: Moving from static layouts to interactive prototypes broke QA's AI-driven test creation. If a definitive view state isn't a discrete static view, how do you point a test-generating AI at it?
Decision: Two fixes. Strengthen view definition and flow documents so the QA AI can source state information from them. Build parameter-driven view substates into the prototypes, directly linkable and documented in both prototypes and definition docs.
Still open: The most remote corner cases. Where preconditions are too complex to model in prototype flows, those states exist as standalone invocable views. Workable, not yet elegant.

4 · Development — my own misstep

What I got wrong: The initial plan assumed dev-side AI flows would be in full use, so the first design skills produced documents aimed at other AIs: wordy, over-detailed, structured for machine parsing.
The result: Developers got specs they couldn't scan. The worst resistance in the project, and I caused it.
The fix: Several iterations of the PRD, view, and flow documents to reach a state where they work for humans and the AI tools consuming them.

Optimising for the machine reader broke the human one — and the humans were the ones who had to trust the output.

What changed

Speed — work that took one designer a week now takes one to two days. Faster through the full agentic route.

How the group produces features — daily use by design and product staff across two enterprise SaaS products. Not a pilot, not a personal workflow.

How QA builds tests — restructured around linkable prototype substates and strengthened definition docs.

Beyond my own work — what began as a sub-project is now used across several projects. I sit on Alma's Core AI team as one of two representing product design across the group's companies, and other teams build their own workflows from my materials.

The proof isn't the architecture. It's that other people chose to keep using it — and then asked to build their own.

What I'd do differently

I optimised for the wrong reader. Building documentation for AI consumption before the humans were on board created exactly the resistance I could least afford, from the group whose trust mattered most.

And every generation failed for a reason I could have anticipated by asking: what happens when ten people use this on twenty features? Scripts, roles, and projects each worked fine for one person on one problem. What made the skills generation stick was designing for sharing from the outset — the same lesson I learned scaling the enterprise design model years earlier, arriving in new clothes.

I'm open to head, lead, and staff product design roles.

pekka.toppi@gmail.com +358 40 577 5547 LinkedIn Download CV (PDF)