{"course":{"slug":"building-apps-with-ai","title":"Building Apps with AI","url":"https://addaly.com/learn/building-apps-with-ai","level":"beginner","track":"build"},"lesson":{"slug":"sketching-the-screens","title":"Sketching the screens, including the empty ones","url":"https://addaly.com/learn/building-apps-with-ai/sketching-the-screens","position":14,"of":87,"minutes":8,"answer":"Every data screen has four states and generated code builds only the loaded one, so write the empty, loading and error states into the request along with the phone-width layout.","keyIdea":"Every data screen has four states and generated code builds only the loaded one, so write the empty, loading and error states into the request along with the phone-width layout."},"body":{"format":"markdown","text":"## Four states, not one\n\nEvery screen that shows data has four states, and generated code reliably builds one of them.\n\n**Loaded**: the data is there and it looks how you imagined. This is the state everyone designs.\n\n**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.\n\n**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.\n\n**Error**: the request failed. Without a design, the screen either stays empty forever or shows a raw technical message from your database.\n\nWrite 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.\n\n```\nBookings page\n  Loaded:  list, newest first, date + stylist + service\n  Empty:   \"No bookings yet.\" and a Book now button\n  Loading: three grey placeholder rows, same height as real ones\n  Error:   \"Could not load bookings.\" and a Try again button\n```\n\nThat block, pasted into a prompt, produces a noticeably more finished feature than any amount of styling instruction.\n\n## Sketch on paper first\n\nA 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.\n\nWhen 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.\n\nThen 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.\n\n## Design the phone first\n\nMost 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.\n\nDesigning the narrow version first is not a constraint, it is a filter. What survives a 360-pixel-wide screen is what actually mattered.\n\nSay it explicitly, because the default output is desktop-shaped:\n\n```\nDesign for 360px width first. Everything must work with one thumb.\nNo horizontal scrolling anywhere. Tap targets at least 44px.\nTables become stacked cards below 640px.\n```\n\n## The wording is part of the design\n\nThe 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.\n\nThree 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.\n\nWrite 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.\n\n## What not to spend time on yet\n\nColours, 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."},"check":{"question":"A new user signs up and sees a blank white area where their bookings would be. What was most likely missing from the request?","options":[{"text":"A loading indicator, so the page appears blank while the request is in flight.","correct":false,"tempting":"Describes a different state with a similar symptom; loading resolves in under a second, while an empty account stays blank permanently."},{"text":"Error handling, since the query probably failed for a user with no data.","correct":false,"tempting":"Assumes a failure where the query succeeded and correctly returned nothing; no error occurred to handle."},{"text":"Mobile-first layout instructions, so the list rendered off-screen.","correct":false,"tempting":"Would misplace content rather than remove it, and would affect existing users as much as new ones."},{"text":"A designed empty state, because a correct query returning zero rows renders as nothing unless told otherwise.","correct":true}]},"prev":{"slug":"acceptance-checks-written-first","title":"Writing the acceptance checks before the code","url":"https://addaly.com/learn/building-apps-with-ai/acceptance-checks-written-first"},"next":{"slug":"naming-things-so-they-stay-findable","title":"Naming things so you can still find them","url":"https://addaly.com/learn/building-apps-with-ai/naming-things-so-they-stay-findable"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Sketching the screens, including the empty ones', in Building Apps with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-apps-with-ai/sketching-the-screens (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Sketching the screens, including the empty ones","courseTitle":"Building Apps with AI","module":{"index":2,"slug":"saying-what-you-want","title":"Saying what you want, precisely enough"},"answer":null,"keyIdea":"Every data screen has four states and generated code builds only the loaded one, so write the empty, loading and error states into the request along with the phone-width layout.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"four-states-not-one","runs":[{"text":"Four states, not one"}]},{"t":"p","runs":[{"text":"Every screen that shows data has four states, and generated code reliably builds one of them."}]},{"t":"p","runs":[{"text":"Loaded","b":true},{"text":": the data is there and it looks how you imagined. This is the state everyone designs."}]},{"t":"p","runs":[{"text":"Empty","b":true},{"text":": 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."}]},{"t":"p","runs":[{"text":"Loading","b":true},{"text":": 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."}]},{"t":"p","runs":[{"text":"Error","b":true},{"text":": the request failed. Without a design, the screen either stays empty forever or shows a raw technical message from your database."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"code","lang":"","label":"Text","text":"Bookings page\n  Loaded:  list, newest first, date + stylist + service\n  Empty:   \"No bookings yet.\" and a Book now button\n  Loading: three grey placeholder rows, same height as real ones\n  Error:   \"Could not load bookings.\" and a Try again button"},{"t":"p","runs":[{"text":"That block, pasted into a prompt, produces a noticeably more finished feature than any amount of styling instruction."}]},{"t":"h2","id":"sketch-on-paper-first","runs":[{"text":"Sketch on paper first"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"When you want it on a screen, the free options are good: "},{"text":"Excalidraw","b":true},{"text":" in a browser with no account, "},{"text":"Penpot","b":true},{"text":" for something closer to a design tool and fully open source, "},{"text":"Figma","b":true},{"text":" free for a small number of files. "},{"text":"Inkscape","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"design-the-phone-first","runs":[{"text":"Design the phone first"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Designing the narrow version first is not a constraint, it is a filter. What survives a 360-pixel-wide screen is what actually mattered."}]},{"t":"p","runs":[{"text":"Say it explicitly, because the default output is desktop-shaped:"}]},{"t":"code","lang":"","label":"Text","text":"Design for 360px width first. Everything must work with one thumb.\nNo horizontal scrolling anywhere. Tap targets at least 44px.\nTables become stacked cards below 640px."},{"t":"h2","id":"the-wording-is-part-of-the-design","runs":[{"text":"The wording is part of the design"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Three rules that carry most of it. Buttons say what will happen: "},{"text":"Book appointment","i":true},{"text":", not "},{"text":"Submit","i":true},{"text":". Errors say what to do next: "},{"text":"That time just went. Here are the next three openings","i":true},{"text":" rather than "},{"text":"Error: constraint violation","i":true},{"text":". Nothing apologises at length; one clear sentence beats a paragraph of regret."}]},{"t":"p","runs":[{"text":"Write the words in your sketch. If you leave them out, you will get "},{"text":"Submit","i":true},{"text":", "},{"text":"Success!","i":true},{"text":" and "},{"text":"Something went wrong","i":true},{"text":", and you will ship them, because by the time you notice you will have read them a hundred times."}]},{"t":"h2","id":"what-not-to-spend-time-on-yet","runs":[{"text":"What not to spend time on yet"}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A new user signs up and sees a blank white area where their bookings would be. What was most likely missing from the request?"}],"options":[{"text":[{"text":"A loading indicator, so the page appears blank while the request is in flight."}],"correct":false,"tempting":[{"text":"Describes a different state with a similar symptom; loading resolves in under a second, while an empty account stays blank permanently."}]},{"text":[{"text":"Error handling, since the query probably failed for a user with no data."}],"correct":false,"tempting":[{"text":"Assumes a failure where the query succeeded and correctly returned nothing; no error occurred to handle."}]},{"text":[{"text":"Mobile-first layout instructions, so the list rendered off-screen."}],"correct":false,"tempting":[{"text":"Would misplace content rather than remove it, and would affect existing users as much as new ones."}]},{"text":[{"text":"A designed empty state, because a correct query returning zero rows renders as nothing unless told otherwise."}],"correct":true,"tempting":null}],"order":[1,3,2,0],"why":null},"prev":{"slug":"acceptance-checks-written-first","title":"Writing the acceptance checks before the code","minutes":8},"next":{"slug":"naming-things-so-they-stay-findable","title":"Naming things so you can still find them","minutes":8}}}