How I Redesigned
My Design Process with AI

As a Senior Product Designer, my job is to remove friction from complex systems. In 2026, I turned that discipline on my own process: I rebuilt how I design and ship — with AI as a collaborator that I direct, verify, and review like a team member. The proof is MaiLLY, a Gmail-connected AI mail client I designed, built, and deployed alone.

AI agents like Claude Code act directly on your codebase. That power cuts both ways: vague prompts produce changes that contradict your architecture, and "done" reports aren't always true. Most designers either avoid agents entirely or accept the chaos. I wanted a third option — a process where AI moves fast and I stay accountable for quality.

MaiLLY didn't start as a one-day build — the AI-collaboration system behind it was forged over three months of shipping v1, and v2's single-day sprint was possible because that system was already mature.

Establishing the discipline (v1, Feb–May 2026). Early prompts were single fixed instructions; by mid-April, after an underspecified prompt caused a regression, I standardized every prompt around explicit scope boundaries. By May, lib/tokens.ts had become the single source of design truth — replacing what would traditionally be a Figma file — with a standing rule I later put in writing: read tokens.ts before touching any visual, no exceptions.

Verification became non-negotiable. I didn't accept a single AI security audit as sufficient — I re-ran the same audit prompt four times until it returned a clean pass, catching a legacy endpoint and an exposed error detail that earlier rounds missed. When a hardening change broke the app in production, I reverted immediately on confirmed regression rather than defending an untested assumption. And the most consequential bug I caught wasn't found in code review at all — it surfaced only when a friend used the product live, next to me, and a multi-turn conversational flaw appeared that no unit test would have caught.

Product judgment stayed mine. I scoped MaiLLY by what I explicitly excluded — no reimplementing Gmail's search, folders, or filters — reasoning later distilled to: the moment you add a fourth verb, the product stops being about one thing. I chose privacy-by-default (AI drafts only on explicit click, not automatically) over a lower-friction default, then deliberately deferred re-litigating that tradeoff until enough user signal existed to justify revisiting it.

When the plan didn't work, I changed the method — not the standard. My research plan depended on user interviews; when the pipeline stalled post-launch, I didn't wait. I pivoted to hypothesis-driven personas built from competitive analysis and the sparse signal I had, and logged the pivot as a constraint-driven design decision — not a failed process. A competitive audit against Gmail Gemini and Superhuman later forced a harder conclusion: MaiLLY was undifferentiated. I didn't rationalize the gap; I used it as the trigger for the UX redefinition that became v2.

The one-day sprint. All of that discipline — scoped prompts, a token-based design system, an evidence-based verification habit, hard-won product judgment — is what let the v2 build (briefing AI, edit modes, reply types) go from design tokens to a deployed, working feature set in a single focused day. The speed was a result of the system, not a substitute for it.

When I identified a workflow gap worth productizing, I didn't start building. I ran a structured market study first: 12+ competitors analyzed, target segments sized, pricing benchmarked. Designer instinct, PM discipline.

The same system runs my client work. For a B2B client, I used AI-driven analytics and heatmap analysis to ground a web redesign in behavioral data rather than opinion. Same gates, same verification discipline, different context — personal product, client work, and (previously, at Rakuten) platform-scale product all run on one process.

The lesson isn't "AI makes you faster." It's that AI amplifies whatever process you bring to it. Bring vagueness, and it ships vagueness at speed. Bring clear intent, enforced constraints, and evidence-based review, and it ships your standards at speed. The skills that made this work are the ones design always demanded: knowing what you want, knowing how to verify it, and knowing what not to automate.