I spent two months building an AI workflow for my design team. Here’s what I actually learned.

It was messier, slower, and more human than I expected.

When my manager asked me to look into how our design team could better use AI in our day-to-day work, I said yes with the confidence of someone who had absolutely no idea what they were getting into.

I’m part of the B2C product design team at Tripadvisor. My job is to make the design team work better with smoother processes, better tooling and less friction between idea and execution. AI felt like an obvious place to invest. Every conference talk, every LinkedIn post, every article said the same thing: adopt AI or get left behind.

What nobody told me was how to actually do it: not the theory, but the weeks of writing documentation nobody reads, the engineering meetings where nobody agrees on what “done” means, and the Slack message you send about a new workflow, then wait, hoping someone will try it.

This is that story.

Figure 1 — Output of the initial workshop on design pain points on tooling.

The honest beginning was a workshop I ran with the design team. I wanted to understand what they actually found painful in the design process we were currently following. The results were predictable in some ways (too much time on repetitive tasks, too much back-and-forth with engineering) and surprising in others (people were already using AI tools individually, in completely different ways, with no shared knowledge).

That last bit was the real insight. We had a fragmentation problem, not an AI problem. Everyone was reinventing the wheel, quietly, alone, and not telling anyone.

Figure 2 — Ask 5 designers what do they use to prototype. You’ll get 5 different answers.

So instead of buying a tool or mandating a workflow, I decided to build shared infrastructure:

• A set of reusable Claude skills: structured prompts that encode team knowledge and give Claude the context it needs to be genuinely useful, not just generically helpful.
• A shared documentation space anyone could follow.
• A shared repository where skills would live under version control, so they could be improved, forked, and maintained properly.
• And a prototyping pipeline that didn’t exist before: designers going from a rough idea in Claude Design, through a working build in Claude Code, to a live URL they could share with a product manager or put in front of a real user the same day. No engineering ticket. No waiting.

Simple enough in theory. Considerably less simple in practice.

What went well: the things that actually landed

The first skill that clicked was the Project Bio Writer. It takes a rough project idea and turns it into a structured brief, hypothesis, description, raw metrics, and at the end, optionally creates a tracking ticket. I shared it with the team and people actually used it. Not everyone, not right away, but enough that it stuck.

Figure 3 — From PRD to tracking ticket in one click. The Project Bio skill creates a brief, hypothesis, description and raw metrics, and syncs automatically with your tracking tickets system.

What made it work, I think, was that it solved a specific, recognisable pain point. Everyone hates writing project briefs. Everyone knows they should do it. A skill that makes it fast and good enough is an easy sell.

The illustration generators were another genuine win. I built one for Tripadvisor’s 3D clay-style assets and eventually one for Viator too. I stress-tested it properly before releasing it to the team, generating around 100 illustrations for a real project. That felt important. Not just “here’s a skill I made, good luck,” but “here’s a skill I’ve put through its paces on actual work and it holds up.”

Figure 4 — Some of the illustrations generated using the skill.

The prototyping infrastructure took longer than anything else, and it had more moving parts than I expected going in:

• The first was hooking Claude Design into the Tripadvisor and Viator design systems, so a prototype comes out already on-brand, right components, right styles, without whoever’s building it needing to know where any of that lives. Getting there meant stress-testing the design system itself against AI prompting, checking that component names, structure, and documentation were clear enough for Claude to actually pick the right ones, not just technically available.
• The second was teaching designers git, which sounds small until you’ve watched someone who has never touched a terminal try to clone a repository for the first time. For some people, that was the steepest part of the entire programme.
• The third was building out Claude Code best practices and a set of deployment skills, so getting from a working build to something live didn’t depend on remembering the right sequence of commands each time.
• The fourth solved the most immediate problem: prototypes built internally were sitting behind our VPN, which meant a designer could build something brilliant and still have no way to put it in front of a real user outside the building. We built the framework that got prototypes hosted externally, and that’s what turned “this works on my machine” into “here’s a link, go try it.” Working, interactive prototypes that you can test with real users, not Figma mockups with invisible hotspots.

Figure 5 — The infrastructure behind faster prototyping: : design system integration, git for designers, deployment skills, and external hosting.

What didn’t go well: the parts I’m still working on

Adoption is harder than building. I knew this intellectually. I did not feel it until I sent a Slack message about a new skill to the full team and received, in return, complete silence.

The problem wasn’t that people didn’t care. Using a new tool, even a genuinely useful one, requires activation energy. You have to remember it exists. You have to have a task where it’s relevant. You have to trust it enough to try it on something real. And if the documentation is even slightly too technical, you’re already asking too much.

I learned this the hard way when I shared the prototyping setup guide and got feedback that it was too engineering-heavy for designers to follow. I had written it for myself, someone who had just spent two months figuring it out, rather than for someone encountering it fresh. I rewrote it. It’s better now. But I should have written it that way the first time.

Get Tripadvisor’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The gap between “I built a thing” and “the team uses the thing” turned out to be almost entirely a documentation and communication problem, not a technology problem. The skills that landed were the ones with clear documentation, honest descriptions of what they do and don’t do, and a personal nudge from me in Slack. The ones I just dropped into the repo and moved on from landed with a quiet thud.

