Design can't wait until features are done

Building a product recently, I ran into a very direct problem:

plenty of features were done, but the product was really ugly.

Not just bad colors and fonts; the different pages clearly weren’t one coherent set:

• the information hierarchy differed
• similar actions used different interactions
• each page had its own structure
• the components kept drifting apart

My process at the time was roughly:

ChatGPT/Claude works out the requirements → Codex/Claude Code implements → features basically done → Claude Design deals with the design afterwards

Reviewing it with Codex, its judgment was:

design came in too late.

But my first reaction was actually confusion.

Indie development is about settling things as you build. Before many requirements are actually implemented, even I don’t know what they’ll end up looking like.

To bring design in earlier, am I supposed to do a complete pass of UX and UI before development?

Later I found I didn’t need to go to the other extreme.

The real problem is:

you can’t wait until features are done to deal with experience and design seriously for the first time.

When a coding agent writes code, it’s already deciding the UI/UX for you

As soon as a feature starts being implemented, it has to answer many questions:

• where users come in from
• what they see first
• how information is grouped
• where the main actions go
• whether to use a modal, a drawer or a new page
• whether to use cards, a list or a table
• how loading / empty / error are handled
• where to go once done

If none of this was defined beforehand, Codex can only choose for itself in order to complete the task.

Looking at any single page, the choices may all be defensible.

The problem is that different pages were generated in different tasks and different contexts.

So it easily ends up like this:

• one place uses a modal, while a similar action elsewhere jumps to a new page;
• one page is all cards, another is entirely a table;
• each choice had its reason, but together they don’t look like one product.

So waiting until all features are done and then asking a design tool to “make it consistent” is sometimes no longer a matter of changing colors and adjusting spacing.

The page structure and the interactions themselves may need redoing.

But design doesn’t need to be done all at once before development either

The problem on the other side is real too.

In indie development, many things really can only be judged once they’re built:

• how much real content there actually is
• how long AI output actually runs
• where users will get stuck
• whether a page is cramped once real data goes in
• whether a feature really needs to exist

So these days I don’t go:

all requirements settled → all UX done → all UI done → start coding

I’d rather have design come in three times.

First time: before development, settle the skeleton of the experience

This step is very light, with no need for full mockups.

Who does it:

mainly me + ChatGPT.

For a brand-new product, or when settling the overall visual direction for the first time, Claude Design comes in lightly.

What to settle first:

ChatGPT doesn’t just help me write “what this feature should do”; it also fills in the experience layer:

• what users come here to do
• where they enter, and where they go once done
• what the most important information is
• what the main actions are
• what loading / empty / error states there are
• which questions are still undecided

If Claude Design comes in, it mainly looks at the more global things:

• the overall character of the product
• navigation / app shell
• basic page structure
• information density
• the most basic visual direction

Output:

two very light things are enough:

UX skeleton

• User goal
• Entry / exit
• Primary flow
• Information hierarchy
• States
• Open questions

DESIGN.md v0

• product character
• UX principles
• navigation / app shell
• layout principles
• approaches I explicitly don’t want to see

It isn’t a full design system.

It’s more like drawing a few boundaries first, so the coding agent doesn’t decide from scratch every time.

Second time: once one real path runs end to end, do the design properly

This is the moment I now think matters most.

Not at the very start, and not once everything’s done.

But when there’s one real thing users can do from start to finish.

At last there is:

• real data
• real content
• real pages
• real interactions
• real information density

Who does it:

me + Claude Design.

First look at the UX based on the product that’s already running:

• does the flow run smoothly
• is the information hierarchy right
• do users know what to do next
• is there unnecessary complexity

Then do the UI:

• page structure
• typography
• spacing
• color
• components
• visual hierarchy

Once the design is settled, Codex comes straight back to implement it.

Otherwise Claude has one design while Codex keeps developing on the old structure, and they quickly split apart again.

Output:

this round starts producing a solid shared foundation:

• a few representative pages
• the app shell
• typography / spacing / color tokens
• basic components like button / input / card / table
• empty / loading / error patterns
• shared components actually landed in the code
• DESIGN.md v1

In other words, the shared design isn’t conjured up out of thin air at the start.

It grows slowly out of real pages.

Third time: later, wherever something changes, the right tool comes back

The end of the second round doesn’t mean “design is done.”

But there’s no need to go back to Claude for every field you change either.

These days I first judge what changed.

Only the content changed

For example, one more field, one less paragraph of explanation.

→ Codex reuses existing patterns.

The user flow or requirements changed

For example, adding a new entry point, or going somewhere new once done.

→ First update the UX skeleton with ChatGPT.

A new page or complex interaction appears

For example, the first appearance of:

• Review AI output
• Compare
• Timeline
• Complex filter
• Bulk action

→ Claude Design comes in again to design this new pattern clearly.

If it will be used again and again, add it to DESIGN.md and the shared components.

Pages start drifting apart as they grow

→ Claude Design does an overall design audit, and Codex then fixes things consistently.

So DESIGN.md isn’t written in one go either

I used to think:

the product isn’t even done; how could I define a design system first?

Now I think you don’t need to in the first place.

It can grow in stages.

Early on, settle the fairly stable parts:

• product character
• UX principles
• navigation
• app shell
• layout

Once real pages appear, add:

• tokens
• basic components
• common states
• interaction patterns

Only once a certain business pattern genuinely repeats, abstract it.

Not building a complete design system first and then the product.

Nor unifying everything once all pages are done.

But solving real problems first, then keeping the solutions that keep working.

Looking back at my original process:

ChatGPT writes requirements → Codex develops everything → Claude designs last

Now I’d change it to:

ChatGPT fills the requirements out to the UX layer → Codex first gets one real path running → Claude Design does UX + UI based on the real product → Codex lands the design foundation in the code for real → later, wherever something changes, the right tool comes back

Several AI tools can each provide product, design and engineering capability.

But they won’t automatically form a product team.

Experience ChatGPT didn’t spell out, Codex fills in itself in order to get the feature built.

Page structure Codex has already filled in, Claude can only keep editing on top of at the end.

In the end a person still has to keep judging:

is what’s missing now product judgment, experience design, visual design or implementation?

So in the end, “why is this product so ugly” didn’t lead me to:

from now on, do all the design first.

Instead it led to a simpler conclusion:

design doesn’t have to be done all at once, but it can’t start last.