This is a summary of my Medium article, I spent two months building an AI workflow for my design team. Here's what I actually learned. — read the full story there.
Executive summary
I was asked to explore how the B2C product design team at Tripadvisor could make better use of AI in its day-to-day work. Over a two-month trial, I turned scattered, individual experiments into shared infrastructure: a library of reusable Claude skills, shared documentation, version-controlled repositories, and a prototyping pipeline that takes designers from a rough idea to a live, testable URL the same day.
The real problem: fragmentation, not AI
I started with a workshop on the team's pain points with tooling. Some findings were expected — repetitive tasks, back-and-forth with engineering. The surprising one: people were already using AI tools individually, in completely different ways, with no shared knowledge. Everyone was reinventing the wheel, quietly and alone.
So instead of buying a tool or mandating a workflow, I decided to build shared infrastructure:
- Reusable Claude skills — structured prompts that encode team knowledge.
- A shared documentation space anyone could follow.
- A shared repository so skills could be improved, forked and maintained under version control.
- A prototyping pipeline — from Claude Design to a working build in Claude Code to a live URL. No engineering ticket. No waiting.
What landed
- Project Bio Writer — turns a rough idea into a structured brief, hypothesis, description and raw metrics, and can create the tracking ticket. It solved a specific, recognisable pain, so it stuck.
- Illustration generators for Tripadvisor's 3D clay-style assets and for Viator, stress-tested on around 100 illustrations for a real project before release.
- Prototyping infrastructure — Claude Design hooked into the Tripadvisor and Viator design systems so prototypes come out on-brand; teaching designers git; Claude Code best practices and deployment skills; and external hosting so prototypes behind the VPN could finally be put in front of real users.
What was hard
- Adoption is harder than building. A new tool needs activation energy, and a Slack announcement alone was often met with silence.
- Documentation for the reader, not the author. My first setup guide was too engineering-heavy; I rewrote it. Showing people — sitting next to them, sharing before-and-afters — worked far better than telling them.
- Engineering dependency. Without a committed roadmap slot, this kind of work is always the first to slip.
The biggest surprise
The technology wasn't the hard part. Everything around it was: documentation, version control, governance, timing and framing. That's design operations. And no single way of working fits every project — sometimes Figma, or Figma Make, is still the right call. The goal was more tools to choose from, not replacing judgment.
Where we are now
- A shared skills library across Tripadvisor and Viator, documented and version-controlled.
- A prototyping infrastructure that half of the design team actively uses.
- A documentation space people actually navigate.
It's a proof of concept that makes the case. The next step is a real commitment of engineering time to make it how the whole team works — built so the workflow doesn't depend on any single tool.
Want the full story? Read the article on Medium →