One task, already chosen, with the reason in plain words. Everything else on the plate is one quiet line underneath.
Concept to deployed prototype
Methods
Double Diamond
Persona, journey map
Interviews, forum research
Crazy 8s, SCAMPER
Jobs to be done
Usability testing
Objectives
Reduce decision fatigue at peak load
Surface one clear next action
Prove the concept as a working prototype
Role
UX / Product Designer
Researcher
Team
Individual
Duration
7 weeks
Production tools
A focus tool that works by hiding your work.
Every task tool answers overload with more visibility. The research pointed the other way.
The problem
At peak chaos, task tools fail at the very job they were created to do.
When work arrives from every direction at once, capable people lose time to one thing: Choosing what to do next. It isn't a discipline problem. Under enough pressure, the tool meant to help and the mind meant to choose give out at the same time.
An average professional's day, in four panels: Composed, First pings, Pile-up, Overload.
"When I hit peak overload, having a view of all my tasks overwhelms me more."Interview participant
What popular task tools show at that moment:
More visibility is the answer most tools give. At peak pressure, it's the wrong one.
What research found
Two sources, one collapse.
Four professionals walked me through a real workday. Productivity forums showed hundreds more describing the same breakdown as it happened. The two groups started in different places and broke down in the same order.
4In-depth interviews: Implementation, account, marketing, and founder roles
5Stages in the same breakdown, repeated across forum threads
1Fix everyone invented on their own: Narrow to one thing and shut the rest out
Initial setup
Backlog builds
System overload
Forced narrowing
Disengagement
Nobody quit their tool because it lacked a feature. They quit to stop seeing the list.
Intervention needs to step in here, before the low point
Sam's day, from the journey map. Sam is the persona built from the four interviews. What tips people over differs (volume for some, interruptions for others); the low point doesn't. Output followed the curve, and neither fully recovered.
The productivity bottleneck isn't workload or features. It's decision paralysis under pressure.
HMW
How might we help professionals decide what to do next when cognitive load peaks?
The question every design decision below was tested against.
The solution
Q models the natural defence mechanism against overwhelm: It cuts the noise and locks onto one task.
But unlike a stressed mind, Q stays sharp — prioritising your most urgent work based on three concrete criteria.
At peak load, Q steps in:
BYhiding the list
BYshowing you one task
BYprotecting your focus
NOlong lists
NOfeature clutter
NOdistractions
Q never takes control: The full list stays one click away. And it picks with three plain rules, not AI — can I start it now, is it due soonest, are others waiting — so anyone can check the pick at a glance.
Try it: Twelve tasks, one decision
The prototype's real task list. Switch Q on, then ask for a different pick.
12 tasks on your plate
Here’s where to start.
Tools
Recalculating…Here’s what’s next.
How Q shows up
Q finds you mid-work. You never have to go looking for it.
Email, chat, a spreadsheet, and a ticket queue, all pinging at once. Four switches in twenty minutes, nothing finished. That pattern is Q's cue: it appears as one small prompt and waits for Sam to say yes.
Concept animation, built in code with the app's real screens. A browser can't see other apps, so the live prototype simulates this moment with a timer. The desktop version is the next build step.
Five states, each one from research
Every state exists because a participant described needing it.
Step through Sam's day. Each screen is from the working app, next to the interview quote that created it, and the design decision behind it.
P
Decision
Reason
Testing and iteration
Two rounds of testing. Three fixes that changed the product.
Every change started with something a participant said or stumbled over. Each fix had to pass one test: more freedom, without putting the whole list back in front of them.
Round 1
"Why are these two numbers different?"
Before"5 in the queue" next to "16 in the list" read as a bug.
After"Narrowed from the 16 on your plate." The narrowing became the point.
Round 2 · Caught a Round 1 fix
The fix that was too good.
BeforeRound 1 made the list clickable, so leaving mid-flow wasn't a dead end.
AfterRound 2 showed the list had become the way back in. Now it stays closed, and "Suggest a priority" brings you back to Q.
Testing the fix caught what testing the design didn't.
Round 2
A number in Focus.
Before"3 held · quiet." A count invites checking.
AfterA lock and one word, "Quiet". Only a task that outranks the current one interrupts.
Also shipped: "Suggest another" kept to one alternative, not a menu · "View all tasks" demoted to a quiet link · "All clear" doesn't hide the bell list showing what came in · A home headline that tracks progress · A one-time tip to turn on Do Not Disturb.
What's next
Three things the next version should carry.
AI, starting with sensing
First to tell "busy" from "overwhelmed", then to fine-tune Q's pick within the three rules, explained in the same plain words. Trust first, then automation.
Rules you set yourself
"Anything from Sally, my boss, outranks everything else." Personal priorities, applied in the open.
Q outside the browser
A desktop app: the prompt appears over any app, switching is detected for real, and Focus turns on Do Not Disturb so Quiet covers everything.
The full story has the evidence.
Interview findings, the tool review, persona and journey maps, jobs to be done, ideation, the user flow, every key decision, the AI position, and both testing rounds, in detail.
Too much landed at once, and I lost the morning just deciding what to touch first. Not doing any of it. Just deciding.
I've spent almost a decade in enterprise software, watching task tools promise to make the chaos manageable. On a normal day they do. That day, the long list views added to the overwhelm instead of relieving it. I was stuck in a loop: pressure made choosing harder, and not choosing made the pressure worse.
I assumed it was a me problem. So I asked around.
It wasn't just me. The same week showed up in four conversations: capable people, full plates, stalling not on the work but on the choosing. That was the pattern worth designing for, and it gave me one opening question:
Why do tools that are supposed to keep us organised stop working when we need them most?
01 · Discover
I went looking for where the plan breaks.
Starting hypothesis: When the volume of work becomes unmanageable, professionals lose the ability to prioritise.
I chose two sources for their opposite strengths.
4Interviews, for depth. An implementation specialist, an account manager, a marketing manager, and a founder each walked me through a real day: where the plan held, and where it broke. I asked them to narrate, not diagnose.
100sForum posts, for breadth. Productivity forums and threads: raw frustration written in the moment, when I'd never be in the room.
The forums described a five-stage breakdown
Initial setup
Backlog accumulation
System overload
Forced narrowing
Disengagement
The relief of writing everything down turns into anxiety as the backlog grows, then into paralysis at peak load. People stop using the tool's views, narrow to a single item, and eventually abandon the tool.
"The more I used them, the more overwhelmed I became. I opened Things 3 and saw 247 tasks staring back at me."Klaus Kneupner, DEV Community
The interviews started somewhere else, and slid the same way
If things get too hectic, I either step back and reset, or just go all in on one thing.Emile · starts each day with a clear top five
Every time a new task comes in, I tend to switch tasks.Sam · implementation specialist
If I finish the thing I need to do, then I feel relieved, and if I don't, then I feel more stress.Diana · a self-described list person
No tools — just mental assessments.Angela · the line that reframed the study
Where the two met
One group had a system that failed them. The other had no system at all. Both reached the same collapse, in the same order, and both invented the same fix: narrow to one thing and shut the rest out. Stop looking at the list. Silence the notifications.
Many inputs, one card: the shape of the fix people already use.
The bottleneck isn't workload or features. It's decision paralysis under pressure.
That was the finding I hadn't planned for. If the breakdown happens with a tool and without one, the tool isn't the cause, and neither is the workload. What tips people over differs (volume for some, interruptions for others), but they all reach the same moment when choosing stops working.
My hypothesis was half right: people don't lose the ability to prioritise. They lose the capacity to turn priorities into a next move.
Seven findings
Structured systems exist but collapse under stress
Days start with clear intent. Under pressure, structure breaks and behaviour turns reactive.
Coping is binary
Overwhelmed people don't reach for a tool. They step back entirely, or narrow to one task and push through.
Priorities shift, and depend on many things
Deadline, impact, stakeholder pressure, and dependencies all matter, and so does available information. What I work on first is determined by the amount of information I have available.
Task switching is reactive, not intentional
New work arriving, not a deliberate re-evaluation, is the main trigger for switching.
Avoidance is a rational response to friction
High-effort tasks aren't forgotten. They're consciously pushed to quieter windows. I delay tasks I know will take the most time until after hours.
Stress hits the doing, not the knowing
People trust their priorities; stress changes how they work through them. I feel overwhelmed by the amount of work, but not by choosing.
Mental tracking dominates
Priorities live in people's heads or in quick checks with peers, invisible to any system.
"I don't have a problem deciding. I just don't know what to start with when things get hectic."Sam, implementation specialist
01 · Discover, continued
Why more visibility fails.
"When I hit peak overload, having a view of all my tasks overwhelms me more."Interview participant
I reviewed four leading tools for how people behave in them, not for their feature lists, and asked one question: does this help someone decide what to work on when they're already overwhelmed? The answer was always no, for different reasons.
Notion
Flexible · user-built structure
Works
Freeform canvas matches how people think
Low-friction capture of tasks and context
Breaks
Zero prioritisation logic; all structure is manual
High setup cost, so stressed users don't reach for it
A blank page paralyses when load is already high
A capture tool, not a decision tool. When you most need guidance, it offers a cursor.
Asana
Collaboration-first · strong visibility
Works
Clear hierarchy and deadline views
Priority fields give basic sequencing
Breaks
Full backlog always visible, amplifying load
Priority labels are static; nothing adapts
Notifications encourage switching
Great for the manager tracking a team; hard on the individual deciding what to start.
ClickUp
Feature-rich · highly configurable
Works
Effort scoring, custom statuses, automations
Can model complex prioritisation
Breaks
More features mean more load, not less
Power sits behind setup most people never finish
Prioritisation exists but never surfaces
The ingredients for decision support, with the assembly left to the user.
Linear
Built for teams · triage built in
Works
A Triage inbox gates unplanned work before it reaches the backlog
Rules route and prioritise incoming issues automatically
Breaks
Triage is a team ritual, run by a lead on a schedule
Once accepted, work lands in the same long list
Priority levels are set once and don't adapt to the moment
Gates the team's intake, but nothing gates one person's list at the moment it overflows.
Team triage tools like Linear's already gate incoming work before it reaches the shared list, and every mature prioritisation method (ICE, RICE, MoSCoW) is a small, transparent rubric rather than a black box; Q brings both ideas to one person, at the moment their own list has become the problem.
People at peak overload don't need more visibility. The gap is a tool that makes the next call with you when thinking is hardest.
02 · Define
From patterns to a problem worth solving.
I rewrote each finding as a design implication, so every one could be held against a later decision.
Plans fail at peak stress
People don't lack plans; they lack plans that survive a hard day.
→ Design for the worst hour, not the ideal one
Load triggers natural narrowing
Going to one task is adaptive, not a failure.
→ Support one-task mode; don't force the list back
Actionability beats importance
Under pressure, "what can I act on now" wins over "what matters most".
→ Rank unblocked work first
Missing information stalls tasks
Tasks without enough context get pushed down whatever their value.
→ Readiness is a first-class ranking input
Friction drives avoidance
Heavy tasks are deliberately deferred.
→ Lower the cost of starting: show the first steps
Stress hits execution, not confidence
People know what they should do.
→ Support doing, not second-guessing
Nothing supports the decision
Mental tracking is slow and invisible.
→ Take the deciding off their plate, visibly
Problem statement
Professionals juggling many responsibilities struggle to make task decisions under cognitive and situational pressure, because their tools are built for organising, not deciding. They help people store work. They don't help people choose what to work on.
HOW MIGHT WE
Help professionals decide what to do next when cognitive load peaks?
Identify and commit to their most actionable next task during moments of peak cognitive load, so they spend less time deciding and more time doing?
Why "professionals", not "users". The word narrows the design: people with real stakes, other people waiting on them, and tools already in place. The short question is the anchor; the long one is the working definition I tested every idea against.
03 · Empathise
Meet Sam, and the day that breaks him.
Sam RoyImplementation specialist · 5 years · full-time corporateTools: email, Slack, calendar,a task app, sticky notesBuilt from all four interviews and anchored on one participant, who later tested the prototype.
"I know what needs to get done. I just postpone heavier tasks, mostly until after hours, when things feel less hectic and I can finish without distractions."
Goal
End the day knowing the important work got done, not just the urgent-feeling work
Frustrations
Loses the thread once requests start piling up
Spends 10–15 minutes working out where to start
Tools show everything at once
Hidden behaviour
Says his prioritisation is fine, but avoids important work until notifications stop
Several participants said their prioritising was fine, but their behaviour said otherwise: they put off important tasks to avoid being interrupted, waiting until after hours for quiet. Overwhelmed people avoid lists and struggle to hold focus. Their tools answer with longer lists and more notifications.
Journey map: where Sam's day breaks, and where tools stop helping
Pattern. Tools don't fail while Sam is clear. They fail once the plan is disrupted and he most needs help getting his bearings. This is where the product should step in: at the start of the cascade, before the low point.
04 · Jobs to be done
People aren't hiring a tool to store tasks.
"Jobs to be done" asks what people are really hiring a product to do. Here, they're hiring it to think with them. I started with four jobs and merged the two that overlapped (handing over the choice, and being nudged when blocked), leaving three that map to the later product states.
When
my workday gets disrupted and the plan falls apart
I want to
reorient around what matters most right now
So I can
stop losing time in my own head and make real progress
→ Detecting, Recalculating
When
cognitive load peaks, or I'm blocked on something
I want to
hand the choice to a system I can understand, and get the next actionable task
So I can
spend my energy doing the work, not deciding what work to do
→ Suggesting
When
I'm deep in one task
I want to
have that focus protected, and only hear about what genuinely can't wait
So I can
finish what I started without fragmented attention
→ Focus active, Recalculating
05 · Ideate
Where the product enters the story.
Double Diamond: discover and define the problem, then develop and deliver the solution.
Up to here I researched the problem, defined it, and built a persona and journey map. That first half of the Double Diamond is about finding the right problem. The second half is about finding the right solution: start wide, then narrow.
Crazy 8s: eight concepts in eight minutes
The sheet itself: eight boxes, eight minutes. Boxes 1 to 4 became Q.
A rapid sketching exercise, run on paper against the short "how might we" question, for speed over polish. Four of the eight ideas turned out to be parts of one system.
1 · AI decision knobA toggle that hands prioritisation to the system.Converged
2 · Top-three listOnly three pre-ranked tasks visible.Converged
3 · Deep-focus modeBlock notifications while working.Converged
4 · Re-orient on changeA prompt when a disruption is detected.Converged
5 · Next-task previewSee what's coming without switching.
6 · Decision menuA control centre for priorities and overview.
7 · Progress nudge"60% done, keep going."
8 · Status on demandA short numbered list whenever you need control.
SCAMPER: stress-testing the combined idea
SCAMPER is a checklist of prompts (Substitute, Combine, Adapt, Modify, Eliminate, Rearrange) for pushing an idea further. Each prompt changed the design.
S
Substitute
What if the manual AI knob became automatic detection?
Behaviour signals (rapid switching, idle time, interruption count) trigger an offer of help. The product reaches for the person, not the other way round.
C
Combine
What if re-orienting and the task list were one thing?
It re-ranks when something new arrives, and the list is always reachable. Two features, one place, no jumping between screens.
A
Adapt
What pattern elsewhere already solves this?
GPS recalculation. Miss a turn and the map doesn't list every route; it recalculates silently and gives one instruction.
M
Modify
What if three tasks became one?
Three still asks for a choice. One removes it, which is what a person at peak load needs. "Suggest another" handles disagreement, one alternative at a time.
E
Eliminate
What if re-orienting never had to be manual?
It re-ranks on its own whenever the situation changes. Manual control stays available but is never required.
R
Rearrange
What if activation reassessed everything, including the current task?
Activation means "reassess and tell me what to do now". It may recommend stopping current work if priorities have shifted.
06 · The solution
Five states, each earned by a quote.
Q models the natural defence against overwhelm: it cuts the noise and locks onto one task. Unlike a stressed mind, it stays sharp.
At peak load, Q steps in:
BYhiding the list
BYshowing you one task
BYprotecting your focus
NOlong lists
NOfeature clutter
NOdistractions
Q does not take over. It suggests and nudges, and the full list stays one click away, because an overwhelmed person won't hand their day to a system they don't trust yet.
Sam's day, with Q
He starts calm, then tasks pile up
Q notices the slide and offers help Detecting
He accepts; Q suggests one task Suggesting
He starts it; Q protects his focus Focus active
Something more urgent lands; Q recommends Recalculating
Priorities done; Q steps back All clear
Each state below comes from something a participant said. That's what makes them evidence, not preference.
"When I get stressed, I tend to switch tasks multiple times without meaningful progress in each one."
Detecting
Exists because help has to arrive before overwhelm, not after.
"I know what needs to get done, but I tend to avoid them and switch to easier tasks to give myself that dopamine hit."
Suggesting
Exists to make the call once choosing stalls: One task, with the reason.
"When I know I need to work on a task, I pick one item and lock in. I close Slack, I close everything, and just do that one thing."
Focus active
Exists to protect that state for you, instead of relying on willpower.
"Every time a new task comes in while I'm in the middle of completing another one, I quickly try to mentally reassess whether that new incoming task needs my attention more to decide whether to continue with the current task or switch."
Recalculating
Exists to re-rank when a task is done or something more urgent lands.
"I'm usually pretty good at setting my priorities mentally if my day's not that chaotic."
All clear
Exists because clarity returns once the urgent work is done. Q shows All clear and hands the rest of the day back.
The same day, caught before the low point
Q steps in on the way down. By the time the old curve bottoms out, the decision is already made.
07 · System
One loop, always with a way out.
With the story in place, here is the system itself. Every decision point has two labelled exits, and every screen can return home, so Sam is never trapped.
Each coloured zone is one of Q's five states, labelled with the status pill it shows. Ambient is home.
ScreenQ screenDecision- - - Loop backZones: Q's five states, each with its pill"View all tasks" and "Exit focus mode" lead home from every state; "Suggest a priority" on home goes straight to Activate
08 · Key decisions
Every state is one decision, and the reason behind it.
q-priority-under-pressure.vercel.app/detect
Detecting
Decision
Automatic, not a switch you turn on.
Reason
An overwhelmed person shouldn't have to remember to ask for help. Q asks; Sam can decline in one tap.
q-priority-under-pressure.vercel.app/activate
Suggesting
Decision
Three readable rules, not AI. One card, the reason in plain words.
Reason
An overwhelmed person trusts what they can understand. The tags on the card ("Unblocked · Due 3pm · 3 depend on it") show why this task won, at a glance.
q-priority-under-pressure.vercel.app/focus
Focus active
Decision
Everything that helped you decide disappears.
Reason
Only what helps you do the work should remain: the first steps, progress, and one word, "Quiet", where the notification bell used to be.
q-priority-under-pressure.vercel.app/reorient
Recalculating
Decision
Q recommends, Sam decides.
Reason
The panel opens on its own, with Q's pick as the main button and the reason in one line. Continuing is one tap (or Esc) away. Two options, never a menu.
What changed between the first build and this one
q-priority-under-pressure.vercel.app/reorient
Decision 5
Reorient opens where the disruption happens.
Decision
Reorient opens over Focus on its own, with Q's pick as the main button. Continue is one tap, or Esc.
Reason
The first build sent Sam back to the task list to reconsider. That turned one disruption into two decisions, whether to switch and then what to switch to, and reopened the list Q exists to hide. Now Q makes its recommendation at the moment it matters, and Sam's answer is final either way.
q-priority-under-pressure.vercel.app/ambient
Decision 6
New work changes the count.
Decision
The only thing that interrupts Focus is a task that arrives and outranks the current one. It joins the priorities (4 becomes 5). Anything that can wait joins the list silently.
Reason
The first build reshuffled the existing list to simulate a disruption, which contradicted its own rule: nothing had actually outranked anything. Modelling work arriving is what makes "only what outranks you interrupts" true, and what keeps the priority count honest.
Protecting focus: quiet, unless it outranks you
An earlier version showed "3 held · quiet" in the Focus nav. Testing showed the problem: a number invites checking, and every change pulls Sam out of the task to see if it matters. It also promised control a web app doesn't have: a browser can't hold anyone else's notifications.
Now Focus shows a lock and one word, Quiet. No count, no bell. Q sorts everything that arrives in the background. Anything that can wait goes onto Sam's list without a sound and shows up in the bell after Focus ends; the dot means unread, nothing else. Only a task that outranks the current one interrupts: Reorient opens by itself, Q's recommendation is the main button, and Sam's choice is final.
The first time Sam enters Focus, a one-time tip asks him to turn on his computer's Do Not Disturb. Q can't do that from a browser, so it asks once, plainly, instead of pretending.
q-priority-under-pressure.vercel.app/focus
First Focus: one honest ask, one button.
q-priority-under-pressure.vercel.app/ambient
After Focus: what arrived, and what Q did with it.
Why it holds up. "Quiet" describes what Q itself does, so it's true in the browser today. The desktop version turns on the system's Do Not Disturb, so Quiet covers every app, not just Q.
09 · How it works
Three questions people ask as soon as they see it.
How does Q get its tasks?
It reads the places work already arrives (email, chat, calendar, and task tools) and builds the list for you. In the prototype, this list is a realistic sample day.
→ one ranked queue
There is no "add task" button. Q pulls from where work already lives. Asking an overloaded person to maintain another list would add the very load Q exists to remove.
How does Q reach you when you're in another app?
Whatever Sam has open, Q appears as a small prompt once the switching pattern crosses a threshold. It expands only when he engages, and "Yes, help me focus" takes him into the app.
Prototype scope. A browser can't see other apps or draw on top of them, so the live prototype simulates detection with a timer and shows the prompt inside the app. I kept it in the browser on purpose: reviewers can try it from a link in seconds, and detection is the riskiest assumption, so it's tested as a concept before it's built for real on the desktop. Section 10 rebuilds detection in code, so it reacts to real switching on the page.
How does Q prioritise?
Three rules, applied in order. Rules you can read, not a score you have to trust blindly. Each one comes from a research finding.
Unblocked
You can start it right now. Under pressure, "can I act on it" beats "does it matter most".
Time-sensitive
Soonest deadline first.
High-leverage
The most tasks and people are waiting on it.
Q ranks by urgency and who's waiting, not by calendar fit. It doesn't know how long a task takes, and it doesn't pretend to. If a pick doesn't fit the moment, the user asks for another. Scheduling around meetings is a planning job, and Q is built for the moment of decision.
Q only works on today's priorities. Sam's plate has 12 tasks; Q narrows them to the 4 that matter today. A new task that outranks them joins the set (4 becomes 5); anything that can wait just joins the list. When the priorities are done, Q shows All clear and steps back. Everything else stays on the list but never enters the loop.
10 · Detect → Activate, in code
Detection that reacts to you, not to a timer.
The live app simulates Detect with a timer, because a browser can't see other apps. That left the riskiest assumption untested: when Q offers help, does it feel like help, or like being watched?
So I rebuilt the moment everything hinges on, from the first signal to one task, on real behaviour. Below, Q counts your clicks the way it would count Sam's switches, then runs the same three rules to pick his task.
Prototype · Detect → Activate · runs in this page
Q10:40 AMS
Things have shifted.
RecalculatingRanking today's priorities
3 more priorities after this. The rest can wait.
What Q seesClick a tab to start. Sam's clock starts with your first switch.
20 min agoNow
0 of 4 short switchesLong stays 0, ignoredInterruptions 0, logged
Switch tabs the way you would on a bad morning.
Each second here is one minute of Sam's day. Or press play and watch his morning unfold.
One rule, taken from one quote
"When I get stressed, I tend to switch tasks multiple times without meaningful progress in each one."
The rule, exactly as it runs in the prototype aboveconst WINDOW = 20; // minutes Q looks backconst SHORT = 5; // leave sooner: no real progressconst THRESHOLD = 4; // short switches before Q asksconst QUIET = 30; // minutes of quiet after a "no"function shouldOfferHelp(switches, now, quietUntil) {
if (now < quietUntil) return false;
const stalls = switches.filter(s =>
now - s.at <= WINDOW && s.stayed < SHORT);
return stalls.length >= THRESHOLD;
}
Four quick exits in 20 minutes, and Q offers help.
A switch counts only when Sam leaves a task within 5 minutes. That's the quote, turned into a rule. Long stretches are work, so they never count.
What Q counts, and what it never reads
Q counts
When Sam switches tasks
How long each stay lasted
How often something interrupts him
Q never reads
What's in the email, chat or doc
What he types
What's on his screen
Why it matters. An offer to help can't cost privacy. Counting is all the rule needs, so counting is all Q does.
Decisions in the code
Long stays never count.
Busy and overwhelmed both switch a lot. Overwhelmed switches without getting anywhere. One rule about how long a stay lasts tells them apart, and it's the baseline any model in the next section would have to beat.
The offer quotes Sam's real numbers.
"You've switched tasks 4 times in 11 minutes" is something Sam can check. "You seem stressed" is a judgement, and a wrong one costs trust.
One "no" buys 30 quiet minutes.
If declining doesn't stick, the help becomes the interruption. The count also starts over, so old switches can't trigger a second offer.
Every threshold is one named number.
The window, the stay length, the count and the quiet time are the least certain numbers in the design. Each lives in one place, so it can change between test sessions without touching the interface.
Next: a rule borrowed from a Venus flytrap
A Venus flytrap can't afford to close on a raindrop. It shuts only when a trigger hair is touched twice within about 30 seconds, and it starts digesting only after about five touches.
Q faces the same trade. An offer on a busy-but-fine morning costs trust, so the next version of the detection rule borrows the plant's logic.
Venus flytrapCloses
QOffers help
One signal fadesTwo inside the window act
Same rule, two systems. A lone signal fades; a second one inside the window acts. For Q, that second signal ◆ is a stall or a new interruption.
One touch could be a raindrop. Two within 30 seconds is prey.
Two signals, not one.
Busy people switch a lot too. Overwhelmed people switch without getting anywhere, so a second kind of signal (a stall or a new interruption) has to confirm the first.
Old signals fade.
A single touch is forgotten. In Q, older switches would count for less instead of dropping off a hard 20-minute edge.
Commit in stages.
Closing is cheap; digesting takes about five touches. Q's offer is the cheap step. Focus and Quiet only follow a "yes".
A false alarm has a cost.
A trap shut on a twig is out of action for hours. A wrong offer costs trust, so the thresholds lean towards missing a moment rather than inventing one.
Designed, not built yet. The demo above still runs the four-switch rule; the next testing round compares the two. Source: University of Würzburg on how the flytrap counts (Böhm et al., Current Biology, 2016).
Timing: the offer waits for a pause
A correct signal can still arrive at the wrong moment. If Sam is halfway through a reply to a client, an offer to help is one more interruption.
So Q holds the offer until the next natural pause: the message is sent, a tab closes, or typing stops for a few seconds. Only then does it appear.
Why wait. In a study of notification timing, holding notifications until a natural break in the task, instead of delivering them at once, reduced people's frustration and how long they took to respond (Iqbal & Bailey, "Effects of Intelligent Notification Management on Users and Their Tasks", CHI 2008). Designed, not built yet: the demo above shows the offer as soon as the count is reached.
What the next round tests
Does it feel like help, or like being watched?
Participants work through the prototype, then describe the offer in their own words.
Is four in 20 minutes the right line?
Too early, and Q nags. Too late, and it misses the dip on the journey map. The session notes where each participant expected the offer.
Does one "no" feel respected?
Whether 30 quiet minutes reads as respect, or as Q giving up.
Does a second signal cut unwanted offers?
The four-switch rule and the flytrap rule run side by side. The session counts offers participants didn't want, and moments they wanted help and got none.
Is "not now" different from "no"?
Even at a pause, the moment can be wrong. The test adds "Yes, but not now", which brings the offer back at the next pause. "I'm fine, thanks" still means 30 quiet minutes.
Still a browser. The prototype only sees switches inside this page. On the desktop, the same function would read window changes from the operating system. The rule stays the same; only the source of the signal changes.
11 · The AI question
Why Q ranks with rules first, and where AI fits.
Ranking tasks and reading someone's context are natural jobs for AI, so leaving it out of version one was a deliberate decision, not an oversight. Trust is the constraint: a person at peak pressure won't hand the choice to something they can't understand, and one unexplained pick costs more trust than ten good ones earn.
Now: readable rules
Three rules, shown on every card as plain tags. Sam can predict and check every pick.
Next: AI for sensing
Telling "busy" apart from "overwhelmed" before Q offers help is the best first job for a model, and the riskiest assumption in the design.
Then: AI on top of the rules
A learned layer that fine-tunes the order within the rules and explains itself in the same plain words.
12 · Testing & iteration
Two rounds of testing. Six changes that mattered.
I put the clickable prototype in front of participants, fixed what they tripped over, then had Sam test the rebuilt app end to end. Every fix passed one filter: give people more freedom without putting the full list back in front of them.
A self-review before the first round caught four defects (duplicate icons, a progress bar that ignored sub-steps, two progress formats, a switch that could land on the same task). They're fixed and not interesting.
Round 1: the first clickable build
F1
"Why are these two numbers different?"
Before: two unexplained counts.After: the narrowing is named.
Before"4 tasks in the queue" above "12 tasks in the list". Two counts, no relationship.
After"Narrowed from the 12 on your plate" and "1 of 4 priorities cleared".
Why it mattered. The confusion was the product. Narrowing 12 to 4 is what Q does; the fix was to say so. This became the line the whole case study leads with.
F2
"What if I want a different task than Q recommends?"
One alternative, one tap away.
BeforeDisagreeing meant opening the full list, the thing Q exists to hide.
After"Suggest another" swaps in one different priority, with its own reason line. When every priority has been skipped, it returns to Q's top pick and says so.
Why it mattered. The first suggestion was to offer two or three alternatives. I kept it to one. The finding was "I want a say", not "I want a menu", and every extra option slows the choice down for someone who is already stalled.
F3
A dead end, and then a fix that was too good.
Round 1 build: the list open on every return.Now: ask Q again; the list stays closed.
BeforeLeave for the task list mid-flow and there was no way back in: a view-only list.
After, Round 1Priority tasks became clickable, straight into Focus. Sam had already decided, so Q didn't ask again.
What Round 2 showed. The clickable list quietly became the way back in, and the list was open every time he came home. So Round 2 added "Suggest a priority" on home, made "You started this one. Q still recommends finishing it." the answer for a paused task, and collapsed the list on every return. Opening it is always his choice.
Why it mattered. The fix solved the dead end and undermined the thesis. Testing the fix, not just the design, is what caught it.
Round 2: Sam tests the rebuilt app
F4
A number in Focus kept pulling him out of the task.
Before: a count in the nav.After: a lock and one word.
Before"3 held · quiet" in the Focus nav.
AfterA lock and one word, Quiet. No count, no bell.
Why it mattered. Two things were wrong. A number invites checking, so every arrival looked like it might matter. And "held" promised something a browser can't do: it can't hold anyone else's notifications. "Quiet" describes what Q itself does, so it's true today; the desktop version turns on Do Not Disturb so it covers everything.
F5
"All clear" hid what had come in.
The bell keeps a history, tagged by what Q did with each item.
BeforeFinishing every priority cleared the bell too. The dot and the list vanished.
AfterThe dot means unread and nothing else. The bell keeps a running history, tagged "Now a priority" or "Added to your list", and the dot can still show after All clear if something that can wait is unread.
Why it mattered. "All clear" is a claim about the priorities, not about the day. Hiding what arrived would make Q dishonest at the exact moment it hands control back.
F6
"Manageable" mid-day.
Before: "manageable" with nothing cleared.After: the headline states what's left.
BeforeThe home headline said the day looked manageable even with priorities still open.
AfterThe headline follows progress: "4 priorities need you today. Q has the order." → "One down. Q has the next one." → "One priority left." → "Your day looks manageable."
Before Detect has ever fired, it still says manageable: that's the moment it stops being true.
Why it mattered. Calm copy that's false isn't calm. Factual, never praise, and Q always carries the order.
One fix I cut: a summary line after Focus ("While you focused: 3 new, 2 from Sarah"). The dot already said it. A prototype with no found problems is a prototype no one tested.
13 · How I built it
Designed and shipped by one person, with AI as the build team.
There was no developer on this project. The live app, the concept animation, the diagrams, and this page were all built by me, with AI tools doing the typing and me doing the deciding. That's not a footnote to the design work: it's why two rounds of usability testing were possible at all. A working app was cheap enough to change that every finding could be fixed and re-tested within days.
Two processes ran side by side: a technical one for the product and the case study, and a visual one for the illustrations, diagrams and motion.
3Git repositories: the app, the case study, this site
94commits, June to September, every one reviewable
4pull requests merged to main on the app, one branch per change
0developers. One designer, a brief, and a budget
The technical process: brief, build, guard
Brief in Claude, before any code
I wrote the product into plain-language spec files first, then handed those to the coding tools. Context engineering, not prompting.
CLAUDE.md: what Q promises, every rule, every exit, what never to touch
SCREENS.md: each screen, its state, what's on it and how it relates to the others
DESIGN-TOKENS.md: the colour system as the single source of truth
Build in Claude Code, inside Cursor
Claude Code read the briefs and wrote the React app in one pass: audit, plan, confirm, implement. I made the small changes myself in Cursor's editor, especially copy and the case-study HTML, and used the terminal for the repetitive parts.
npm run dev to see every change live
git add · commit · push on a branch per change
Screens captured from the running build, never mocked
Guard, review, ship
Rules I couldn't hold in my head went into the pipeline, so the tools couldn't drift from the design.
check:tokens runs before every build and blocks a deploy if a raw colour appears in code
Feature branches and pull requests on GitHub, reviewed by me before merge
Vercel deploys from main, so the link in this case study is always the reviewed build
Spending credits like a budget
These tools bill by the token, so process discipline was cost discipline. A few habits kept a seven-week, one-person project affordable.
Constraints in the brief, not the chatThe CLAUDE.md opens with hard limits: don't rebuild, don't redesign, don't read Figma, don't add dependencies, plan first and wait. Every rule there is one round-trip I never paid for again.
Auto-accept editsClaude Code can pause for permission on every file change. With the brief in place I ran it in auto-accept mode, so a pass ran to completion instead of stopping twenty times to ask.
Batch, then reviewTen small requests cost more than one well-specified one. I collected changes, wrote them as a single brief, ran the pass, and reviewed the diff in Cursor before committing.
Hand-edit what's cheaper by handA typo, a spacing fix or a caption doesn't need a model. Those went straight into the editor.
Throwaway file firstEvery new pipeline (a capture script, a sync script, a new tool) was tried on a scratch file, never on the real case study.
A budget per sessionEach working session started with a credit ceiling. When it was spent, the day was over. Errors were the curriculum, not a reason to keep going.
Iteration: first draft, then versions, then the one that tests
Nothing here was right the first time, and the process assumed that. Each artefact started as a fast first draft, then went through named versions until one held up in front of a participant or a reviewer. The storyboard took four versions before the panels read in order; the emotional curve took six before it plotted one thing instead of two. The app itself went through two full builds: the July build that Round 1 tested, and the September rebuild that Round 2 tested. The Testing section above is what this loop looks like from the outside.
git log · q-priority-under-pressure (excerpt)
2026-06-01feat: Q design system with six screens and context engineering
2026-07-05Add scoped CLAUDE.md and SCREENS.md build specs
2026-09-18Activate "Suggest another", Ambient re-entry, fresh demo per login
2026-09-18Align every color to docs/DESIGN-TOKENS.md and guard it
2026-09-19Ambient re-entry, honest Focus label, bell driven by unseen items
2026-09-20Focus goes quiet: lock + "Quiet", a bell that remembers, one interruption
2026-09-20One live ranking decides what's next, never a stored position
2026-09-27Call Q's tasks "priorities" everywhere; one plate line on Ambient
2026-09-27Merge pull request #4 from simplyfay/feat/ambient-drop-calendar-stats
branches & pull requests
maindeploys to Vercel
feat/ambient-reentry-focus-labelPR #1, #2
chore/align-color-tokens
fix/activate-controls-and-reentry
fix/activate-footer-count
feat/activate-card-higherPR #3
feat/ambient-drop-calendar-statsPR #4
the other two repos
q-case-study23 commits · 3 branches
portfolio39 commits · 4 branches · Next.js
The repositories are private. I'm happy to walk through any of them in an interview.
From CLAUDE.md, the brief that ran the September rebuild
The prime directive. Do not rebuild, redesign, or re-extract anything. Reuse what exists. Make minimal, surgical changes. Before writing any code, list every existing page in the repo and your plan, then wait for confirmation.
Hard constraints (these protect a limited budget).
Do not read from or connect to any Figma file. All design is already in the repo.
Do not redefine the design tokens. They exist in tokens/; use them.
Do not add a backend, real auth, analytics, or any dependency not already present.
Do not invent new page designs. If a page in the flow is missing, stop and ask.
Work in one focused pass: audit → plan → confirm → implement. Minimise round-trips.
The visual process: four tools, one style
Illustration, diagrams and motion came from different tools, so the job was keeping them in one voice: the same navy-and-blue palette, the same calm register, nothing decorative. Adobe Firefly drew the people and scenes from written prompts. Paper generated several takes on a screen at once, so I could brainstorm layouts side by side before committing to one in Figma. Figma held the journey maps, wireframes and screens. Claude wrote the diagrams and the concept animation directly in code, so they share the page's own tokens and stay editable as text. This site's structure started from a template drafted with Grok, then built out in Next.js.
This case study first lived on my previous portfolio. There, Figma Make and Framer's agent made quick, site-wide changes in one pass instead of page by page.
Adobe FireflyStoryboardFour versions, one consistent character across every panel.Adobe FireflyThe opening illustrationGenerated, then background-removed to sit on the page.Adobe FireflyMany inputs, one cardDrawn from a prompt, then cleaned up by hand.PaperScreen explorationsMany ideas for one screen, generated to brainstorm before choosing a direction.FigmaJourney mapsFive stages of Sam's day, with an emotional curve that never recovers.Claude, in codeUser flow and its statesWritten as SVG with the page's tokens, so it re-themes with the site.Claude CodeConcept animationHTML and CSS, using the app's real screens, no video file.
What this means for a team: the research gets a working prototype, not a promise of one, and engineers get a reference build to read instead of a file to interpret.
14 · Design system
One small system behind every screen.
Q is built from one set of design tokens and three shared components. It's small on purpose: a product that hides everything but one task shouldn't need many parts.
78colour tokens, in three layers
1typeface, Inter, in ten sizes
3components: button, status pill, progress bar
0raw colours in the app; a build check blocks them
Colour: raw value, meaning, use
Raw valueblue/600#2563C9
Meaningaccent/primaryPrimary actions
Usebutton/primary/bgThe primary button
In the app
Components never touch a raw value. Change one meaning, and every screen follows.
Blue ramp · 600 is the primary
50100200300400500600700800900
Gray ramp · slate-tinted to sit with the blue
50100200300400500600700800900950
Surface and border
surface/page#F8FAFC
surface/default#FFFFFF
surface/subtle#F1F4F8
border/default#E4E8EF
border/strong#CFD5DF
Content
content/primary#111827
content/secondary#4B5563
content/muted#6B7280
content/link#2563C9
content/error#D14343
Accent and status
accent/primary#2563C9
accent/primary-hover#1E50A6
accent/primary-active#1A4488
accent/subtle#EFF4FE
status/success#3F9A4E
status/dnd#5856D6
Blue is an accent, not a text style. Headings and body copy are grays. Blue is kept for links, the primary action and the status pill. The one purple belongs to the Do Not Disturb moon.
Type: one family, ten sizes
text-5xlYour day looks manageable.32 / 1.2
text-4xlOne priority left.28 / 1.2
text-3xlAnswer Northwind on the blocked rollout24 / 1.2
text-2xlNew priority came in20 / 1.35
text-xlLet Q take the wheel18 / 1.35
text-lgHalfway through today’s priorities.16 / 1.5
text-mdQ has the next one.15 / 1.5
text-baseFor the quietest focus, turn on your computer’s Do Not Disturb.14 / 1.5
text-smNarrowed from the 14 on your plate12 / 1.5
text-xsDemo login: sam / focus. Logging out restarts the demo.11 / 1.5
Line height follows size. 1.5 up to 16px, 1.35 at 18 and 20px, 1.2 from 24px. Weights run from Regular to Bold; Medium carries most labels.
Shape, space and elevation
Radius
sm · 4md · 6lg · 8xl · 122xl · 16full
Anything Sam clicks is fully round. Cards and dialogs take 16px; popovers and the logo tile, 12px.
Spacing
4812162024324048648096
Twelve steps on a 4px grid. Buttons are 12 by 24; cards pad 24 or 32.
Elevation
smmdlgxl
Depth comes from shadow, not borders. Small for cards, large for the Detect card and dialogs. Each is two layers of a cool dark, never pure black.
Mark
QQ
A white bold Q on the darkest gray. Drawn in code in the app's own typeface, so it never needs an image file.
Components: three, and each has one job
Button
Job
Primary is what Q recommends. Secondary is the alternative; ghost is the quiet way out.
Rule
One primary per screen. Buttons get colour only through these variants.
Says what Q is doing right now. Amber notices, blue helps, green works, gray rests.
Rule
One at a time, and only for Q's state. The word carries the meaning; the dot is decoration.
Today's priorities40%
This task75%
Progress bar
Job
Shows how far along Sam is. Blue for the day's priorities, green for the task in Focus.
Rule
Same bar in both places. Only the fill colour changes.
15 · Accessibility
Calm has to pass contrast, too.
Q's colours live in one design-token system with three layers: raw values, their meaning (such as "primary action"), and their use in each component. A check at build time blocks any release where a raw colour sneaks into the code. The primary blue is #2563C9, a shade darker than the obvious choice, so white text on it meets WCAG AA, the standard accessibility bar for contrast.
Detecting
Suggesting
Focus active
All clear
Page
5.67:1white on primary blue: AA for every button
4.83:1muted text on white; muted text is kept off tinted surfaces, where it would fail (4.38:1)
24px+minimum tap target: the notification bell grew from 20px without shifting the layout
Keyboard & screen readersevery control reachable by keyboard with a visible focus ring; screen readers hear each new suggestion, and Reorient takes focus when it opens
16 · Reflection & what's next
What I'd carry forward.
The insight was in the overlap. Pairing a few deep interviews with forum volume showed that people with and without a system break down the same way. Either source alone would have blamed the tool.
Restraint is a feature. Every round of feedback pushed towards "show more". The design held because each fix added freedom, not visibility.
Test the fixes, not just the design. Round 1's clickable list solved a dead end and quietly made the list the way back in. Round 2 caught it. Building a working app early is what made both rounds possible.
What I'd do differently: test detection earlier. "Four switches in twenty minutes" sometimes means busy, not overwhelmed, and that's the riskiest assumption left.
Next
AI, starting with sensing
First to tell busy from overwhelmed, then to fine-tune the order on top of the three rules, explained in the same words.
Rules you set yourself
"Anything from Sally, my boss, outranks everything else."
Q outside the browser
A desktop app: the prompt over any app, real switching detection, and Focus that turns on Do Not Disturb, so Quiet covers everything.
Intervention needs to step in here, before the low point
