From research synthesis to something you can hold

AI before the prototype

The bottleneck isn't Figma, it's building enough context, and trust in the ability of that prototype to make a call you can stand behind, and defend.

I use AI to read across research notes, product threads, competitive patterns, and existing work, then pull the repeated signals into one working picture. I don't treat that synthesis as truth, I use it to find the tensions, questions, and blind spots worth inspecting myself.

Instead of spending days rebuilding context from scattered material, I can get to the real product question faster, and keep that context alive while I prototype.

I'm not trying to dump research into a prototype. I want a collaborator that can hold the context while I make the calls, and discover more and more options, and paths forward.

Prototyping as a way to experience the system

When I prototype in code, I'm not trying to convince anyone that this is the right approach, I'm trying to experience that it will hold up in the scenarios people will encounter.

I want to see how an interaction behaves under load, how it reacts when you get interrupted, and how it feels when you're tired or in a hurry, how dark mode looks in sunlight, and how the app reacts to accessibility settings.

AI earns its place there because it closes the gap between intent and something concrete enough to judge. Figma is still in my daily toolkit, but for different purposes.

From synthesis to prototype

Once the context is in place, AI shifts itsrole. I can challenge a structure with it, ask where a proposed flow contradicts the source material, or ask it to translate a direction into a working SwiftUI prototype.

The model doesn't have taste (yet), and hierarchy, pacing, interaction feel, and product calls stay with me. What it can do is hold a lot of context at once, which makes the design conversation sharper.

Instead of stopping at "this seems promising," I can get to "let me show you how this behaves" much faster.

From workflow to organizational leverage

One run of this workflow synthesized 23 signals from 13 internal studies and 10 external sources in about an hour, then turned the resulting direction into a four-tab SwiftUI prototype on TestFlight in four days. That compressed weeks of work into days, which is useful, but the part I cared about more was that the workflow could be picked up by other people without me sitting next to them.

I wrote it up twice, once for the mobile team and once as an org-wide proposal with templates, standard source repos, and persona-based reasoning prompts. Both write-ups were folded into a director-sponsored research program as official resources, alongside the research team's own tools. I presented the work at a design-org town hall as the only non-research speaker, and again at two design leadership quality workshops.

The clearest signal that it landed was a designer on a different team telling me, in structured peer feedback, that the way they approach research now came directly out of watching this work. That's the level of impact I aim for, because a workflow that other designers can carry forward is more useful than another well-run project.

Micro-interactions still shape the feel

I'm currently working on a larger project at GitHub that I can't write about in detail. A small part of it led to another prototype.

Copilot made its way to GitHub Mobile almost 2 years ago, and a lot of focus naturally went into improving capability and usefulness. What often gets lost in that process are the small moments that make a product feel present and considered.

I wanted to see what would happen if we brought some of the Copilot character animations from github.com/copilot into the GitHub Mobile chat experience.

When the chat view appears, Copilot jumps in with it, and when you stop typing, it observes the input field.

It stays quiet, and a little playful.

When I shared this internally, people immediately understood what it added. They didn't need a walkthrough or a pitch.

These moments aren't vanity, because they shape how products are remembered. People forget the pull request they merged a few days ago, but they remember how a tool made them feel the first time they used it.

I also built that prototype largely with an LLM, which let me stay on intent while the tool handled most of the mechanics.

The focused inbox

The focused inbox came out of that workflow. I wanted to test what it would feel like to process one email at a time inside an inbox full of noise.

The prototype used a deliberate review mode where the first email takes over the screen and gives you enough context to make a decision.

You see a short summary of the message, with previews for image attachments and short summaries for PDFs or text files.

If the sender has never emailed you before, the app tells you immediately and lets you decide whether to block them or keep receiving messages from that person.

The interaction pattern is intentionally simple. Swipe left to archive, or swipe right to pin the email back to the inbox.

I wanted inbox zero, but in a way that feels calm and easy to consume.

Most email clients already support swipe actions like archive, pin, mark as read, or reply. What they don't offer, at least to my knowledge, is enough context to make that decision quickly. You always decide without really knowing what you're archiving.

I wanted to see what happened once that blind spot went away.

Why this had to run on device

It wouldn't work in Figma.

Its value lives in pacing, resistance, and timing. How long the summary takes to appear, how the swipe settles, and how quickly you feel confident enough to move on.

These aren't visual problems, they're behavioral ones.

So I built a functional SwiftUI prototype with mocked data that runs on device and responds to real gestures. It feels real enough to judge.

The unusual part for me was that I didn't write the code myself. I described the idea, the interaction rules, the data I needed, and the edge cases I cared about. An LLM generated the prototype, and I refined it by prompting again.

It moved quickly because the intent was clear. The tool handled the first pass, and I could spend more time judging the feel.

What AI is actually useful for

AI isn't good at judgment or taste, but it's good at holding context and turning clear intent into something you can react to with your hands.

Designers used to hear that some ideas were too complex to explore without a real project attached. That's changed. I can say "let me show you how this feels" without turning the demo into a delivery commitment.

The idea stops being a pitch and starts being something people can use, even for a minute.

From prototype to craft

The same workflow has shaped my side projects too. Tempra Ora's Clap Control and Twilight Swirl theme came out of the same pattern: describe intent, let the model do the first pass, then spend the time judging the feel on device. The full case is at tempraora.html.