Every screen, every state, every route through Lightkeepers.

The five actors

Who can be on the other side of the screen, and what lets them in.

The fact that shapes every wireframe

Get this wrong and half the screen designs are wrong with it.

Journey A. Visitor to signup

The free side. Fully built, and the most finished part of the product.

The nine steps

Four things already broken here

The /start copy promises "six quick questions" for a nine step wizard. The progress bar is calculated so step 9 reads 88.9 percent and never reaches 100. Step 9 collects a learning style that gates the final button and is then never shown on the plan. And the state content file is flagged as a draft that no page may render from, while all three public surfaces render from it today.

Journey B. Signup to a generated term

The funnel that decides whether anyone ever sees the product working.

The seven states of the hub screen

The build screen is already good work. It shows a per block checklist, one row per subject and week, each pending, building or done. A flavour line rotates every six seconds and is seeded with the child's own interests. It reassures the parent that closing the browser is safe, and it surfaces an early "first lessons are ready, start now" callout before the whole term finishes.

Two approvals, one dead end

A term plan reaches a parent through two gates. Staff move it from draft to vetted in the admin queue, then the parent moves it from vetted to live by approving it. A plan sitting at draft shows the parent "awaiting review" with no action, no timeline and no way to nudge it. Worse, the dashboard reads that same state as "no plan" and tells them to generate a term they already have. Two screens describing reality differently is the single worst moment in the product today.

Journey C. The child's daily loop

Parent hands over the device. Everything from here is designed for a kid.

Answers save themselves

Questions are detected from the lesson markdown in five different ways, so the field layout varies by lesson. Each answer saves 800 milliseconds after typing stops and immediately on blur, with a saving, saved or could not save status line. Worth knowing for the wireframes: a parent viewing a lesson gets read-only fields. Only a child mode session can write.

Ask Sarah

A fixed bubble, scoped to "about this lesson only", 300 characters per question and twenty questions per lesson per day. The question is stored, an external service answers it, and the page polls every three seconds for up to a minute showing a thinking bubble, then a graceful apology if nothing arrives.

One honesty problem

Locked nodes on the quest map are still ordinary links, and nothing on the server stops a child opening a later lesson directly. The only real sequencing lock in the product is the step accordion inside a lesson. Either enforce the lock or stop drawing padlocks.

Journey D. Parent oversight

The half of the product a parent pays for and a child never sees.

Dashboard /app

A greeting band that changes on this week's actual progress, a conditional onboarding nudge, a compliance-due card that appears within sixty days of a deadline, a single "today's quest" next action, per child progress with pace pills and week dots, then the child cards. It polls for attention signals every forty five seconds and shows a "needs a look" badge, where a signal means a flagged Sarah message or a lesson finished with low confidence in the last fortnight.

Work review /app/work/[id]

Read only, grouped by subject then week, newest first. A summary strip counts lessons done this week, average confidence this term, lessons worth revisiting and Sarah questions asked. Each lesson expands to show exactly what the child wrote and the full Sarah thread. Printable per lesson, per week or all at once.

Compliance documents /app/documents

Journey E. Admin vetting

Deliberately minimal. The team's own words: anything else is a job for the database console.

The queue lists term plans filtered by status. Opening one shows every lesson with its eval flags as raw JSON, plus a table of generated assets. The reviewer has exactly one lever: a status dropdown and an update button. There is no per lesson approve, reject or edit, so a reviewer who dislikes one lesson out of forty must reject the whole term or let it through. The generation request list is a read-only monitor with no retry, and the household list has no edit controls at all.

Screen inventory

Thirty two routes across six surfaces.

Where one route is really five designs

Thirty two routes, but roughly sixty distinct things to draw.

Gaps and openings

Ranked by how much they hurt a real person using this today.

Suggested wireframe order

In the order a user meets them, with the two compounding screens pulled to the front.

1. The child hub, all seven statesIt is the junction. Everything routes through it.
2. The lesson, all nine statesIt is the actual product. Get this right and the rest follows.
3. The dashboard, five statesThe parent's home base.
4. Onboarding and add child, seven stepsThe funnel that decides whether anyone reaches a term at all.
5. Quest map and the badge systemThe delight layer, and there is already staged art to work with.
6. Work review and compliance documentsThe parent's reason to keep paying.
7. Public side and the nine step wizardAlready the most finished part of the product.
8. AdminFunctional is enough.