Process
AI-Native Design Process
When building becomes cheap, product and design judgment becomes the strategic advantage. AI can generate a working version of almost anything quickly, which moves the value of design away from producing screens and toward deciding what is worth producing for the business and the user. This page walks through my AI-native process, and the points where design intuition and judgment carry the real weight.
From making to deciding at each stage
A working prototype that once took weeks now takes hours, and when building is no longer the bottleneck, the hardest work shifts to deciding what to build, judging what the tools return, and holding a quality and craft bar as everyone starts from the same vibe-coded first draft.
The sections below follow one project through four stages, from early research to shipping code. Since the product built on this process has not been released, I am keeping the details general and focusing on where my judgment created impact.
01Discovery and prioritization
Discovery is where AI buys back much of the early product development time. It can survey existing patterns, surface what has already been tried, and lay out the tradeoffs in a fraction of the time desk research used to take. The value of that speed is not the speed itself, but the time it creates for the harder work: choosing the right problem to solve.
On my project, that meant using AI to find and prioritize the problems a settings feature should actually solve, before committing the team to a direction. Here is where AI moved the work:
Reviewing past research
The user group I was focused on had several years of research documented by UX research, so I linked all the relevant docs and asked AI to identify trends and the places where users had shared difficulty with settings. That validated where my team's instincts were right, showed how the problems had shifted over the years, and gave me a clear list of what our settings experience could solve.
Prioritizing the problems
With the problem list in hand, I used AI to prioritize it through the lens of team, app, and company strategy, weighing the potential impact on both people and the business. That let us take the problems and proposed solutions to every level of leadership with clear rationale for why we were solving the most important ones.
Outcome
In about two hours of working time, I had a research-backed, prioritized set of problems, which gave us the artifacts to start designing solutions and building the case for leadership.
The judgmentDeciding which problem was worth solving first, weighing impact on people and the business.
With the right problems in hand, the next task was to turn the most important problem into a design direction we could put in front of our users.
02Design and prototyping
Once we knew which problem was most worth solving, I partnered with my PM to brainstorm solution directions, then brought them straight back to AI to begin prototyping in preparation for leadership alignment and UX research. The speed at this stage was remarkable. AI handed me a competent first version of the design deliverables, leaving me the real work of making the experience intentional and right for our users. Here is where AI moved the work:
Reusing a proven pattern
During the brainstorm, our cross-functional team identified a design pattern used elsewhere in the app that fit our problem. Because the product space had robust internal documentation, I used AI to comb through it and research where that pattern had been applied and how it had performed. That gave us precedent, backed by UX research and data, that we could build on where it worked, improve where it fell short, and reuse as scaffolding across design and implementation.
Early design
I spent under an hour validating the design and content direction in a discussion with AI before opening Figma. Once the content direction was locked, I laid it into the existing UX pattern using only system components. I kept my time in Figma deliberately light, since I knew most of the quality refinement would happen later in code.
Visual asset placeholders
The experience needed custom illustrations, so rather than wait on the visual systems team, I fed the company-wide illustration and style guidelines into AI and asked it to reference them to generate the specific visuals my prototype called for. It produced solid, on-brand images and illustrations I could put straight into UX research, while the visual systems team built the final assets in parallel.
Prototyping
I built the prototype in Cursor, on top of a company-wide prototype shell. I fed it my Figma and content files to generate the end-to-end flow. A single strong prompt and about an hour of back-and-forth produced a working version. A second pass on visuals and near-final content, following the app's brand guidelines, took the prototype from generic to research and leadership ready.
Leadership alignment
To gain leadership backing, I needed alignment on the problem and the direction. I had AI consolidate the context from every agent thread into a single file, then used it to draft a leadership deck and design brief in our standard template. In about 30 minutes both were done and aligned between me and my PM. Together with the working prototype, we used them to propose the idea and get the go-ahead to begin UX research.
Outcome
Working with my PM and several agents across a few AI tools, we produced a solution direction, functioning prototype, leadership deck, and a design brief in roughly a day of continuous work, which cleared us to start research and move toward an implementation plan.
The judgmentGetting past the default AI output to something intentional and right for users, deciding what in the design to keep, push further, or discard to get leadership approval and move into UX research.
With leadership's approval, our next step was to put the prototype in front of users and plan for any iteration that came from their feedback.
03Research and synthesis
With a working prototype in hand, the next step was structured research. My research partner and I used AI to assemble a discussion guide, take notes, and synthesize findings. Here is where AI moved the work:
Assembling a discussion guide
We gave AI the design brief, the prototype, our list of research questions, and our discussion-guide template as guardrails. Within minutes we had a first draft to share with the team and refine as the sessions approached.
Research notes
Notetaking ran on AI during sessions, while the team worked in parallel to capture the points we wanted for the daily debrief.
Research synthesis
After the sessions were complete, we used AI to synthesize the research notes and identify the areas of success and places needing improvement. Within a couple hours we had the list of findings we needed to iterate the design before beginning implementation.
Outcome
My research partner and I leveraged AI to handle the bulk of the artifact production, so our time could go to the parts that needed us, engaging with users in the sessions, framing what we heard, and presenting the outcomes. Planning, execution, and synthesis that would normally take several weeks collapsed into about one, and we came out with the feedback we needed to make the experience better before final implementation.
The judgmentFraming the right questions before the sessions, and deciding which findings actually mattered after them.
With the feedback in hand, we took another pass at the design to refine it. From there, our next step was to turn it into an implementation plan we could build from.
04Implementation
With the design, documentation, and prototype finalized and reviewed by the right partners, it was time to build the implementation plan with AI. Here I deliberately brought in my technical program and engineering partners as reviewers and co-owners, so the plan was accurate and likely to produce shippable code with little rework. Here is where AI moved the work:
Setting the right context
The build plan was only as good as the artifacts behind it. I gave the agent our design brief, a video of the prototype, and the static Figma designs, and asked for a phased approach to building into the app across iOS and Android. Because the experience reused patterns from elsewhere in the app, I asked it to study the codebase and reuse as much existing code as possible while still keeping our unique design needs in mind.
Building the plan in phases
There were two ways to sequence the work. One split it into backend, frontend, and the connection between them. The other built a single flow end to end, tested it for quality, then used it as the template for the rest. Since the experience leaned heavily on backend data, I went with the single flow, confirmed the backend and frontend were communicating correctly, then had AI extend that pattern to the remaining flows.
Involving partners at the right moments
It's easy in this new way of working with AI to end up in a vacuum. To avoid that, I added my TPM and design partners as core collaborators on the design and implementation plans, and kept my PM and engineering partner as reviewers, ready to unblock or review when needed.
Writing the code
With the plan set, we moved into VS Code and used Claude, embedded in the editor, to build each phase. This was the longest stretch of the project, since every phase carried its own cycle of building, testing, and fixing before the next one could start.
Code review and experimentation
My engineering partner was most helpful in two moments, when the team hit blockers during vibe coding and implementation, and during the final code review before we opened the experience to a public experiment. With the code ready, we used AI to set up the experiment parameters, which let us stand up a public test quickly, gather feedback from real users, and watch for regressions against core metrics.
Outcome
AI accelerated the three heaviest parts of implementation: creating the plan, writing the code, and setting up the experiment. With partners involved at the right moments, we took the design all the way from plan to a live public test, work that would normally require a full engineering cycle, without losing the quality bar along the way.
ClaudeA phased plan across iOS and Android, reusing existing code. One flow end to end, then the template for the rest.VS Code + ClaudeEach phase built, tested, and fixed in cycles. The longest stretch of the project.The judgmentChoosing the build strategy, bringing partners in at the right moments, and holding the quality bar all the way into shipped code.
In this stage, AI did the building while the judgment stayed with me. Designers shipping code is common now, so that skill alone is not where the value is. The value is continuity of judgment. When the person who framed the problem stays with it through the build, the quality holds all the way through, including the details AI still gets wrong on its own.
The takeaway
All four stages of this project ran on the same pattern. AI handled the production of the artifacts we needed, which freed up my time to make the judgment calls that shaped the right experience for our users.
Choosing what to build
Framing the problem and setting the direction, before anything gets made.
Telling good from good enough
Moving past the competent default AI hands everyone, toward something intentional.
The quality calls AI misses
The craft and accessibility details that decide whether a product actually works for everyone using it.
With AI, everything moves faster, but speed is not the full story. What matters is where we spent the time we saved.
When building is cheap, what sets a product apart is the decisions AI can't make. Working this way, one person can carry an experience from a problem, through prioritization and planning, all the way to shipped and tested code. Holding that judgment steady and consistent across all of it is what makes the experience feel right.
This way of working is repeatable. Used this way, AI is a powerful tool for designers. It accelerates the work so we can spend our time on the decisions that truly matter for the people using what we build.