Chapter 3. The Dining Room

Yesterday you put a page on the internet. Today you turn it into something people can use: the user interface, the part of software you can see and touch. This chapter is about what a UI is made of, the different places a UI can live, and one rule about the dining room that every app-builder has to learn.

What a UI actually is

A UIUI (user interface)Everything a person sees and taps in an app: screens, menus, buttons and forms. (user interface) is everything between a person and the software: the screens, buttons, text, colours, sounds and even the little vibration when you tap "Pay". Some people say UX (user experience) too. UI is what it looks like; UX is what it's like to use. Good UX is Rohit ordering one-handed without thinking.

The anatomy of a screen

Every screen you've ever used, from WhatsApp to your bank, is made of the same four things. Once you can name them, you can describe any screen to Sous precisely.

Layout

LayoutLayoutWhere things sit on a screen: header, content, sidebars, a bar fixed to the bottom. is where things sit. A header at the top, a list in the middle, a button stuck to the bottom. On a phone, layouts are mostly one column, stacked. On a laptop, you might have a sidebar and two columns.

Describe layouts by region: "A sticky header with the café name. A scrolling list of menu items. A cart bar fixed to the bottom of the screen."

Components

A componentComponentA reusable building block of a UI, such as a button, card or drawer, built once and used many times. is a reusable building block. You build a "menu item card" once and use it twenty times. The common ones have names everyone, including Sous, understands:

Using these exact names in prompts gets you far better results than "a box thing that pops up".

States

This is the part almost every AI-built app gets wrong. A screen isn't one picture. It's several, depending on what's going on. Every screen that shows data needs at least four statesUI statesThe different versions of a screen depending on what's happening: empty, loading, error and success.:

• Empty: nothing here yet. "Your cart is empty. The masala chai is very good."
• Loading: waiting for data. A spinner, or grey placeholder shapes called skeletons.
• Error: something failed. Say what happened and what to do: "Couldn't load the menu. Check your connection and try again." Plus a Try again button.
• Success: the happy path, with real content. Plus confirmations: "Order placed! Pick up at the counter in about 5 minutes."

Sous builds the success state beautifully, because that's what you described. Ask for the other three by name, or you won't get them.

Navigation

NavigationNavigationHow people move between screens: tabs, links, back buttons and menus. is how people move between screens: tabs at the bottom, a back arrow, a menu icon, links. Good navigation answers three questions at a glance: where am I, where can I go, how do I get back?

For QueueLess, Pixel's rule is simple: a customer should reach "Pay" in four taps or fewer from opening the app.

The surfaces: where a UI can live

"Build me an app" can mean very different things. Here are the main surfacesSurfaceA place where a UI lives: a website, web app, mobile app, desktop app, watch or chat. a UI can live on, and when to pick each.

A few notes on the less obvious ones:

• A PWAPWA (progressive web app)A web app that can be added to a phone's home screen and open full-screen like an app, without an app store. (progressive web app) sits halfway between a website and an app. You visit it in the browser, tap "Add to Home Screen", and it opens full-screen with its own icon. For a café, that's often enough.
• A native appNative appAn app installed from the App Store or Play Store, built for the phone platform (Swift, Kotlin) or with cross-platform tools like Expo or Flutter. is built specifically for one phone platform. Expo (built on React Native) and Flutter let one codebase run on both iPhone and Android, and AI tools handle Expo well. Store review, developer fees and update delays come with the territory.
• Watch apps are tiny. A watch screen is about the size of a postage stamp. You show one fact and one or two buttons. Nobody browses a menu on their wrist.
• Chat UIs are growing fast. Some products now live mainly inside an AI assistant, as a connector that does one job well.

Why a web app is the right first product

For QueueLess, and probably for your first product, the answer is a web app, built phone-first. Here's why:

• One codebase, every device. It works on iPhones, Android phones, laptops and tablets the day you ship it.
• No app store. You deploy in a minute with Vercel. No review, no waiting, no fees per download.
• Instant updates. Fix a bug, push, and every customer has the fix on their next visit.
• Zero install friction. Rohit scans a QR code at the counter and he's ordering. Asking a stranger to download an app loses most of them.
• AI is great at it. Next.js, Tailwind and React are the most common patterns in Sous's training. Fewer mistakes, faster fixes.

Later, if customers ask for push notifications or a home-screen icon, you can make it a PWA. If thousands of regulars want a proper app, you can build one with Expo, reusing your server and database. You don't have to decide that today.

Design basics for non-designers

You don't need to become a designer. You need five basics, so you can tell Sous what's wrong with a screen and how to fix it.

1. Hierarchy

HierarchyVisual hierarchyArranging a screen so the most important things are the most noticeable, using size, weight, colour and position. means the most important thing is the most noticeable. On a menu, that's item names and prices, then the Add button. Not the logo. Not the sparkle icon.

Squint at your screen until it's blurry. What stands out? If it's not the thing that matters most, change size, weight or colour until it is.

2. Spacing

