For most of my design career, Figma was where the real work happened. I’d design screens, build prototypes, then hand off the designs for someone else to build. If something felt slightly wrong in production, we’d go back and forth trying to articulate what “it should feel like” in words. This process worked well enough, but there was always a gap between what I could show in a static design tool and what someone would actually experience in the product.

That gap started to feel especially wide when I began working on the search functionality in Slack. Using AI tooling has finally helped me start to close it. Not in some dramatic overnight shift, but through a gradual realization that I could work much closer to where the pixels actually live. This is my honest, ground-level account of what adopting AI has looked like in practice so far: the tools, the workflow changes, and the questions I’m still figuring out.

The shift to code

The search experience in Slack is a deeply keyboard-driven feature: typing states, focus management, the way content scrolls and reflows as you interact. These are things you can sketch in Figma and even prototype to a degree, but a Figma prototype can’t tell you whether the focus ring moves correctly between elements when you press tab, or whether a scrolling gradient feels right as content overflows. You need to actually use it. 

For interactions this nuanced, the gap between a static mock and the real thing isn’t just inconvenient — it changes the quality of the conversation you can have about the design. I needed something people could actually type into, tab through, and respond to in real time. That meant moving into code.

More accessible than you’d think

I came into this with basic HTML and CSS — enough to roughly understand what I was looking at, but not enough to write it myself. That turned out to matter less than I expected. The first time I described a focus interaction in plain language and had a prototype working in minutes, I stopped thinking of code as someone else’s territory. Things I wouldn’t have known how to code myself — like keyboard navigation or making sure focus moves the right way when you tab through results — I could just describe and the AI handled the technical side. It’s still designing, just in a different medium. The barrier was genuinely lower than I expected.

My setup is fairly straightforward. Cursor is my main environment. I use Figma’s MCP integration to pull in components I’ve already designed and Slack’s design tokens, so I don’t have to rebuild spacing, color, and type from scratch every time. I tried working directly in Slack’s codebase — years of accumulated complexity that made every small change feel like a bigger undertaking than it needed to be. A lightweight HTML and JS prototype I could host and share turned out to be all I actually needed at the exploration stage.

How my day-to-day has actually changed

Today, I’m mostly working in Cursor rather than Figma. I’ll still use Figma when I need to explore something visually from scratch, but the real iteration happens in code. Cursor’s design mode, combined with inspecting and editing CSS directly, feels a lot like using DevTools, which makes the transition surprisingly natural.

Slackbot has also become a real part of how I design. A lot of decisions, especially around accessibility and keyboard patterns, live in past conversations in Slack. Before I start building something interaction-heavy, I’ll ask Slackbot to surface relevant discussions, then paste what it finds directly into my Cursor prompt as context. That loop of pulling institutional knowledge and applying it directly to code has become one of the most useful parts of my workflow.

Everything I build gets deployed to GitHub Pages, which has become my living design workspace. Engineers and PMs can open a link and try things for themselves — and see not just where I landed but how I got there.

My honest account

As I’ve adopted AI, there have been real wins. A multi-line text interaction came up in a Slack discussion with another designer and a frontend engineer. We landed on three possible directions, and I had all three prototyped by that afternoon. When the group later met, we had a focused real-time conversation instead of another drawn-out, asynchronous discussion. That’s the collaboration pattern now: less back and forth, faster alignment, because the prototype is right there.

The same was true for the quick switcher’s entrance animation. Once we moved it to a centered modal, we needed it to feel snappy but not abrupt — if the animation was too slow, it would feel like the whole thing was lagging. That balance is almost impossible to land in a static tool or nail down in a description. I iterated through a few variations in Cursor until it felt right, brought them to the team to decide together.

But working with AI hasn’t all been smooth. The biggest adjustment has been learning to work in smaller increments than feels natural. Early on, I’d input multiple changes at once — the model would get confused, or produce something technically functional but hard to verify. Breaking work into smaller pieces helped, but created its own overhead: after every change, you have to stop and test everything before moving on. You end up keeping a running list of pending changes and feeding them in one at a time.

AI also doesn’t always preserve what you’ve already built. You prompt it to change one thing, and it quietly breaks something else. If you’re not testing after every turn, you won’t notice until you’re sharing the prototype with someone — or worse, presenting it — and that’s when you realize something’s broken.

There’s also the context-switching. AI runs in the background while I move on to other tasks, which sounds efficient until I come back and need to fully re-orient before I can prompt anything useful. I genuinely don’t always know if I’m saving time or spending more of it. But the comparison isn’t really “AI versus a faster method.” It’s “AI versus a workaround that probably wouldn’t have felt real enough to be useful.”

I’m somewhere between excited and cautious about all of this change. The work feels more fluid and flexible than it ever has. An AI-first mindset, for me, isn’t about mastering a fixed set of tools. It’s about working in a way that’s closer to the real experience, even if it’s messier. I’m not sure where this lands yet, but right now I’m designing things I can actually use, and that already feels like a meaningful shift.