← Independent product builds
StudyOps
A student operations prototype that connects what must be learned with when the student is actually available, what is already complete, what remains uncertain and what deserves attention next.
- Role
- Product strategy, UX architecture and prototype build
- State
- Release 1 interactive prototype
- Proof
- Functional interactive prototype
01 Problem
Why this deserved a product
A student’s study plan is fragmented across school timetables, tuition, syllabus completion, exams, doubts and limited self-study capacity. Most planners record tasks but do not model that operating reality.
Product decision
Before claiming to “detect” backlog or risk, make the input model explicit: syllabus, timetable, tuition, study blocks, completion signals, doubts and exam timing must form one coherent system.
02 Product mechanism
How the system behaves
The useful part is the operating sequence—not the screen alone.
- 01
Capture syllabus structure and progress at topic level.
- 02
Combine school, tuition and personal study commitments.
- 03
Surface today’s actions without hiding the underlying plan.
- 04
Carry doubts, confidence and incomplete work into future planning.
- 05
Preserve state locally for a realistic interactive prototype.
03 Product tensions
Trade-offs made explicit
Each build is a negotiation between competing forms of value.
04 Working surfaces
Screens from the build itself
Real product surfaces are included where public sharing is possible.
These screens show the current product state being referenced on this page. They support the product record but do not, on their own, claim user or business outcomes.
05 Build and evidence
Technical surface
Stack
ReactViteTypeScriptReact RouterlocalStorage
Current proof position Functional interactive prototype
The evidence below separates implemented product state, supporting artifacts and proof that is still pending.
Evidence ledger
What exists, what it supports and where the claim stops.
Verified state Available artifact Planned proof
Working prototype Verified state
Release 1 application flows
- Claim supported
- The concept is navigable and stateful across the main student-planning surfaces.
- Evidence detail
- Today, Syllabus, Calendar, Doubts, Tuition, Mission, Capture, Settings and About routes are implemented in the frontend prototype.
- Source
- React application and local browser verification
Product artifact Available artifact
Input and communication model
- Claim supported
- The product mechanics account for how syllabus, schedules, completion and uncertainty enter the system.
- Evidence detail
- The story map, Data Input & Communication Spec, demo scenario, UX specification and technical build specification define the operating model.
- Source
- Product specifications and implementation checklist
Interaction evidence Verified state
Persistent demo state
- Claim supported
- The prototype supports repeated use rather than resetting on every route change.
- Evidence detail
- Local persistence, demo-time changes and reset behaviour were exercised during phased interaction QA.
- Source
- Browser tests and state-hardening passes
Outcome evidence Planned proof
Student validation and computed workload
- Claim supported
- The product still needs evidence that the input burden is acceptable and the planning model improves student decisions.
- Evidence detail
- A longitudinal student demo, usability findings and a computed study-capacity model are the next proof layer.
- Source
- Planned validation study
06 Release trail
From intent to working state
A build becomes credible through the sequence of decisions it survives.
- 01 Product logic reframingComplete
Manual-input dependency, cold start and risk-model gaps were made explicit.
- 02 Release 1 specificationComplete
Story map, input model, UX spec and technical build plan completed.
- 03 Interactive frontendComplete
Core routes and local state behaviour are functional.
- 04 Interaction and state hardeningActive
The build is being tested against realistic states and recovery paths.
- 05 Student validationNext
Usability and longitudinal planning evidence remain pending.
07 Current state
Where the product is now
Release 1 frontend prototype is functional; the current focus is interaction QA, state hardening and validating the input burden with realistic student scenarios.
Next evidence to add
- 01One-student longitudinal demo
- 02Usability test findings
- 03Computed study-capacity and exam-load model
Continue exploring