This is a case study from 10/2025, rewritten as a blog post. It felt appropriate given all the kerfuffle about the death of Figma and tools like it.
A few months ago, a Customer Operations lead pinged me on Slack. Was a personalized messaging distribution, the AI-generated and behaviorally-tuned outreach we send to patients, ready to launch? He wasn't sure. He'd cross-referenced three APIs, run a SQL query, asked an engineer, and still couldn't tell.
This was the kind of question our Ops team had to answer before every send. The signals lived across a handful of tools that weren't built to be read together, so confirming readiness took longer than it should. An internal tool could change that.
What I didn't do
My instinct was the usual path: a few days of informal research with the people who'd use the thing, then wireframes, then a clickable Figma prototype to validate against them, then hi-fi mocks, then hand off to engineering. I'd loop engineering in early — walk through the flows, flag anything that looked expensive, get a read on feasibility before I got too attached. It's the traditional loop, and for good reason.
The intermediate design artifacts existed because standing up a working front end against real data was expensive. It isn't anymore. But even with engineering in the loop, the traditional approach breaks. A static file or a Figma prototype is a picture of an interaction, and pictures get interpreted. I'd see one thing, engineering would see another, and neither of us would know until the field I designed around turned out to require a new API endpoint, or the state I assumed existed didn't. The validation was real, but it was validating the wrong thing: the interaction, not the system underneath it.
So I inverted it. Keep the research. Skip the intermediate artifact. Let the prototype itself, running against real data in the real stack, be the thing users validate against.
Watching the work
I spent a couple of days with the Ops team. Not in a kickoff meeting. Sitting next to them while they prepped real sends. I watched which tabs they opened, in what order. I watched where they paused. I asked what they were looking for at each step, and what would make them stop a launch versus let it through.
A few things surfaced that I wouldn't have gotten from a requirements doc. The question they were really answering wasn't "is this message ready?" It was "if this goes wrong, will I be able to tell it was my fault?" That reframed the whole thing. They didn't need a green-light button. They needed evidence they could point at.
I also learned which signals they trusted and which they double-checked anyway (some because the data was stale, some because they'd been burned before). The tool would need to show not just the answer, but why the answer was what it was.
Designing by writing
I pasted the transcripts of those sessions into an LLM and had it generate a first-pass set of requirements. Not as a finished artifact, but as an argument to push against. I rewrote most of it. But starting from a structured draft instead of a blank doc shaved days off the requirements phase.
From there I wrote acceptance criteria, enumerated edge cases, and started describing the UI in prose. Not wireframes. Prose.
Then I had Cursor scaffold Angular components, part of our production stack, using that prose as the brief. Within a day I had a functional-ish prototype pulling realistic sample data, in the actual layout the team would eventually see.
What the prototype taught me
Two things the inverted loop gave me that the old one wouldn't have.
First: I learn more from a functional prototype than from a finished mock. Ops leads clicked around, found the states I hadn't considered, and told me which data points they'd actually use versus which ones I'd assumed they'd want. One validation screen I was proud of got cut. Two I thought were secondary became primary. None of that would have come out of a Figma walkthrough, because the Figma walkthrough would have been validating my assumptions about the data, not the data itself.
Second: engineering could engage with real code instead of a picture of code. The usual "yeah but" conversation (yeah but how do we get this field, yeah but that query is expensive, yeah but this state doesn't exist) happened on day two instead of week three. By the time I did open Figma, the hard decisions were already made. The visual work was just that: visual.
What shipped
A web dashboard that lets non-technical Ops staff validate AI-generated message distributions on their own. Eligibility, targeting, timing, and content readiness, all in one view.
Engineering support requests for validation dropped by about half. Launches moved faster. The team doing the last-mile quality check on our AI output had the visibility to do it with confidence.
The part I keep thinking about
The interesting thing wasn't the tool. It was the process.
Due to specialization in tech, the term "designer" has come to mean producing artifacts that other people turn into products. Figma files. Specs. Red lines. The artifact is the work. In a world where an AI-native coding tool can stand up a believable front end in an afternoon, the artifact is cheap. What's not cheap is the judgment behind it: which problems to solve, which data points matter, which trade-offs are acceptable, which states to design for.
The role of tools like Figma doesn't disappear, it just gets narrower and more honest. Figma is where I still do my best early thinking: flows, IA, the shape of a product before it has edges. A freeform canvas is better for that than a code editor, and I don't think that changes anytime soon. What changed is the middle of the process. Figma used to be where I validated interactions too, because code was too expensive to stand up as a draft. It isn't anymore. So Figma goes back to being what it was always best at, a place to think, and the prototype takes over the job of telling me whether the thinking was right.
The gap between idea and implementation keeps getting shorter. That's not a threat to designers. It's an invitation to get closer to the thing we're making.
I still use Figma. I'm just not precious about when.