Chapter 8The full prototype: every page, one design

Chapter 8 · Steps 12 and 13

The full prototype: every page, one design

3 min · 706 words

This is where it gets interesting, because now it's building the site. And notice we've barely had to do anything: hand it the idea, hand it the screenshots, choose. The skill did the rest.

Step 12: applying the design to everything

You say "let's move on" and ChatGPT starts creating, one by one, the pages we mapped out at the beginning: the categories with their filters, the product detail, the cart, the checkout, the payment page. All in the Purple design. All using the same design file.

While it works, it audits every page again at every resolution. Downloading the images, testing, fixing. All automatic. Sometimes it gets a bit stuck and you have to save by hand, but other times ChatGPT presses the save button on its own and even renames the file. Let it work.

You'll see the product page appear, and you'll notice something: it has exactly the structure of the page you handed over in step 2. And on the checkout, the postcode and the city sit in two columns, just like on the page we surveyed. That's what matters about structure. And the structure could have been a pencil drawing on a sheet of paper: what matters is having it before you apply the design.

This is where a lot of people make the mistake of thinking it all has to come out finished first time, well designed, well made. ChatGPT doesn't know what counts, for you, as good design. Thanks to the skill, it knows what standards good design has to meet in general. But not what you're after. That's why, instead of generating and generating and not liking it and asking again, every step we take is solid and is a step to build on: the idea, then the structure, then the wireframes, then the design survey, the brand survey, the prototype.

What you're looking at

The prototype is HTML. If you know nothing about programming, that's fine; but here's the gist. An HTML file is where the page gets structured: the hero has two columns, it uses this font, this button goes here. Animations and movement are done differently, with other libraries, and that comes later, when we create the project that goes on the web.

Look at the modal, the pop-up: it already has the site's design. That's the good thing about working this way. These are all solid steps; there's no "oh, but I didn't want it like that," "oh, but you did it this way." By choosing a proposal we generated a design file with all the information, and every page gets built from that file.

Step 13: review and approve

When it's done, you go through the whole prototype. The home page is identical to the one you already approved. The categories have the filters. The product page, the checkout, the payment page: they're all there.

The prototype: every page, one design.md design.md(Purple)+ the brandHomeCategoryProductCartCheckoutPaymenteach one checked on desktop, tablet and phone
Figure 15. One design file feeds every page. That's why the checkout and the home look like siblings.

If you want to change the design or the structure, this is the moment to say so, before you authorize it. But notice what kind of changes:

  • "The buy button doesn't show on the phone" → now.
  • "The checkout is missing the phone number field" → now.
  • "The site is too static, there are no animations" → not now.

Respect each moment. We haven't moved to a React project yet; we're on the prototype. Animations and dynamic behavior come later, and the idea is that by then the design and the structure are settled. So we're not changing things all the time, but using each step for the changes that belong to that step.

Anything to do with content (the copy, the product names), don't worry about that now either.

We were pretty happy, so we approved it. Think about it: from an idea and an intention ("I want to build a sneaker site") we got to a clickable site that looks pretty good. Now we add a little magic.