Sketching the screens, including the empty ones

Four states, not one

Every screen that shows data has four states, and generated code reliably builds one of them.

Loaded: the data is there and it looks how you imagined. This is the state everyone designs.

Empty: a brand new user, no bookings, nothing to show. Left alone this renders as a blank rectangle, sometimes with a stray heading. The first thing every new user sees is the state nobody designed.

Loading: the half second while the request is in flight. Without a design, the page jumps as content arrives, or shows nothing and looks broken on a slow connection.

Error: the request failed. Without a design, the screen either stays empty forever or shows a raw technical message from your database.

Write one line for each, per screen. It takes two minutes and prevents the most common complaint about AI-built apps, which is that they look unfinished the moment anything is not perfect.

Bookings page
  Loaded:  list, newest first, date + stylist + service
  Empty:   "No bookings yet." and a Book now button
  Loading: three grey placeholder rows, same height as real ones
  Error:   "Could not load bookings." and a Try again button

That block, pasted into a prompt, produces a noticeably more finished feature than any amount of styling instruction.

Sketch on paper first

A pen and the back of an envelope beats any tool for the first pass, because it is fast and you are not tempted to make it pretty. Boxes, labels, arrows for what happens when something is pressed.

When you want it on a screen, the free options are good: Excalidraw in a browser with no account, Penpot for something closer to a design tool and fully open source, Figma free for a small number of files. Inkscape if you want a proper vector editor on your own machine. None of these need to be learned properly to be useful: a wireframe is boxes.

Then photograph the sketch and give it to the model. Every major tool reads images now, and a photo of a hand-drawn layout with three labels communicates more than a paragraph, particularly about arrangement: what sits beside what, what is above the fold, what is on a second screen.

Design the phone first

Most of the people who will use what you build are on a phone, and for large parts of the world that is not most, it is nearly all. A layout designed on a 27-inch monitor and then squeezed down produces the familiar result: a horizontally scrolling table, a button under the keyboard, text at 11 pixels.

Designing the narrow version first is not a constraint, it is a filter. What survives a 360-pixel-wide screen is what actually mattered.

Say it explicitly, because the default output is desktop-shaped:

Design for 360px width first. Everything must work with one thumb.
No horizontal scrolling anywhere. Tap targets at least 44px.
Tables become stacked cards below 640px.

The wording is part of the design

The text on a screen is not decoration you fix later. It is most of what the user actually reads, and it is where generated apps sound like software rather than like a person.

Three rules that carry most of it. Buttons say what will happen: Book appointment, not Submit. Errors say what to do next: That time just went. Here are the next three openings rather than Error: constraint violation. Nothing apologises at length; one clear sentence beats a paragraph of regret.

Write the words in your sketch. If you leave them out, you will get Submit, Success! and Something went wrong, and you will ship them, because by the time you notice you will have read them a hundred times.

What not to spend time on yet

Colours, fonts, shadows, animation. Not because they do not matter (a later course in this catalogue is entirely about design) but because they are the cheapest thing to change and the most tempting thing to fiddle with. A grey, ugly, correct screen can be made attractive in an hour. A pretty screen with no empty state has to be reworked.