Lesson 45.1 gave you the browser's responsibility: presentation, interaction, local temporary state — everything the person sees and touches, with no secrets and no final authority. Now stay on that side of the boundary and learn what a good frontend actually is. It is not a set of colorful components. It is a set of user flows — the sequence of screens, decisions, and states a person experiences to finish one job — each designed to stay clear when reality intrudes.

The vocabulary, in plain language

• Page: a full screen or route with one primary job, such as the company search page or the saved watchlist page.
• Component: a reusable interface piece with a clear job — a search field, a research-result card, a save button. Not every <div> an AI happens to generate earns the name.
• State: what the interface currently holds or shows — the typed ticker, the signed-in user, the fetched brief, the error message. Some state is local and temporary (the draft query); the authoritative copy lives server-side.
• Navigation: how a person moves between pages and back — search results to brief detail to watchlist — without getting lost or losing work.
• Loading state: what the person sees while waiting — a skeleton card or "Fetching brief for AAPL…" — so waiting reads as progress, not breakage.
• Empty state: what the person sees when there is legitimately nothing to show — "No brief for this ticker yet. Try another symbol or request a refresh" — with a next action, not a blank panel.
• Success state: confirmation that the job finished — "AAPL saved to your watchlist."
• Error state: a plain-language explanation plus a path forward — "Provider data is unavailable right now. Your watchlist is unchanged; try again shortly."
• Responsive layout: the same job, reprioritized for a narrow screen rather than merely shrunk.

Hold that list against any AI-generated screen. A polished mockup that shows only the success state is a demo, not a frontend.

The Research Desk flow, end to end

Design the company-search job as one continuous flow before anyone writes code:

landing page → company search → loading
  → research brief → save button
  → signed-out prompt or saved confirmation
  → accessible error when provider data is unavailable

Concretely: a signed-out visitor searches AAPL, sees loading, reads the brief, clicks Save, and meets a signed-out prompt instead of a silent failure. A signed-in reader gets a saved confirmation. When the provider is down, both see an error that names what happened and what to do — readable by a screen reader, operable by keyboard, and legible on a phone. The brief itself keeps the Part II shape: structured data with a stable contract (ticker, summary, sources, dates) that the frontend renders but never redefines — if the shape changes, the contract in Lesson 46.2 changes first.

Neighborhood Events is the simpler mirror: browse public events → open an event → signed-out visitor sees "sign in to post" → organizer sees Edit only on their own listings → submitting an empty title returns the form with the error announced next to the field, focus moved to it.

Three questions before coding a screen

For every screen, answer these in writing — in the spec, in USER-FLOW.md, or directly in the task card:

1. What is the user trying to accomplish? ("Decide whether AAPL deserves a deeper look, then save it or move on.") If the answer is "see the dashboard," the screen has no job yet. 2. What information or choice is needed now? Show the evidence (summary, sources, dates) and exactly one primary action per step. Everything else is secondary or belongs on another screen. 3. What happens if data is slow, empty, incomplete, or rejected? Name the loading, empty, partial-data, and error rendering for this screen specifically. "The API always returns data" is not an answer.

The third question is where AI screens fail most often. The model shows you the happy path because the happy path is what you praised. Your job is to demand the other four paths before accepting the work.

Semantic HTML and accessible interaction

Accessibility is part of the product definition, not a decorative final check. AI can produce a polished screenshot that fails every one of these — and a screenshot cannot be keyboard-tested. Teach these as build rules:

• Use real buttons for actions. A Save control is a <button>, not a clickable <div>. Real buttons are keyboard-focusable, activatable with Enter and Space, and announced correctly by assistive technology for free.
• Label every input. The ticker field gets a real <label> ("Company ticker"), not placeholder text alone. Placeholders vanish when typing; labels persist.
• Keep keyboard focus visible and logical. A person tabbing through search → result → save must always see where they are, reach every action, and never get trapped. Test with Tab, Shift+Tab, Enter, and Escape — no mouse.
• Use sufficient contrast and meaningful headings. One <h1> per page naming the job ("Research brief: Apple Inc."), subheadings in order, body text with contrast that survives sunlight on a phone.
• Write error text that explains. "Invalid input" helps nobody. "Use a 1–5 letter ticker, such as AAPL" plus moving focus to the field helps everybody — and helps screen-reader users most of all.

A minimal sketch of the discipline:

<h1>Research brief: Apple Inc. (AAPL)</h1>
<label for="ticker">Company ticker</label>
<input id="ticker" name="ticker" autocomplete="off" aria-describedby="ticker-hint" />
<p id="ticker-hint">Use a 1–5 letter ticker, such as AAPL.</p>
<button type="submit">Search</button>
<p role="alert">Provider data is unavailable right now. Your watchlist is unchanged.</p>

Real elements, real labels, a live region (role="alert") so the error is announced. For the full foundation, work through MDN Learn Web Development and its accessibility guidance.

Responsive is priority, not shrinking

On a phone, the primary action and key evidence must remain understandable; secondary panels can move or collapse. For the brief page that means: company identity, verdict summary, Save action, and sources stay in the first scroll; related-companies sidebar, methodology notes, and historical charts collapse below or behind disclosure controls. The acceptance question is behavioral: can a phone user complete the search → read → save job with one thumb and no horizontal scrolling? If the desktop three-column grid merely shrinks until the Save button is unreadable, the layout is responsive in name only.

Give the AI this constraint explicitly (tokens, breakpoints, what collapses first), or it will hand you a desktop screenshot stretched thin.

The bounded AI task

Now convert all of the above into a task card the agent cannot inflate. Adapt this example:

Notice what it does: names one component, pins the visual system, demands the neglected states, forbids scope creep, and states the evidence (keyboard proof plus two screenshots).

Practical exercise: specify the flow

Write the Research Desk search-to-save flow (or one Neighborhood Events flow) as a USER-FLOW.md: screens in order, the decision at each step, and the rendering for normal, loading, empty, success, and error cases. Then attach acceptance checks covering normal, loading, empty, error, keyboard, and mobile — for example: "Tab order reaches Search → result heading → Save with visible focus; error text is announced; on a 360px viewport the Save button and verdict remain visible without horizontal scrolling."

Finish line: a USER-FLOW.md plus acceptance checks for normal, loading, empty, error, keyboard, and mobile states.

Verify: run the keyboard pass (unplug the mouse) and load the flow at mobile width. Every check must describe something observable: focused element, announced message, visible button — never "looks good."

Common failure mode: checks that cover only the success screenshot. If loading, empty, and error have no named rendering, the frontend is unfinished no matter how attractive it is.

Check your understanding

1. Define component, state, and user flow without using the word "screen" twice. 2. What three questions precede coding, and which one catches most AI-generated gaps? 3. Why is a <div> with a click handler not a button? 4. What collapses first in a responsive brief page, and what must never collapse away? 5. What four constraints in the example AI task prevent a redesign?