Where a candidate starts
The work at a glance
- My role
- Product designer
- Scope
- Placement challenge · full flow, edge cases
- Built in
- 3 days · Claude, no Figma file
How it came together
-
01
Read the brief and never opened Figma.
-
02
Gave the model its constraints before any generation.
-
03
Built it in VS Code, live on Vercel in three days.
-
04
Corrected what the model got wrong for first-time users.
I wrote the constraints first and the markup second
Three decisions made the prototype usable. The rules, the first run, and the recovery.
When the placement PRD landed I did not open Figma. I built a custom Claude skill encoding Scaler’s design system — components, spacing, the mascot toolkit — so anything generated came out inside the system rather than next to it.
Then I wrote an implementation-plans.md translating the learner-facing requirements into a flow: category order, what happens on a wrong answer, when a correct count carries forward, when a category closes.
I sketched that flow myself first, then let Claude build it out against those constraints — straight into a working prototype the front-end could pick up directly. Full flow, edge cases included, in three days.
## Challenge rules ### Category order - Easy, then Medium, then Hard. Fixed. - A category opens only once the one before it closes. ### On a wrong answer - The miss is not graded and not deducted. - Route into Practice Mode, same interface. - Practice is required, not offered. No skip. ### What carries forward - Every correct answer already banked stays banked. - The correct count carries across the practice detour. - One miss still clears the round. ### When a category closes - Threshold met -> close it, unlock the next. - Six tries spent -> the attempt ends here.
The rules existed before the code did. I decided the edge cases; Claude only carried them out.
The first pass Claude generated assumed a returning, already-familiar user. It dropped candidates straight into Contest Mode with no onboarding at all.
That is a reasonable default for a model working off a PRD written for someone who already knows the product. It breaks for the actual audience: a candidate hitting this cold, for one company, once.
I caught it and rebuilt in a first-time-user experience — the rules screen, the mode explainer, the ‘you cannot skip this’ framing — before any contest question loads.
The harder problem was not the state logic. It was managing how a learner feels at the exact moment they fail, under a timer and a camera.
A wrong answer routes into Practice Mode, but I kept it in the same interface rather than a separate space, framed clearly as ‘not graded’ rather than a step down.
Right at that transition — the moment most likely to spike anxiety or make someone want to quit — the copy says it directly: you keep the answers you already got right, your contest progress is safe. And the way back is never ambiguous; a ‘Continue’ or ‘Back to Contest Mode’ always tells the learner exactly when they are clear to resume.
The conditions the learner has agreed to before the first question. Timer and camera on.
Four screens that keep one promise
A wrong answer never takes away a right one. One miss still clears the round.
Practice changes nothing in the real test, but the detour after a wrong answer is not optional.
The same editor, no camera. Practice uses different questions, so rehearsing costs nothing.
Each detour spends one of six tries. Spend the last and the attempt ends here.
A PRD on one side and commits on the other
The document set the behaviour; the repo holds every decision that followed it, one commit at a time.
The PRD is not mine. It defines the state machine, the thresholds and the proctoring rules, and this entry treats all of that as fixed. The design work is everything the document leaves open, which is what a first-time candidate sees and what happens the moment they get one wrong.
Each change is a scoped commit against a written spec, so a decision like ‘cut the landing page’ or ‘rewrite both instruction screens in plainer English’ is a reviewable diff rather than a redraw.
What this entry was testing
Can a design system be written down tightly enough for a model to build to it?
Components, spacing and the mascot kit went into a Claude skill. What came out matched the system.
Is writing the rules better than asking for edge cases?
Writing the rules down first meant I decided the edge cases and Claude only carried them out.
Where do a model’s defaults quietly miss the real audience?
At the start. It built for someone returning, because the brief was written for one.
Can you design how a moment feels while working in code, not screens?
It reads right to me, but no nervous candidate has met it on a live timer yet.