Cramped screens feel cheap; generous spacing feels calm and expensive. Use a consistent scale, such as 4, 8, 12, 16, 24, 32 pixels, rather than random gaps. Tailwind does this for you: p-2 is 8px, p-4 is 16px, p-6 is 24px.

Related things sit closer together. The item name and its price are close; two different menu items have more space between them.

3. Type scale

Pick a few text sizes and stick to them: one for headings, one for item names, one for body text, one for small print. Too many sizes look messy. On phones, body text should be at least 16px, so nobody has to pinch-zoom. Use one font family, two at most.

4. Colour and contrast

Use one main brand colour (Meera's deep chai orange), one or two neutrals, and colours with a meaning: green for success, red for errors. Use your brand colour for the main action, like Add and Pay, so people know where to tap.

ContrastContrastHow much text stands out from its background. Normal text should have a contrast ratio of at least 4.5:1 to be readable. is how much text stands out from its background. Pale grey on white looks stylish and is unreadable in sunlight. The accessibility guideline is a contrast ratio of at least 4.5:1 for normal text. Browser DevTools and free online checkers will tell you the ratio.

That's part of accessibilityAccessibilityMaking software usable by everyone, including people with low vision, colour blindness, limited movement or a screen reader.: making your app usable by everyone, including people with low vision, colour blindness, shaky hands or a screen reader. Big tap targets (about 44px), real labels on inputs, and not using colour alone to show meaning go a long way. Mrs. Kapoor, seventy-eight, a regular since 1998, will thank you.

5. Phone-first, responsive design

Responsive designResponsive designLayouts that adapt to the screen size, usually designed for phones first and then spread out for larger screens. means the layout adapts to the screen size. Design for the smallest screen first, then let it spread out on bigger ones. It's much easier than squeezing a laptop design onto a phone.

Most of Meera's customers will use QueueLess on a phone, in a queue, with one thumb. So: big buttons in the bottom half of the screen, where thumbs reach, and nothing important hidden behind hover effects, because phones can't hover.

Why AI apps all look the same

Sous learned from millions of websites, so when you say "make it look nice", it gives you the average of all of them: purple-to-blue gradients, rounded cards, a sparkle icon, grey text. Pixel calls it "the AI look". It's not ugly. It's just forgettable.

The fix is a design systemDesign systemA written set of design decisions (colours, fonts, spacing, components) that keeps every screen consistent.: a short set of decisions written down once. Your exact colours, fonts, spacing scale, corner radius and how buttons look. Then every prompt says "follow our design system", and every screen looks like it belongs to the same café. You'll build one properly in Chapter 12. For now, giving Sous three specific choices ("deep orange #C2410C, cream background, chunky rounded buttons") already beats "make it nice".

The golden rule of the dining room

This is the most important idea in the chapter, and one of the most important in the book.

Anything in the UI can be read and changed by the user.

When someone opens your web app, their browser downloads your page's code (the HTML, the CSS and the JavaScript) onto their device. It's theirs now. Every browser comes with DevToolsDevToolsDeveloper tools built into every browser that show a page's code and let you inspect and edit your own copy of it live., a built-in panel for developers that lets anyone see that code and edit it live, on their own screen.

On a phone ordering screen, a cursor edits the price of masala chai from 40 to 0 rupees in browser developer tools and places the order. Meera is shocked; a stamp reads 'Trusted the browser'.

That means a customer can, on their own phone or laptop:

• Read everything you sent: text, hidden elements, data, and any keys you put in the code
• Change prices shown on the page
• Reveal hidden buttons (an "Admin" button you only hid with CSS)
• Flip flags like isAdmin = true or isPremium = true in the page's code
• Change what the page sends to your server when they tap "Pay"

This isn't hacking in the movie sense. It's how browsers work, and it's been true since the 1990s. DevTools exist so developers can debug their own pages.

So the question isn't "can a customer change the price on their screen?" They always can. The question is: does your app believe them? If the page tells your server "one masala chai, ₹0" and your server says "OK!", that's a bug, and it's your bug.

Building the dining room

Time to turn Pixel's napkin into real screens. You'll use claude.ai for thinking and sketching, and Claude Code in your queueless repo for building.

This screen looks like a generic AI-built app. Restyle it with these decisions only:
- Brand colour: deep chai orange #C2410C for main actions only
- Background: warm cream #FFF7ED; text: dark brown #431407
- Font: one family; headings bold, body 16px
- Corners: rounded-xl on cards and buttons
- No gradients, no sparkle or AI icons, no grey buttons

Check every text colour against its background meets a 4.5:1 contrast ratio and tell me any that don't.

What you've learned

• A UI is the dining room: everything users see and touch. Every screen is layout, components, states and navigation.
• Every screen that loads data needs empty, loading, error and success states. Ask for them by name.
• UIs live on many surfaces: websites, web apps, PWAs, native mobile, desktop, watches and chat. Start with a phone-first web app.
• Hierarchy, spacing, a type scale, contrast and phone-first layout make AI screens look intentional. A design system fixes the AI look.
• Anything in the browser can be read and changed by the user. The browser shows; the server decides.