Show only what's current. Hide everything else.
Most productivity tools assume more visibility leads to better decisions. They give users hierarchies, projects, tags, filters, custom views. For users in interrupted contexts (anyone who gets pulled away every five minutes), those tools quietly fail. The visibility itself becomes the problem.
I designed and built Focus to test the opposite hypothesis: that radical hiding, applied as a system, would produce more shipped work than any amount of customization.
The architecture is a funnel. The full task universe lives in Backlog, hidden by default. Weekly planning pulls a subset into This week. Daily planning pulls a smaller subset into Immediate, capped at five to seven tasks. Each step makes a smaller scope visible. Each step is a choice the user only makes during planning, never during execution.
Backlog
18 tasks · hidden by defaultThis week
6 tasksImmediate
3 / 5The user
Working parents are the productivity industry's blind spot. The dominant systems (GTD, Todoist, Notion, time-blocking) were designed by and for users with a specific set of conditions: predictable schedules, two free hands, protected focus blocks, and the ability to spend 30 minutes a day on system maintenance.
Working parents have none of those.
A working parent's day is interrupted by definition. They lose hours to context switching that's not optional. They often have one hand occupied. Their focus blocks are 20 minutes long, not two hours. And they don't have 30 minutes a day to maintain a productivity system. That's the time the system is supposed to give back.
Across research and observation in this segment, one pattern dominated: roughly 60 minutes per day spent deciding what to work on before any work began. The bottleneck wasn't time management. It was decision management under interruption, and every existing tool was making it worse by exposing more options, not fewer.
Why existing systems fail this user
Each major productivity system fails users in interrupted contexts in a specific, testable way:
| System | Why it fails |
|---|---|
| GTD | Requires 30+ minutes of daily processing. That's the time the system is supposed to give back. |
| Todoist / TickTick | Endless lists create decision paralysis; the inbox itself is the problem |
| Time-blocking | Assumes predictable, protected blocks of time that don't exist |
| Notion | Infinite customization invites infinite procrastination |
| Eat the Frog | Closest to working, but breaks down with parallel projects |
| Day theming | Assumes control over when things happen |
The pattern across failures is the same: every system requires users to do work to use the system. Maintenance, customization, decision-making about the system itself. For users in interrupted contexts, that overhead consumes the time the system was supposed to free up.
The opportunity was a system with built-in constraints, near-zero maintenance, and an architecture designed for unpredictability rather than in spite of it.
Three design decisions
I prototyped on paper first. Validated the constraint mechanic before writing any code. Then built the system around three decisions, each of which is, at its core, a decision about what to hide.
1. Hard task limit (1–7 in immediate view)
The system blocks the user from adding task #6. They literally cannot, until something is completed or moved out.
This forces prioritization at planning time, not at execution time. The decision the user used to make every morning ("which of these 47 tasks do I start with?") gets pre-made by the system.
What's hidden: every task that didn't make the cut. What the user gains: zero decision overhead during execution.
Try it: drag a task from This week into Immediate. The system blocks it at the 5/5 limit. Complete a task to free a slot, then try again. Tap the target icon to enter focus mode and hide everything but Immediate.
Immediate
This week
2. Three sections, with planning separated from execution
The system has three sections, no projects, no hierarchies, no tags as primary structure:
- Immediate: what you're working on now
- This week: what must happen this week
- Backlog: everything else
What's hidden: the tree-shaped mental model of every other task system. What the user gains: a flat, scannable view that takes seconds to read.
The system has two modes. In Planning mode (10 minutes daily, 30 minutes weekly), the user sees all three sections and drags tasks from Backlog into This Week or Immediate. In Focus mode (used during execution), only Immediate is visible. This Week and Backlog are hidden so nothing competes for attention. The interface offers nothing to fiddle with mid-task because there is nothing else on screen.
Try it: toggle between Planning and Focus. In Planning, drag tasks between sections (the Immediate limit still applies). In Focus, only the active task list remains, and tasks become checkboxes.
Immediate
2/5This week
Backlog
Supporting decisions
Several smaller decisions support the two constraints. Each one applies the same logic: hide something the user doesn't need to see right now.
| Design decision | What it hides | What the user gains |
|---|---|---|
| Hidden-but-accessible backlog | Visual noise of every uncommitted task | Nothing gets lost; nothing demands attention |
| Tag-based capture from anywhere | The need to switch tools to add a task | Stay in flow while still capturing |
| Monthly completion archive | The shame of an empty-looking list | Visible proof of progress without inflation |
| Voice and one-handed input modes | The assumption of a keyboard-and-desk setup | Capture works in real-life conditions |
The most important supporting decision is the hidden-but-accessible backlog. The full task list is one tap away during planning, and gone from view during execution.
When the user is in Focus mode, the backlog is not minimized or collapsed in a panel. It is not on screen at all. The interface offers no opportunity to wander into it.
The build
The platform is designed across multiple surfaces from a single data model. The PWA (React, TypeScript, Vite, Tailwind) is the primary build and what's currently in beta. Three companion clients are in progress: a Mac desktop app (Tauri), an Amazfit watch app, and a Chrome extension. The backend is Supabase with row-level security policies and realtime sync, designed for team workspaces with task delegation between users.
The architecture follows the same principle the UI does. Each platform exposes only what makes sense in its context. The PWA shows the full system. The watch will show the current task and the next one. Chrome will offer quick capture. None of them will show everything.
The PWA is currently in private beta with a small group of working parents and small-team users. They're the same audience the design decisions were made for.
Validation
What's been validated about the principle:
What's currently in test: the multi-platform build itself, with beta users. Tracking adherence, weekly task completion, and self-reported decision overhead. Initial signal is consistent with the single-user data, but I'm holding the platform-level numbers until the cohort is large enough to mean something.
What's next: a structured study with 20–30 working parents to extend problem validation beyond the segment I've reached so far, plus a controlled comparison against unconstrained task lists to isolate the effect of the constraint mechanic.
Where this principle goes next
The same principle (show only what's current, hide everything else) generalizes well beyond personal productivity. Internal dashboards, admin panels, and operational tools all suffer the same failure mode: they expose every option to every user at every moment, on the assumption that visibility is power.
I'm currently applying the principle to a beta-tester engagement platform: an internal tool that shows each tester only what's actionable to them right now, hides the firehose of program-wide activity, and uses motivational structure rather than incentives to drive participation. The hypothesis is that radical hiding, applied at the workflow level, can produce substantial engagement gains without relying on incentive escalation.
That case study lands when the test does.