How I transformed our content design team to become AI-led

"I've got a quick thing for you." That's how a lot of requests used to land on my team, and the quick thing was almost never quick.

I joined Miro 18 months ago to lead content design. At the time, we had two content designers. We now have three, plus me. Four people, in total, doing work that used to feel a lot bigger than we were. We were still finding our rhythm as a team, often reactive and stretched thin enough that we could only make surface-level changes, which meant we weren't operating at the level we should have been.

AI arrived around the same time I did, and it handed us two jobs at once: figure out how to design AI experiences for our users, and figure out how to use AI to run our own team better. We couldn't tackle everything ourselves as a team of four, so building an AI-led practice felt like the only way to scale our impact faster than we could individually.

I'm writing this because other content design teams are probably hitting the same walls we did, and it seems more useful to share what worked, and what didn't, than to let each team figure it out the hard way on their own.

The problems AI put in front of us

Before vibe-coding, our workflow looked like this: designers and content designers collaborated in Figma or Miro, mapped out a journey together, and iterated before anything went into build.

Then tools like Claude Code, Cursor, and Lovable arrived, and designers started experimenting on their own. They could build a clickable, working prototype by themselves and only bring content design in at the end, saying, essentially, "Here it is, now help me with the content." It sounds efficient, but it actually took us a step backwards – we'd lost the collaboration that used to happen earlier in the process.

The second problem was harder to solve. AI is good at binary decisions and applies a clear yes-or-no rule well. Nuance and context are a different story, and Miro's product has a lot of both. We often need to explain complex concepts in just a few words, and AI doesn't have the broader context to do that on its own. That same gap showed up again when we started writing prompts for our own AI chat-led experience: we had to learn what needed an explicit instruction (you must do this, you must not do that) versus what needed examples to handle the nuance.

What we built

If designers were going to use AI tools independently, we figured we could put our content design best practices directly inside them. That way, designers would apply good practice automatically while they built, and we wouldn't need to catch every surface-level issue after the fact. That single shift got us about 70% of the way there, and it freed up content design to focus on the foundational work: structure, logic, and flow, rather than re-litigating word choice on every screen.

In practice, that meant building three self-serve AI tools for designers to use before they ever come to us:

• Content design guidelines built directly into our MCP setup
• A skill they can point Claude to for feedback on what they've created
• A Miro Sidekick and a matching Figma plugin that do the same basic content sweep

The feedback on these has been genuinely good, but the bigger win has been time. When I joined, my team spent about four hours a week running office hours, sitting down with people for 30-minute sessions to fix fairly basic copy issues. We've cut that down to 30 minutes a week, which is three and a half hours a week of content designer time back, just from designers catching the basics themselves first.

We did the same thing for content already live in the product. We're too small a team to fix everything manually, so we partnered with our accessibility and localization teams, who already ran their own checks before release, and added a content design layer on top, a final gate checking things like US English and sentence case before anything ships. We built what we call a standard, a machine-readable version of a rule that our automated content check can read and flag against, and used it to run a legacy sweep across more than a thousand live items already in the product. We've also set up bots that act like background agents, and if we spot a typo or small copy issue, the bot creates the pull request and fixes it itself, instead of the fix sitting on a backlog where it would never win priority against a new feature.

Mistakes we made along the way

It's tempting, as a content designer, to put every single rule you have into an agent or a prompt. We did exactly that, first with our prompts for AI experiences, then with our evaluation criteria, where we ended up checking against 110 individual rules. The problem is that AI is already pretty good by default at a lot of basics, like using US English or sentence case instead of title case, so a lot of what we were specifying didn't need to be said at all. Overloading it with every possible rule created unpredictable behavior, where it would either try to apply everything or skip rules altogether, with no reliable way to predict which. What I'd have done differently is to start by figuring out what AI already does by default, and only layer in the Miro-specific rules on top. For us, that could mean paring 110 rules down to the roughly 30 that actually matter – we’re in the process of doing this.

One problem we haven't solved yet: there's no multiplayer prototyping in Claude Code or Cursor right now. If someone's building a prototype, you have to wait for them to finish, then create your own branch, make your changes, and commit them back. It's sequential, not simultaneous. Fine-tuning that part of the process is next on my list, but we’ve built a pretty good relationship with design now, and sometimes content designers might even start the prototype first then pass it to the designer.

Where content design is headed 

People are starting to realize that content designers are genuinely well-suited to prompt design and model training. Our job has always been crystallizing rules, behaviors, and descriptions into language. That's model design, whether we've called it that or not. I expect to see more content designers getting into the details of prompts and evaluations because of it. Honestly, engineers have really loved collaborating with us on things like evals, so it shouldn’t feel intimidating to do this.

At the same time, AI is still binary and still inconsistent, so it isn't a replacement for someone making sure a whole experience hangs together. If one designer builds one part of a product and another designer builds a different part, someone still needs to make sure they feel cohesive rather than like two different products stitched together. It's easy for a designer to skip pointing their vibe-coding tool at a skill and just build first, think about voice later, and AI has a real tendency to make everything sound the same.

That's why I think voice and narrative are going to matter more, not less, as more of this work gets built with AI. Someone still has to be the person saying, "Let's make sure this sounds like Miro all the way through."

If your team is wrestling with the same questions, a lot of what we built started on a Miro board: mapping our workflow, testing where AI helped and where it didn't, and building from there. Try Miro free and see what it surfaces for your own team.