Senior product designer with a background in psychology.

I'm part of Apryse's internal AI team, and I use these tools as a partner on specific parts of my process, not a replacement for the process itself. What that looks like changes depending on what I'm working on, but the judgement always stays mine. When I say something is AI-assisted, it means the AI worked on something I'd already designed myself: a prototype built from my own high-fidelity screens, or copy tightened against a draft I wrote. It's not a shortcut past talking to users. If anything, it just means I get to more of them, sooner.

Sharing what works

I used the Figma MCP to recolour a set of legacy icons into our new brand palette and build a visual out of them, and raised it at a design retro. In the review that followed I showed the whole thing (the chat history, the raw output, and the version I finished by hand) with what I had learned about its limits from testing batch edits myself. Colleagues are using it at handoff now. It is still in beta, so what it can do keeps moving.

Finding where it would help a team

I would not start with tools. I would start with whichever part of the process takes longest to get through (usually wherever one person is trying to align a team on scope, goals and feedback) and time it from first information to handoff. Then the designers: what each is strong at and what each finds slow, because the useful AI is the one that closes a specific gap for a specific person. One gap at a time, not a rollout.

Making a system a model can use

If I were building a design system to be read by AI as well as by people, I would audit the built app against the existing system first, with AI, to find where the interface has drifted from what it is meant to be. Then rename components and tokens so the convention reads the same way to a designer, a developer and a model. Naming is what makes a system usable by something that cannot see the screen.