Keep 25 minutes selected. Leave Task blank and choose Build my plan. Read the specific error and check what remains.
Screen 1 of 100:00–0:05
First, use a web app before you design one.
For this course, a web app is a page in a browser that accepts input, responds to an action, changes visible state, and provides a way to continue or recover.
STUDY SPRINTPlan one focused work block
INITIALEnter the fictional task Review chapter notes. Build again and check the 2 + 20 + 3 minute result.
Choose Revise task, then Start over. Notice what each action preserves or removes.
Discuss after all three rounds: What did the user do? What changed on the page? What stayed available—and why does that matter?
Why this leads forwardThe next two screens preserve the same user task while identifying the decisions and web layers behind it.
5 MIN
Screen 2 of 100:05–0:11
Choose a starting idea and name six decisions.
Study Sprint starts here: a fictional student chooses a task and time to receive a three-step plan. Reuse a Topic 7 idea only if useful.
PROBLEM + USERWho struggles with what?
AUTHORIZED INPUTWhat may enter?
VISIBLE OUTPUTWhat can the user inspect?
BOUNDARYWhat stays out?
HUMAN CHECKWhat requires judgment?
OPEN QUESTIONWhat should the wireframe test?
Start here: use the complete Study Sprint seed for full-credit classwork and assignment evidence. No prior project is required.
Why this leads forwardNow map the seed into the four parts that make a static web page understandable.
6 MIN
Screen 3 of 100:11–0:19
Now peel back the four layers of the same app.
Use the layer tabs, then change presentation and custom behavior. The layers cooperate; they are responsibilities, not four sealed boxes.
STUDY SPRINTPlan one focused work block
INITIALBoth the course CSS presentation and custom JavaScript behavior are active.
Open each layer in order and connect it to something you can point to in Study Sprint.
HTML gives the page meaning and structure.
It declares the heading, labels, task input, time choice, button, and result region. The task input is marked required.
CSS presents the interface.
It controls spacing, contrast, hierarchy, state styling, and responsive layout. Remove the course styling: the meaningful controls remain, but their presentation changes.
JavaScript adds custom behavior and state changes.
It reads the submitted values, calculates the 2 + work + 3 minute plan, shows the result, focuses the missing field, and supports revise/reset.
The browser renders and runs the page.
It interprets HTML and CSS, executes JavaScript, manages focus, and can enforce native constraints such as required. The final behavior emerges from the layers working together.
After trying both switches: When presentation is removed, what still works? When custom JavaScript is off, what remains—and what visible result disappears?
Why this leads forwardThose responsibilities help us reject app ideas whose first version is too broad.
8 MIN
Screen 4 of 100:19–0:27
Round 1: Which first version is small enough to inspect?
The learner proposes a study platform with accounts, calendar sync, AI tutoring, social groups, grades, notifications, and analytics.
FEATURE WISH LISTaccounts · calendar · tutor · groups · grades · analytics
ONE USERa student with one unfinished task
ONE ACTIONchoose a time and build a plan
FIRST VERSIONone screen · three states
Which Topic 8 scope preserves the learning goal?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Packet revision: write one feature you removed and the exact user task that remains.
Why this leads forwardScope becomes defensible only when it is attached to a specific user task.
8 MIN
Screen 5 of 100:27–0:34
Read the user story. Can this interface answer it?
Compare: “Students need motivation” versus “A student with one unfinished task needs a three-step plan for the next 25 minutes.”
Which version is more buildable, what assumption does it make about the student, and what visible success state should the screen show?
1 · COMMITSketch or write your first answer before comparing.
2 · CHALLENGEAsk what user state, boundary, or evidence is still missing.
3 · REVISEKeep or change the design; name what changed your judgment.
Working alone? Write two plausible designs, challenge both with the same success rule, then choose one.
Course clarification
The second version names a user, task, time boundary, and inspectable output. It still assumes a three-step plan is useful; the wireframe should make that assumption reviewable rather than treating it as fact.
Why this leads forwardThe next screen converts that task into three interface states.
7 MIN
Screen 6 of 100:34–0:42
Your wireframe shows one screen. What is it missing?
Reveal the user journey. Each state needs a visible message and a possible next action.
1 · INITIALAsk for a task
Task: ______
Time: 15 · 25 · 45
Build my plan
2 · MISSING INPUTExplain + preserve
Enter a task to continue.
Time: 25 ✓
3 · RESULTShow + recover
Three steps · 25 min
Revise plan
After all three: What should remain on screen when the task field is empty but the student already chose 25 minutes—and why?
Why this leads forwardRound 2 asks students to place those states inside one labeled screen.
8 MIN
Screen 7 of 100:42–0:50
Round 1: Label the structure before styling it.
A wireframe records responsibility and hierarchy. It is not a beauty contest and does not require a drawing tool.
PAGE TITLE + PURPOSEStudy Sprint · plan one focused block
TASK INPUTRequired label + field
TIME CHOICE15 / 25 / 45 minutes
PRIMARY ACTIONBuild my plan
ERROR + RECOVERYSpecific message; preserve duration
RESULT REGIONThree steps + chosen time + revise/start-over action
Which missing label would most damage reviewability?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Why this leads forwardRound 2 tests the wireframe when the happy path fails.
8 MIN
Screen 8 of 100:50–0:58
Round 2: The user leaves the task blank. What should they see?
The user chooses 25 minutes, leaves the task blank, and presses Build my plan. The first draft silently does nothing. Keyboard focus means the control currently ready to receive typing or key commands.
Where should the error appear, what should it say, where should focus move, and what valid choice must remain?
1 · COMMITSketch or write your first answer before comparing.
2 · CHALLENGEAsk what user state, boundary, or evidence is still missing.
3 · REVISEKeep or change the design; name what changed your judgment.
Working alone? Write two plausible designs, challenge both with the same success rule, then choose one.
Course clarification
Place a specific message beside or immediately above the task field, connect it to that field, move focus or attention to the problem, and preserve the 25-minute choice. “Something went wrong” is not actionable.
Why this leads forwardA final scope decision asks whether the app needs generative AI at all.
8 MIN
Screen 9 of 100:58–1:04
Does this first version need a model?
Study Sprint can produce a transparent three-step template from a task and time choice. A model could add flexible language, but also adds variability, cost, privacy, and verification needs.
Does flexible generation create a specific benefit the transparent rule cannot provide?
NO OR NOT YETUse a transparent ruleExact mapping, predictable output, easy manual tests, no model dependency.
YES, WITH EVIDENCEBound the modelName the benefit, authorized input, variability, verification, privacy, and fallback.
What is the strongest Topic 8 decision?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Packet rule: for a transparent rule, write the exact input → rule → output mapping. For a model, name the necessary benefit and what a human must verify.
Why this leads forwardThe checkpoint preserves the decisions Meeting 2 will turn into a prompt contract.
6 MIN
Screen 10 of 101:04–1:08
Leave with a scope sentence and three-state wireframe.
This is a formative checkpoint. Complete missing fields during the protected buffer or after class; Meeting 2 uses the same seed.
One user + task
Include one removed feature.
Four responsibilities
HTML, CSS, JS, browser.
Three states
Initial, error, result + recovery.
AI fit decision
Transparent rule or justified model need.
Before leaving: mark one field that still needs evidence. No code, account, or live tool is required.
Why this leads forwardMeeting 2 converts the wireframe into a build prompt another person can critique.
4 MIN
Screen 1 of 100:00–0:06
Reconstruct the screen before writing the prompt.
A build prompt should describe the same user task and states as the wireframe—not silently invent a new project.
INPUTWhat the user supplies.
ACTIONWhat the user triggers.
ERRORWhat happens when input is missing.
RESULTWhat appears after success.
RECOVERYHow the user revises or starts over.
Turn to a partner: point to all five on your wireframe. Working alone? Point to all five on your own wireframe and write the one you cannot find. If one is missing, add a label before continuing.
Why this leads forwardThe nine-part contract adds an exact rule, constraints, and success checks to those visible states.
6 MIN
Screen 2 of 100:06–0:14
Build a contract you can test.
Build the contract from Study Sprint. Before each reveal, suggest that part’s answer; then compare the worked example.
1 · USER + TASKA student plans one focused study block.
2 · INPUTFictional task; choose 15, 25, or 45 minutes.
3 · ACTION“Build my plan” submits the inputs.
4 · RULEPrepare 2; work = total − 5; reflect 3.
5 · RESULTShow the task and labeled steps: 25 → 2 / 20 / 3.
6 · ERRORBlank/spaces: ask for Task, focus it, keep duration; no plan.
7 · ACCESSLabels, keyboard, readable contrast and mobile layout.
8 · BOUNDARYLocal only; no backend, accounts, keys, or private data.
9 · SUCCESS25 → 2/20/3; blank → recovery; revise to 45 → 2/40/3.
After all nine: Which three parts prevent “make it beautiful” from changing the project? Then adapt one worked part to your own seed; keep its state or test visible.
Why this leads forwardRound 1 tests whether a polished-sounding prompt actually specifies these parts.
8 MIN
Screen 3 of 100:14–0:22
Round 1: “Make a beautiful AI study app.” What is missing?
The sentence names neither user task, input, state, boundary, nor success check. “Beautiful” cannot repair missing behavior.
Which revision is strongest for the first build?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Packet revision: replace one adjective with a visible behavior or test.
Why this leads forwardRound 2 adds the state most vague prompts omit: what happens when input is missing.
8 MIN
Screen 4 of 100:22–0:30
Round 2: The prompt describes success. What else must it describe?
The prompt says what the successful result looks like, but says nothing about missing input, keyboard use, focus, or preserving valid choices.
What is the lowest-cost defensible addition?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Why this leads forwardStudents can now test the contract with paper, a course mockup, or an optional live prototype.
8 MIN
Screen 5 of 100:30–0:37
What is required in your submission, and what is optional?
Choose the route that answers one unresolved design question. The optional live route is a disposable client-only layout/state probe—not Topic 9 implementation. Tool access, polish, and generated code earn no automatic advantage.
DEFAULT · FULL CREDITPaper or typedWalk through initial, error, and result states with a partner or solo role-play.
COURSE MOCKUP · FULL CREDITStudy Sprint mapCompare labels, error, result, and recovery using the supplied example.
OPTIONAL · SAME CREDITDisposable probeUse fictional input to test layout and states only; no extra credit or Topic 9 replacement.
Record: the question tested, what the reviewer could or could not identify, and the one decision you changed.
Why this leads forwardThe critique protocol uses the same five questions for every route.
7 MIN
Screen 6 of 100:37–0:45
Read a classmate’s contract. What can you check — and what can’t you?
Reviewer: point to one visible requirement or missing state. Designer: defend it, then revise one field. Solo route: write both roles.
Can a reviewer identify the user, primary action, initial/error/result states, boundary, and success checks without inventing details? Which missing item would most change the first build?
1 · COMMITSketch or write your first answer before comparing.
2 · CHALLENGEAsk what user state, boundary, or evidence is still missing.
3 · REVISEKeep or change the design; name what changed your judgment.
Working alone? Write two plausible designs, challenge both with the same success rule, then choose one.
Course clarification
A strong critique names the exact missing field and its consequence. Missing error behavior or success checks often create the largest downstream ambiguity because the builder cannot know what failure or completion should look like.
Why this leads forwardA small source example now connects the design vocabulary to actual web responsibilities.
8 MIN
Screen 7 of 100:45–0:52
Return to Study Sprint: where does each visible decision live?
This is the source map behind the app used in Meeting 1. Read behavior from the interface into the source; syntax memorization is not assessed.
HTML + BROWSER
<label for="task">Task</label>
<input id="task" required>
<button>Build my plan</button>Meaningful controls, a required constraint, and native browser behaviorCSS
.error[hidden] { display: none; }
.result { border-left: 5px solid; }Presents the missing-input and result states without deciding the planJAVASCRIPT
invalid → showMissing()
submit → work = time − 2 − 3
→ render the planImplements the transparent rule, custom error, state preservation, and recoveryHUMAN DECISIONApprove the labels, 2 + work + 3 rule, recovery, accessibility, and whether the result is appropriate.
Where should “preserve the 25-minute choice when task is blank” be implemented and verified?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your reason, then revise one packet field.
Why this leads forwardThe external build-flow source now becomes a transfer exercise rather than a recipe to copy.
7 MIN
Screen 8 of 100:52–0:58
Watch a build flow—or use the equivalent course summary.
Andrew Ng’s DeepLearning.AI lesson is optional enrichment and may change. Students without video access use the same three course-created transfer questions for equal credit.
BEFORESpecifyUser task, visible states, boundary, expected result
DURINGInspectCompare actual behavior with the contract—not polish
AFTERRevise + retestChange the smallest difference and run the check again
Before viewing: predict which decision can be made before a build and which requires observed behavior.
After viewing or summary: name one observed difference you would revise, then state the retest.
Optional video: Build Your Own App In Just 30 Minutes! Full Course with Andrew Ng
Why this leads forwardThe packet records the design evidence whether students use the video, summary, paper, or optional live route.
6 MIN
Screen 9 of 100:58–1:04
Submit four pages of design evidence—not generated-code volume.
The preferred PDF, editable HTML, LMS text, DOCX/export, scanned paper, and approved accessible alternatives use the same evidence fields.
PAGE 1Route, scope, user task, removed feature.
PAGE 2Web map + initial/error/result states.
PAGE 3Labeled wireframe + AI-fit decision.
PAGE 4Prompt contract, critique revision, success checks, source transfer.
Scope: one one-screen concept, one primary action, and three states. No code, account, video, paid tool, model API, backend, or public deployment is required.
Why this leads forwardThe close preserves the exact inputs Topic 9 will turn into transparent interaction logic.
6 MIN
Screen 10 of 101:04–1:08
One task. Three states. One contract. Three tests.
Submit the packet before Topic 9 using the LMS calendar. Bring or recreate the same app concept in Topic 9 regardless of packet status.
App Design Packet
Preferred filename: Lastname-Topic08-AppDesign.pdf; maximum four pages.
No-video, no-AI route
Use the course summary, paper/text wireframe, and supplied source map.
Private data or access proof
No credentials, account/device screens, full chats, real records, API keys, or unnecessary identity evidence.
Topic 9 handoff: input → click/event → transparent rule → visible result → missing-input behavior → three manual tests.
Why this leads forwardTopic 9 implements and tests one transparent interaction from this design.
4 MIN