AI Playbook: 3 Experiments Every Design Team Should Run

There’s a version of AI adoption in UX that looks impressive on paper — faster outputs, more iterations, automated summaries — but leaves teams feeling strangely hollow. Like they’re moving quickly without quite knowing where they’re going.

That’s not the version worth chasing.

Over the past months, our team has been running a different kind of experiment. Not “how do we use AI to go faster?” but “how do we use AI to work better, together?” The distinction sounds small. It isn’t. It shifts the conversation from individual productivity to collective intelligence — from tools that help one designer move faster, to systems that make the whole team sharper.

What follows are three experiments: one we’re about to begin, one we’re building right now, and one we’ve already completed — an attempt that fell short, but ended up teaching us more than any success could.

Experiment 1: Turn Research into a Living System (Coming next)

The problem we’re trying to solve Research insight has a short shelf life in most teams — not because the insights expire, but because they get buried. A usability study from eight months ago lives in a Miro or Google slides no one can find. Patterns from five rounds of interviews never made it into a shareable format. New team members start from zero. Even experienced ones repeat work that’s already been done.

The question we’re asking ourselves isn’t “how do we summarize research faster?” It’s: “What if all of our research was actually usable?”

What we’re planning to build A centralized research system — a living database where every study, interview, and insight lives in one place, structured and searchable. The idea is to use AI to do two things within it: first, pull transcripts directly from the platforms we run interviews on and auto-populate analysis templates, so findings go from raw data to structured insight without the manual overhead; second, surface connections across studies, so we can ask things like “what friction points have we seen in onboarding across the last year?” and get a real answer.

Templates are central to this. A shared structure for synthesis means everyone’s analysis looks the same, lives in the same place, and can be handed off or reused without translation — ready to use as-is for the next project that needs it.

Why we think it will matter We expect institutional memory to stop being a metaphor and become something real. New designers will be able to tap into years of research context from day one. Senior designers will stop being the unofficial archive everyone comes to with questions. And we’ll stop re-discovering the same user problems in every new project cycle.

The impact we’re looking for isn’t measured in hours saved — though we expect those too. It’s measured in the quality of decisions we make earlier, because we’re no longer starting from scratch every time.

Experiment 2: Build Your Own Figma Plugins (In progress)

The problem we’re solving Design quality checks happen too late. Accessibility, consistency with the design system, copy tone — these are often reviewed in critique, or worse, after handover to engineering. By then, the cost of fixing them is high, the conversation is defensive, and the feedback loop is broken.

We also noticed something uncomfortable: every designer on the team had slightly different internalized standards. The same component could be reviewed by three people and get three different assessments of whether it was “consistent with what we have in production” or “accessible enough.” That inconsistency wasn’t a people problem. It was a systems problem.

What we’ve built — and where we’re going We started with one plugin: an inline copy assistant embedded directly in Figma — one that knows our glossary, our tone of voice principles, our dos and don’ts, and our best practices. Instead of opening a Jira ticket to the UX writer, designers get contextual support exactly where they’re writing. When one UX writer supports multiple product designers, manual copy review simply can’t keep up with the volume — the plugin helps us move from one-off requests to a scalable content system, so designers can self-serve against shared standards and UX writing effort goes where it has the most impact.

Now we’re scaling it up. The next step is a plugin that checks consistency with our design system — flagging deviations before they reach a review. The thinking is that if designers can run their own structured check before a critique, we remove a layer of noise from those conversations and create the conditions for higher quality feedback. Less time catching the obvious. More time spent on the decisions that actually need a room.

What we’re assuming — and what we want to find out Our hypothesis is that this will shift the nature of critiques and raise the overall quality bar. But we’re honest that it’s still an assumption. We haven’t yet seen whether removing consistency checks from the critique agenda actually frees up the conversation, or whether it just changes what gets flagged.

That’s what we’re watching. Starting with one plugin made this feel achievable — each addition builds on a foundation the team already trusts, and we can evaluate the impact before scaling further.

Experiment 3: The Prompt Library That Taught Us the Wrong Question (Completed — and failed)

What we tried — and what broke A while back, we built a shared prompt library — organized by task type, documented carefully, made available to the whole team. Almost no one used it. Not because the prompts weren’t good, but because most designers had already developed a habit of asking Claude or ChatGPT to write a prompt for them. The library existed. The behavior never followed. And that failure pointed us toward a much more interesting question than the one we started with.

Where it actually led us We stopped asking “how do we prompt better?” and started asking “how do our design methods need to change in an AI world?” Take personas — instead of maintaining a prompt for them, we redesigned the method itself: give AI our existing template plus a set of research summaries, and let it generate a structured first draft that designers then interrogate and refine. The method is still ours. The labor distribution has changed. We’re now working through journey mapping, “How Might We” framing, and affinity clustering the same way — not replacing the craft, but rethinking where AI fits inside it.

The Shift That’s Actually Worth Making

Three experiments. Three different stages. Three different lessons.

What connects them isn’t the technology — it’s the posture. In each case, we weren’t asking “how do we add AI to what we already do?” We were asking “what do we need to change from what we do?” That’s a slower, less comfortable question. It’s also the right one.

The teams that will benefit most from AI aren’t the ones who adopt it fastest. They’re the ones who are most thoughtful about how they adopt it — who treat the integration itself as a design challenge, worthy of the same rigor they bring to the products they build.

We’re still in the middle of this. Some experiments are working. Some are still being planned. One already humbled us. But that, too, is how good design works — you test, you learn, you adjust the question.

Sometimes the most meaningful shifts in a team’s workflow start with small experiments like these.

A special thank you to Ino Ioannidi for leading the copy Figma plugin, to Avra Alevropoulou for leading the exploration of how design methods need to adapt in the AI era, and last but not least Thanos Dimitriou for the support. None of this moves forward without people willing to do the hard work of making new ideas actually work.