Skip to main content
NOWUPDATING
Contact us
Back to blog

Why Does Designing Webpages with Codex Lead to So Many Revisions?

Repeated Codex revisions can leave a page visually inconsistent and communication costly. This workflow review compares direct chat, design skills and Canvas, explaining why it helps to define design rules first and separate visual design from implementation.

Over the past few days, I have been exploring one question:

How can I use Codex to design webpages more efficiently?

This is probably a familiar difficulty for many people building pages with AI:

It can generate a page, but rarely delivers the intended result in one attempt.

I have mainly tried three approaches.

1. Repeated conversations with Codex alone are inefficient

I started without a strategy, simply chatting continuously with Codex.

Once a page was generated, I kept pointing out what I disliked:

  • Adjust this part;

  • Rearrange that section;

  • This module does not look good enough;

  • Use annotations to select areas and comment, then ask Codex to change them individually.

This seemed the most direct approach, but the results were disappointing.

Each revision addressed only a local detail.

Web design needs an overall visual style, layout rules, content hierarchy and component consistency. It is more than individual pieces assembled together.

Without defining those rules upfront, later conversations become a continuous attempt to correct the design.

The result:

  • Many rounds of revisions;

  • A large amount of usage allowance consumed;

  • A page that still struggles to reach the intended finish.

2. Design skills help, but the process is still not lightweight

I then tried an approach widely recommended online:

Adding design-related skills or MCP integrations to Codex.

For example:

  • Product Creation, included with Codex;

  • Claude Frontend Design Skill;

  • Other design skills.

This does help.

Skills guide Codex closer to the desired design direction, and repeated correction can produce an initially usable page.

But the underlying problem remains.

You are still using rules and feedback to help Codex understand the intended visual result.

Skills solve some problems, but do not replace an upfront website design specification.

3. My current approach: design in Gemini Canvas, then implement with Codex

I now start with Gemini Canvas.

The process is:

  1. Plan the page content;

  2. Put it into Gemini Canvas;

  3. Adjust the design toward the desired result;

  4. Confirm the overall design and export HTML;

  5. Give the HTML to Codex to implement in the project.

I choose Gemini Canvas not because it generates better code, but because it suits the page-design stage.

It is more useful to me for working through the visual design.

Before starting, you can specify the site's design rules, such as:

  • Visual style;

  • Color palette;

  • Typography;

  • Button styles;

  • Card styles;

  • Spacing rules.

It tries to follow those rules across the whole page instead of treating each module independently.

You can also give Gemini Canvas a webpage you like.

It can use that style as a reference to adjust the entire page, rather than changing only one detail.

This helps substantially during design.

It lets the page be improved from an overall visual perspective, partly addressing the inconsistent styling I encounter when designing directly with Codex.

After trying the full process, I also found:

The difference between AI models for web design is not as large as I had imagined.

The stronger influences are still:

  • Whether the design rules are clear beforehand;

  • Whether someone judges the visual result afterward.

For reaching my intended result quickly, however, I currently prefer Gemini Canvas.

Its page output is relatively consistent.

I also find Gemini Pro's allowance comparatively generous for repeated design adjustments.

Once the overall design is confirmed, I export the HTML and ask Codex to integrate it into the project.

Separating page design from code implementation makes the workflow smoother.

4. A workflow that has produced better results in my recent practice

I also reviewed how other designers and developers use Codex. Combined with my recent experiments, the following process seems useful for both cost and results.

Step one: define the website's design rules.

These can live in Agent.md or a separate design specification.

For example:

  • Typography;

  • Page style;

  • Color palette;

  • Buttons;

  • Cards;

  • Spacing;

  • Module structure;

  • Rules for what to avoid.

This step matters.

Whether the next tool is Codex, Claude or Gemini, those rules should constrain the overall page design.

Step two: use skills, MCP or Canvas to produce consistent output.

With the design specification in place, use these tools to generate the page.

In principle, a ready-made skill can support this step.

In practice, many design skills I found online did not perform as well as expected.

For now, it may be better to start with methods others have validated, then gradually develop a workflow suited to your project.

Step three: continue improving the current version.

Iteration is still necessary.

For example:

  • Content hierarchy;

  • Module structure;

  • Images and visual elements;

  • Whitespace;

  • The page's overall feel.

I have not yet found a way to leave all of these judgments to AI.

That is why I currently treat AI as a tool for rapid generation and execution, rather than a complete replacement for web design.

This is the more efficient approach I found after testing the full process over the past few days. I will continue updating it as I try new methods.

Related reading

Discuss page design and delivery

If repeated revisions are not meeting your needs, share the current pages, design requirements and features you need delivered.

Discuss page requirements