The delivery win was the structure: a stable shell that could scale, plus workflow steps that stayed usable on a phone. The dashboard is one route with query-selected sections. Each section is a panel with a clear contract and safe defaults.
- Stable dashboard route with deep-linkable sections (query-param driven)
- Training workflow that works on mobile: preview, pre-step, workout, summary
- Reusable UI primitives (cards, pills, spacing, button patterns) to prevent UI drift
- Backend-ready seams: safe defaults and predictable update paths
Clean-room excerpt: query-selected section
// clean-room pattern (simplified)
const section = (searchParams.get("s") ?? "workout").toLowerCase();
switch (section) {
case "vitals": return <VitalsPanel />;
case "meals": return <MealsPanel />;
default: return <WorkoutPanel />;
}Before the pilot, workflow state lived in spreadsheets and human memory. The product problem was not visual polish. It was operational reliability: reduce manual coordination, create a predictable navigation model, and make key steps completable on mobile.
- Manual tracking as the only source of truth
- Workflow dependency on trainer memory
- Desktop-first layouts that collapse on mobile
- Clear next action and minimal decision load
- Role separation (trainer vs client vs admin)
- Structured capture that produces usable outputs
Forward-looking note: the most realistic place for in-workout controls is the trainer surface (running a client). The client surface should stay lightweight: schedule, readiness inputs, and post-session capture. The demo includes workflow sequencing to prove UI contracts; the trainer build will own the execution controls.
The pilot shipped as a coherent system, not a pile of screens. That meant stable layout primitives, predictable navigation, and a workflow that stays simple under real usage.
One route, query-selected sections, and composable panels. This kept URLs shareable and prevented route sprawl as features grew.
Preview, pre-step, workout, summary. The sequencing reduces decision load and keeps state transitions explicit.
Reusable cards, pills, spacing rules, and button patterns. Panels render safely when data is missing and avoid dead-end states.
UI state is modeled with safe defaults and clear boundaries so placeholder data can be replaced without a layout rewrite.
Delivery was run through gated milestones. Each gate ended in a testable artifact with explicit pass/fail criteria, so stakeholders could validate progress without developer intervention. That reduced rework and kept scope controlled.
- Access and routing: users can enter and reach the dashboard reliably
- Deep links: sections are selectable by URL and remain stable on refresh
- Workflow: sequencing is completable on mobile without layout breaks
- State safety: missing data renders with safe defaults, not broken panels
- Mobile-first build order: phone constraints first, then scale up
- Reusable primitives over one-off CSS
- Stable routing conventions and predictable navigation rules
- Acceptance criteria written as implementable UI contracts
The platform value is in structure: stable shells, composable panels, predictable navigation, and UI guardrails. Below are concrete examples of what that means, with short clean-room excerpts.
One stable dashboard route and a query parameter selects the section. This keeps URLs shareable and prevents route sprawl.
Clean-room excerpt: resolve section
// clean-room pattern (simplified)
const s = (searchParams.get("s") ?? "workout").toLowerCase();
const Current = Tabs[s] ?? Tabs.workout;
return <DashboardShell active={<Current />} />;Each section is its own component with a stable contract. You add a panel without rewriting the shell.
Clean-room excerpt: shell composition
// clean-room pattern (simplified)
export function DashboardShell({ active }) {
return (
<Shell>
<Nav />
<Main>{active}</Main>
<RightRail />
</Shell>
);
}Guardrails mean the UI does not break when values are unknown. It renders stable layout, safe defaults, and clear fallback copy.
Clean-room excerpt: fallback values
// clean-room pattern (simplified)
const value = apiValue ?? 0;
const label = apiLabel ?? "Not available yet";
return <StatCard value={value} label={label} />;Primitives are reused to keep the product cohesive. This is maintainability and delivery speed under changing scope.
This embedded demo is clean-room. It demonstrates UX structure and workflow behavior without proprietary training logic. If you only click one thing, click the workflow links.