webapp Case study
Adviser Education System
Advisers were running student planning in calendars and spreadsheets, which handle appointments well and handle a study plan badly. A plan is not a series of events; it is a structure with dependencies, revisions and a record of what was actually completed.
The business problem
Generic scheduling tools model time, and adviser work is about progress against a plan. Forcing it into a calendar loses the things that matter: which plan a session belonged to, whether the student is ahead or behind, and how the plan changed after the last review. Advisers were reconstructing that from memory and notes each time.
What I delivered
- A platform where student profile, study plan and progress are first-class objects rather than metadata attached to appointments.
- Plan revision history, so an adviser can see how a plan changed and why rather than only its current state.
- Progress tracked against the plan, which is what makes ahead and behind meaningful terms rather than impressions.
- An adviser-centred workflow, since the person operating the system daily is the adviser and not the student.
- A structure that can grow with the practice without becoming difficult for the people running it.
Technical approach
- The domain was modelled before the interface. Profile, plan and progress are separate things with separate lifecycles, and collapsing them is what makes generic tools unsuitable here.
- Plan changes are recorded as revisions rather than edits, because the question an adviser asks is usually what changed since last time.
- Progress is measured against the plan rather than against a calendar, so a student who is doing the work in a different order is not reported as behind.
- The design follows the adviser's daily workflow, which is where adoption is decided.
Result and evidence
Advisers work from student plans with real progress state and a revision history, rather than from a calendar plus their recollection of the last conversation.
Commercial value
The adviser's time is the product being sold. Anything that removes reconstruction work at the start of each session goes directly to capacity.
Readable implementation brief
implementation_brief {
project: "Adviser Education System"
domain: "student profile / study plan / progress, modelled
as separate first-class objects"
not: "a calendar with metadata attached"
plans: "revisioned, not overwritten"
progress: "measured against the plan, not against dates"
audience: "built around the adviser's daily workflow"
}What this project shows
The judgement here was recognising that this is a domain modelling problem rather than a scheduling one. Getting that wrong at the start is expensive to correct later.
Recording plan changes as revisions rather than overwriting them is a small decision that turns out to answer most of the questions advisers actually have.