You can have the backend ready, your API working, and your components planned out — and still spend hours trying to figure out how the interface should actually look.

Where should the buttons go?

How many screens should the flow have?

What should the onboarding experience look like?

How should a subscription screen be structured?

And most importantly: what makes an app feel polished instead of looking like another template?

I used to start with a blank screen and try to answer all of these questions myself.

That changed when I started treating UI design as a research problem first and a coding problem second.

Instead of designing everything from scratch, I started looking at how existing apps solve similar problems, studying their interface patterns, and using that information as context when building my own UI.

For one of my recent experiments, this approach allowed me to go from UI research to a working, polished interface in roughly 15 minutes.

The interesting part wasn't simply generating the UI with AI.

It was the process I used before generating it.

In this article, I'll walk through that process and show how I went from:

Research → UI patterns → AI-assisted implementation → Working app UI

without starting with a completely blank canvas.

Step 1: Stop asking AI to “make it look good”

This was probably the biggest change.

A prompt like:

Build a modern mobile onboarding screen. Make it clean, premium and minimal.

sounds reasonable, but it doesn't really give the model much useful information.

Words like modern, clean and premium are subjective.

The AI still has to guess:

how much content should be on each screen where the CTA should appear whether the flow should use cards or full-screen layouts how progress should be shown when signup should happen where monetization should appear

You can keep regenerating until something looks decent, but you're basically iterating on guesses.

A better approach is to give the model real visual and product context.

Step 2: Research the flow before designing it

Let's say I'm building an app with onboarding followed by a subscription screen.

Before touching the UI, I want to understand how other products structure the same journey.

I usually look for things like:

onboarding length headline structure CTA placement progress indicators personalization questions permission requests signup timing paywall placement pricing hierarchy trial messaging

I'm not trying to copy a particular app.

I'm trying to understand the patterns.

For example, after looking at several onboarding flows, you may notice that many apps introduce the value proposition first, personalize the experience next, and only ask the user to create an account once they already understand the product.

That is useful product information.

Step 3: Look at complete flows, not random screenshots

This matters more than I expected. A beautiful screenshot tells you what one screen looks like. A flow tells you why that screen exists.

When researching an interface, I want to understand what happened before the screen and what happens after it.

For example:

Welcome ↓ Goal selection ↓ Personalization ↓ Notification permission ↓ Account creation ↓ Paywall ↓ Main app

Now I have something much more useful than a Pinterest-style collection of isolated UI screenshots.

For this kind of research, I've been using AppLlama, which lets you explore real mobile app screens and complete user flows instead of manually installing and navigating through every app yourself.

The important part for me isn't finding something to copy.

It's getting enough context to answer:

“How do real products solve this problem?”

Step 4: Extract the patterns you actually want

After looking through a few examples, I don't dump everything into the AI.

I reduce the research into a short set of decisions.

For example:

Onboarding direction:

• Full-screen layout

• One question per screen

• Large headline

• Minimal supporting copy

• Primary CTA fixed near the bottom

• Progress indicator at the top

• Soft card-based answer selection

• Ask for signup near the end

• Introduce subscription after personalization

Now the AI has actual design constraints. Compare that with:

Make a beautiful modern onboarding flow. The difference in output quality is huge.

Step 5: Give the coding agent context before asking for code

Once I've decided on the direction, I give the coding agent a prompt closer to this:

Create a mobile onboarding flow.

Design direction:

• Full-screen minimal layout

• One main action per screen

• Large typography with short supporting copy

• Progress indicator at the top

• Selectable cards for answers

• Sticky primary CTA near the bottom

• Rounded components with generous spacing

• Avoid dashboard-style UI

• Avoid excessive gradients

Flow:

1. Welcome

2. Goal selection

3. Experience level

4. Personalization

5. Account creation

6. Subscription offer

7. Main screen

Build the UI as reusable components and keep the visual language consistent across every screen.

Now the AI isn't inventing the product structure and the UI direction simultaneously.

A lot of the important thinking has already happened.

It just needs to implement it.

Step 6: MCP makes this workflow even more interesting

There's another problem with the workflow above.

You still have to manually:

research apps collect references describe the patterns paste everything into your coding agent

This is where Model Context Protocol (MCP) starts becoming useful.

MCP allows AI tools and coding agents to connect to external tools and data sources.

Instead of the agent knowing only what's inside your prompt, it can potentially retrieve additional context while working.

For mobile UI development, that means the research stage can become much closer to the actual coding stage.

With AppLlama's MCP integration, for example, an AI coding workflow can access mobile app research context without you manually moving every reference between different tools.

That changes the process from:

Research somewhere → Save screenshots → Open coding tool → Explain screenshots → Generate UI

to something closer to:

Research ↓ AI Agent + MCP ↓ Relevant UI context ↓ Implementation

It's a small change conceptually, but it removes a lot of friction.

Skills make the agent more consistent

MCP gives the agent access to context.

Skills help tell the agent what to do with that context.

This is another part of AI-assisted development that I think is underrated.

Giving an agent more information doesn't automatically mean it will use that information well.

A reusable Skill can define things like:

how to research similar mobile apps what UI patterns to look for how to compare flows what information matters before implementation how to translate references into design decisions what to avoid when generating the final UI

So instead of repeatedly writing a giant prompt explaining your process, you can reuse the same workflow.

For me, the interesting combination is:

MCP = context

Skills = process

Coding agent = implementation

Step 7: Let AI build the first version, not the final version

Once the research and direction are clear, generating the first version becomes extremely fast.

But I still don't treat AI-generated UI as final.

I use it as a strong first implementation.

I normally check:

Visual hierarchy

Can I immediately tell what the user should focus on?

Spacing

Does the interface have enough breathing room?

Consistency

Are buttons, cards, radii and typography consistent across screens?

Flow

Does moving from one screen to the next actually make sense?

Mobile behavior

Does the UI still work on smaller screens?

Product logic

Does this flow make sense for my product, or did I blindly inherit a pattern from another app?

That last one is especially important.

Research should help you make decisions.

It shouldn't make the decisions for you.

The 15-minute experiment

The reason this workflow surprised me was how little time I actually spent “designing” in the traditional sense.

Most of the process was simply:

Define what flow I was building Look at relevant real-world examples Identify recurring patterns Decide which patterns made sense Give that context to the coding agent Generate the first implementation Make a few visual adjustments

The actual coding wasn't the difficult part.

The difficult part was deciding what should be coded.

Once that decision was supported by good references, everything else moved much faster.

The bigger shift: UI research is becoming part of development

Traditionally, these were fairly separate activities:

Product research ↓ UX design ↓ UI design ↓ Development

AI tools are slowly compressing that workflow.

A developer can now research interfaces, reason about patterns, generate components and iterate on implementation without constantly switching between completely disconnected processes.

That doesn't eliminate designers.

And it definitely doesn't eliminate product thinking.

If anything, it makes good product context more important.

When generating code becomes cheap, deciding what should be generated becomes much more valuable.

Don't vibe code blind

I like AI coding.

I like being able to build an interface in minutes instead of spending hours on repetitive frontend work.

But there's a difference between:

“Generate something that looks good.”

and:

“Here are the patterns, product decisions and real-world references. Build an interface based on this direction.”

The second one consistently gives me better results.

So my current workflow is simple:

Don't start with code.

Don't even start with the design.

Start with context.

Research how the problem is already being solved, understand the patterns, decide what makes sense for your product, and then let AI help you implement it.

The blank canvas becomes a lot less intimidating when it isn't actually blank.