AI-Native Design Process

Discovering app-wide people problems

The user group our project focused on had years of research documented across the org. I linked every relevant doc and asked AI to surface where people struggled with settings, and how those struggles shifted over time. It came back with trends rather than anecdotes.

It also caught something we had not gone looking for. The same problems showed up well beyond our user group, across other populations at the company. That widened the case for the work, since solving for our group would not only help them, it would scale to a much larger set of people.

Choosing the most impactful problem

I ran the problem list against our team, app, and company strategy to weigh the impact on our users against the impact on the business.

That mapped our user problems onto the company's high priority areas, like video and AI. Inside those areas the general problems got sharper, closer to the specific jobs people were trying to do in each one. It also showed which problems to deprioritize for this effort. They were still real, just not the ones this work was positioned to solve.

Without that analysis we would have presented leadership with a case built on what users needed and little else, which is a common way for design work to stall. Instead we could speak to what users needed, what the business needed, and where the two overlapped across other teams.

Reusing a pattern instead of inventing a new one

Our cross-functional team spotted a design pattern used elsewhere in the app that fit our problem. I had AI comb the internal documentation for where it had been applied and how it had performed.

The analysis told us why the pattern worked, and it turned up something more useful than we expected. In experiments where teams had deviated from the pattern, test results showed those deviations performing worse. That sharpened the decision. Stick to the established flow where the pattern was proven, and tailor only where our use case genuinely needed it.

Deciding what to keep from the first draft

I laid the flow out in Figma using only design system components. That gave Cursor something it could map straight to real code, and it meant the accessibility already built into those components came with them, rather than being something to retrofit at the end. A strong prompt and my Figma files got it to a working flow that linked the screens. It was competent, and it was not enough. Of the areas that needed refinement, two took most of my time.

The first was language. I drafted the settings copy with AI and had my content designer validate it, which left us with two directions worth testing. One spoke to the user, who they were and what they needed. The other spoke to the part of the app they were trying to change. Both read well, so rather than argue it, we took both into research.

The second was disclosure. The first draft let people change settings without a sense of what would happen. I added moments of education before configuration, so the choice was informed rather than just available.

Asset placeholders that stayed placeholders

Our experience needed custom illustrations and icons, which the visual systems team owned. AI could generate something on-brand from the company style guidelines in minutes, and that speed was a trap I needed to avoid. Waiting for the real assets would hold up research, while moving ahead risked letting the generated placeholders quietly become the final ones. Instead, I used AI for visuals good enough to test with, and partnered with the visual systems team on the real assets in parallel. Research was never blocked, and the craft stayed with the people who own it.

Getting leadership buy-in

I consolidated the context from every agent thread into a single file and used it to draft a leadership deck and design brief in our standard templates. About 30 minutes of production and a few tweaks with my PM had us ready for the review, where we walked leadership through the people and business problems, the designs, and the timeline for research and implementation.

There was very little pushback. The work aligned with company and team goals, and because it was AI-native it asked for very few resources. Their one request was that we share what we learned back with the teams whose patterns we had built on, so those patterns could improve too.

Asking the right questions

We gave AI the design brief, the prototype, and the team's initial research questions, and a first draft came back in minutes. The questions were ours. AI put them into our template and did it well, so there was not much left to improve. As the sessions approached, more questions surfaced in team discussions and we added those by hand.

What we heard back from users

AI took notes live and synthesized the sessions afterward, so my research partner and I could spend the sessions listening closely and asking better questions instead of writing things down.

Our users answered the language question, preferring the version that spoke to the product experience and what the settings would improve over the one that spoke about them. The disclosure design held up as well, since people told us they wanted to stay in control of their settings at all times, which is exactly what those education moments were there to protect. The direction itself held too, with users describing the experience as something they wanted.

How we iterated

Those findings drove the last design passes before implementation. We locked the content direction users had chosen, and pushed the educational content further, since people had told us that staying in control mattered and clarity was the whole point of those moments.

That content decision also reached the illustrations. We went back to the visual systems team to make sure the real assets spoke to the product experience rather than to the user, so the whole experience stayed consistent with what research had settled.

Choosing the build strategy

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, then used it as the template for the rest. The experience leaned heavily on backend data, so I chose the single flow, which let us validate as we progressed.

That turned out to be the right call. Building one flow completely meant testing the backend and frontend together across iOS, Android, and web, so we knew the whole path worked before replicating it across the other content modules in the settings feature. The alternative would have left a much larger surface to debug. If something broke in the connection, the problem could have been anywhere in it, instead of inside the one small flow we had just built.

Maintaining collaboration

It is easy in this new way of working with AI to end up in a vacuum. To avoid that, I added my TPM and content designer as core collaborators on the design and implementation plans, and kept my PM and engineering partner as reviewers.

Each of them mattered at a different point. My TPM reviewed the build plan before we started, so the resources and sequencing were sound before anyone wrote code. My engineering partner reviewed every diff I landed and dug into the code when automated tests failed, which is where I needed someone who could read it more deeply than I could. My content designer signed off on the final strings and worked with the internationalization team to get them translated into every language we shipped in.