People are slower and often more error-prone immediately after switching tasks, and preparation reduces but does not remove that cost.
Monsell, Trends in Cognitive Sciences, 2003Back to work
Functioning iOS prototype
Time Anchor
Working SwiftUI system for adaptive planning, check-ins, reminder routing, and variable-capacity days.
Adaptive execution supportVariable-capacity days
- Observe
- Infer
- Intervene
- Learn
Users don't fail because they forgot the plan.
They fail during starting, transitioning, recovering, and adapting.
BuiltSwiftUI app
Adaptive planning engine, reminder routing, SwiftData persistence, tests, and simulation checks.
StrategicPrivacy-first benefit model
Employer-sponsored access without exposing individual calendar, health, task, or check-in data.
Core loopCapacity -> cue -> correction
Check-ins change support mode; cues route to action; corrections are captured for future planning logic.
Problem
Most planners assume that once a plan exists, the user can execute it. Time Anchor explores what a planner should do when attention, energy, transitions, and recovery change throughout the day.
Why this matters
Users do not just forget tasks; they lose the ability to start, switch, recover, or choose the next move under pressure.
Transitions and recovery periods are often where a plan collapses, even when the calendar is accurate.
Static plans punish variable capacity. The useful system is the one that adapts without making users decode the adaptation.
Design challengeHow might a planner reduce execution friction instead of simply organizing information?
Research basis
This is a documented cognitive problem, not just a planner preference.
Cross-national survey research estimated adult ADHD prevalence at 3.4%, with measurable role disability and low ADHD-specific treatment.
Fayyad et al., British Journal of Psychiatry, 2007Time Anchor treats planning as an execution-support problem: starting, switching, recovering, and adapting when capacity changes.
Applied product framingSystem model
Observe -> Infer -> Intervene -> Learn
01
Observe
Missed starts, ignored cues, calendar pressure, capacity check-ins, and health context.
02
Infer
Drift risk, overload pressure, transition friction, recovery need, and commitment pressure.
03
Intervene
Cue adjustment, anchors, simplified plan modes, transition support, and recovery mode.
04
Learn
A future-facing path for reminder timing, support tone, event relevance, and anchor behavior.
Process artifacts
The product logic is the visual story.
I treated this as an execution problem, not a calendar problem. The design work focused on where a day breaks down: the moment before starting, the handoff between activities, and the recovery point after a plan stops matching capacity.
Morning upkeep
Focus block
Recovery
Shutdown
01Observe
02Infer
03Intervene
04Learn
Flagship scope
What is built, what is strategic, and where the boundaries are.
Built prototype
- SwiftUI iOS app with support-profile onboarding.
- Manual capacity check-ins and health/context inputs.
- Tasks, routines, fixed events, anchors, and adaptive planning modes.
- Reminder routing into the relevant task, routine, transition, or wrap-up state.
- Engagement tracking, SwiftData persistence, legacy migration, tests, and simulation checks.
Strategic extension
- Employee wellbeing benefit access model.
- Aggregate adoption and self-reported usefulness reporting.
- De-identified usage trends only with explicit privacy boundaries.
Scope boundaries
- Clinical outcomes are outside the current product scope.
- Employer-sponsored access would exclude individual calendar, health, neurotype, task, and check-in data.
- Correction capture is framed as a future planning input, not a fully automated behavior change.
Three adaptive days
The demo scenarios test whether support can adapt without becoming generic.
Jordan Carter
Need: Reduce household coordination load without becoming the family reminder system.
App response: Shared commitments, reminder handoffs, family anchors, and clearer responsibility boundaries.
Sara Anderson
Need: Predictable co-parenting support with uncluttered, low-stimulation structure.
App response: Fixed commitments stay separate from flexible tasks, so childcare constraints do not become fake to-dos.
Alex Rivera
Need: ADHD time awareness across school, work, parenting, and commute transitions.
App response: Buffers, current action, next fixed commitment, leaving countdowns, and tomorrow preview.
Real app states
The newer screens make the product feel operational instead of conceptual.
Journey evidence
Alex's morning failures clustered around time estimation, transition friction, and leaving.
Today overview on unlockVisual countdownsMicro-task promptsADHD buffer timeTomorrow preview
Trust model
The B2B extension only works if the employee remains the user and owner of the data.
Employee
Personal plans, reminders, check-ins, routines, health guidance, and insights.
Employer
Aggregate adoption, retention, and self-reported usefulness. No individual behavioral data.
Benefit partner
De-identified usage trends and opt-in outcomes.
Manager
No access to tasks, calendar events, health data, neurotype, check-ins, late starts, or recovery patterns.
Validation plan
The next test is whether the system helps people act, not whether the screens look complete.
Can users identify what to do now within five seconds?
Do reminders help users start tasks instead of only alerting them?
Do wrap-up reminders help users leave hyperfocus?
Are anchors understood as day chunks rather than events?
Is the privacy boundary understandable in an employer-sponsored version?
Feedback loop
Support changes when the current cue misses.
01Current state
02User ignores cue
03What felt off?
04Future support adapts
What shaped the system
Support needed to adapt without becoming another task.
Use anchors instead of a flat task list
Problem: A long task list increases ambiguity when the user is already overloaded.
Decision: Group the day into meaningful execution blocks such as morning setup, focus, recovery, and shutdown.
Rationale: Users often need to know what mode they are in before they can decide what task comes next.
Tradeoff: Less granular than a full calendar, but easier to act on during high-friction moments.
Separate events from tasks
Problem: Imported calendar events can become fake tasks if the interface treats everything as the same object.
Decision: Keep fixed commitments visually and semantically distinct from executable work.
Rationale: The system should protect what cannot move while reducing pressure around what can change.
Tradeoff: The data model has to carry more context about each item, but the user gets a clearer day map.
Make explanations optional
Problem: Adaptive logic can create more cognitive load if every reason is visible at once.
Decision: Lead with Now, Next, and Day Map; move system reasoning into a secondary Why layer.
Rationale: The interface should help the user act first and understand the system when they need to.
Tradeoff: Some intelligence is less visible, so trust has to be built through consistency and recoverable choices.
Design walkthrough
How the prototype responds when the plan stops matching the day.
Support profile
Captures support preferences, neurotype context, reminder posture, and sensory cue preferences.
User problem
Avoids treating neurodivergence as one default mode.
Design response
The framing moved from diagnosis-first to support-pattern-first.
Capacity check-in
Lets the user update energy, stress, sensory load, transition friction, and recovery need.
User problem
Gives the planner a way to respond when the day no longer matches the original plan.
Design response
Manual check-ins stayed first-class so the concept does not depend on wearable data.
Today execution surface
Prioritizes what is happening now, what is next, and what the day is asking from the user.
User problem
Reduces the uncertainty of deciding where attention should go.
Design response
The hierarchy was tightened around Now / Next / Day Map / Why after critique.
Correction capture
Records feedback such as too early, too late, too intense, not relevant, or already moving.
User problem
Creates a path for the system to stop repeating support patterns that miss the user's actual state.
Design response
Corrections are designed to eventually feed planning signals into future iterations, rather than being treated as isolated UI edits.
Research / testing
Evaluate whether the concept reads as execution support rather than another calendar, and whether adaptive logic can remain understandable.
Method
Prototype critique, scenario review, persona walkthroughs, and implementation-level checks against planner behavior.
Findings
- The strongest product story is adaptive execution support, not task storage.
- Events and tasks must remain separate or the planner becomes noisy.
- The day's main action needs to be visible before support copy or explanation.
- Adaptive behavior needs an explanation layer, but that layer should not compete with the immediate next action.
Design response
The case study and prototype now emphasize anchored day structure, a clearer Now/Next hierarchy, support transparency, and correction capture as a future planning input.
Outcome
Working SwiftUI prototype with adaptive planning modes, check-ins, reminder routing, anchors, SwiftData persistence, and a privacy-first strategic extension.
Reflection
What this project sharpened.
The strongest part of Time Anchor is the reframing: planning is not finished when the schedule is created.
The next iteration should test whether users trust adaptive changes when the explanation is available but not forced.
Designing for cognitive variability requires restraint; too much visible intelligence can become another task.