Design a clear interface · practice project
Turn a visual reference into a usable, consistent product.
Guide practice project · 2 named conversations · shared project files
Import creates your private copy without running code, installing tools or granting access. Update Helios if this link is not recognised; the ZIP works independently. Native and engine starters require their SDK/editor and have not been built on your device. These conversations are authored examples, not real execution logs.
One project, separate conversations
The first conversation owns the brief and initial decisions. The second reads the handoff and owns review, testing and revisions. Both use the same files; splitting the conversation does not duplicate the project.
Brief and decisions · Design a clear interface
Alex · fictional learner
Design a compact notes app with a quiet warm theme, a clear list and one obvious Add note action. Include empty, loading and error states. Support 360px width and keyboard use. Show long titles and at least 20 notes.
Helios · sample response
We will keep this exercise scoped to Turn a visual reference into a usable, consistent product. I will record decisions in BRIEF.md and hand the review to a separate conversation using HANDOFF.md.
Alex · fictional learner
Keep the first version small. Make the checklist explicit, and record what still requires my device or account rather than claiming it has been tested.
Helios · sample response
The shared files contain the example material and a checklist. Start “Review and next revision · Design a clear interface” for independent checks; it should read BRIEF.md and HANDOFF.md before changing anything.
Review and next revision · Design a clear interface
Alex · fictional learner
Continue from “Brief and decisions · Design a clear interface”. Read BRIEF.md and HANDOFF.md. Review the result against the guide, then propose one small revision.
Helios · sample response
My review scope is separate from the initial design: List screens and states: empty, loading, normal, error, success and permission denied. I will use TESTING.md, keep findings in notes.md and distinguish observed results from checks still to run.
Alex · fictional learner
Add a clear recovery step for when the first attempt fails. Keep the original brief unchanged so we can see what changed.
Helios · sample response
The next-revision note asks for a recovery step and records the handoff. These are authored examples, not execution receipts. Run the listed checks in your copy before marking them passed.
Shared project files
- index.html
- BRIEF.md
- HANDOFF.md
- TESTING.md
- notes.md
- REFERENCES.md
- reading-room.html
- README.md
- walkthrough.json
Start with README.md and HANDOFF.md. Keep observations in notes.md and actual test results alongside TESTING.md.
Try the preview
Open preview separately ↗Authored project log
First conversation records the scope and shares BRIEF.md.
A separate named review conversation uses the same files and records checks in TESTING.md.
The fictional learner asks for a failure-recovery step; notes.md preserves the next action.