Writing the documentation wasn’t the same as people internalising it. Someone could read a skill’s instructions on how to structure a prompt or manage token usage and still not really get it until they’d used it wrong once and seen why it mattered. Telling people the best practice rarely worked. Showing them, sitting next to someone while they ran a skill for the first time, or sharing a before-and-after of a prompt that wasted half its context window on preamble, did.

The engineering dependency was another thing I underestimated. Some of the most valuable parts of this programme needed real engineering time, and engineering time was always competing with other priorities. Without a firm slot on the roadmap, this kind of work is structurally the first thing that gets pushed to next quarter because nothing is forcing the decision otherwise.

I built a roadmap that assumed things would move in parallel. They didn’t, because nothing was actually reserved. If this work matters enough to plan around, it needs a committed slot, not a good-faith agreement to get to it eventually.

The thing that surprised me most

I expected the technology to be the hard part. It wasn’t.

Claude, once you give it the right context, is remarkably capable. Building a skill that works well is more about understanding the problem deeply than any particular prompting technique. The illustration generators took iteration. The critique and ideation skills took a few rounds of refinement. But broadly, the technology did what it said it would do.

The hard part was everything around it:

• The documentation.
• The version control.
• The shared repo and the conversations with Operations about where skills should live and what the right governance structure looks like.
• The Slack message timing and the way you frame a new tool to people who are already busy.
• The decision about when a process is good enough to share versus when you’re just procrastinating by refining it further.

That’s design operations. Which, when I think about it, shouldn’t have surprised me at all.

There was another assumption underneath this that took longer to surface: that once we had a way of working, it would apply to everything. It doesn’t. Some projects still call for Figma, full stop. Some don’t need AI touched at all. Sometimes Figma Make gets you to a testable prototype faster than Claude Code does. The trial wasn’t about replacing judgment on which tool fits the job. It was about making sure people had more tools to choose from when they made that call.

Where we are now

I gave myself two months as a trial to see how far we could get. We have a shared skills library with skills across both Tripadvisor and Viator brands, each with documentation and version control. We have a prototyping infrastructure that half of the design team is actively using. We have a shared documentation space that people actually navigate rather than avoid. We have a team that has been asked to adopt this as a way of working and is beginning to.

None of this is finished. What we’ve built so far is the proof of concept: it works, and enough people are using it that the case is made. Turning it into how the whole team works needs a real commitment of engineering time, not just goodwill from people already stretched thin. That’s the next ask, and it’s a bigger one than the last two months.

What I know is that the design team is working differently than it was two months ago. Habits are stubborn, and AI doesn’t replace judgment. But differently enough that when someone needs to write a project brief, they reach for the skill. When someone needs 3D illustrations, they know there’s a prompt for that. When someone wants to prototype something for testing, there’s a path to a live URL that didn’t exist before.

That feels like good enough. For now. The tools will change, probably faster than we can plan for. What matters is that the workflow doesn’t depend on any one of them, so whatever replaces Claude Code plugs into what we’ve already built instead of needing it rebuilt.

If you’re thinking about doing something similar

A few things I’d tell myself at the beginning:

• Start with the pain, not the tool. The skills that got used solved problems people actually had. The ones that didn’t were solutions looking for problems.
• Document for the person who knows the least, not the most. Your documentation will be read by someone encountering this fresh. Write for them.
• The shared repo matters more than you think. Skills sitting in a personal folder don’t compound. The ones under version control, documented, and easy for the rest of the org to find, do.
• Adoption is a communication problem. An amazing skill or workflow nobody knows about helps nobody. Announce it, explain it, follow up, ask for feedback. Then do it again.
• Plan for engineering dependencies to take longer than agreed. Not because anyone is failing, but because sequencing is hard and priorities shift. Build that assumption into your timeline.
• And finally: it’s messier than everyone on LinkedIn makes it sound. There’s no clean arc from workshop to rollout, and there’s no playbook you can lift wholesale from another company either. Your tools, your team’s habits, your engineering capacity are all different, so what worked for someone else’s design org might just be extra overhead for yours. The job is figuring out what actually makes your team’s life easier, not adding a new thing they now have to manage on top of the old ones.

There are Slack messages with no replies, documentation rewrites, engineering meetings that get rescheduled, and skills that almost nobody uses. There are also moments, a user testing session on a live prototype or a designer reaching for a skill you built instead of starting from scratch, that make all of it feel completely worth it.

A quick thank you to Emiliano Esposito, who built the engineering framework that made all of this actually work, while juggling everything else on his plate. And to Kuldeep Salhan, who read the first version of this and sharpened it with his feedback.

If you’re navigating this on your design team too, I’d like to know what you’re learning! What’s working, what isn’t, and what would you do differently?

Lara Sanchez is a Principal Product Designer at Tripadvisor, where she leads growth design for Tripadvisor Experiences and moonlights as the person trying to convince designers that Git is not that scary.