← All work
2025
AI
Productivity
Neura Task
An AI-assisted productivity system designed to reduce decision fatigue
Role
Sole designer, concept and testing
Timeline
Nov 2025
Services
AI Interaction · Prototyping
Tools
Figma
Industry
Productivity
Status
Concept
Visit live site ↗
Overview
A productivity system built around a question nobody had answered for me: how much should an AI assistant do before it asks?
Not whether it should act — where the line sits. I prototyped an agentic task model that proposes and waits for approval, A/B tested to locate the point where automation stops reading as helpful and starts reading as presumptuous, and set the defaults there.
Challenge
Every AI productivity tool makes the same bet: that people want fewer decisions. So the assistant reschedules, reprioritises and reorganises, and the user is grateful.
Past a certain threshold it inverts. The same automation that felt helpful starts feeling like the system has opinions about your life. People turn features off, or leave.
Most products handle this by shipping a settings panel and making the user find their own tolerance. That works for the small minority who open settings. For everyone else the default is the product, and the default is usually a guess.
I wanted to find the threshold rather than guess it.
Constraints
Self-directed, at prototype fidelity. No engineering team, no existing user base, no production telemetry. Everything was tested on prototypes with recruited participants rather than on live behaviour, which means I was measuring stated and observed reaction in a session, not retention over months.
That limits what the finding can claim. I can say where people’s reaction turned during a task. I can’t say whether it holds after a week of living with the tool — and those are different numbers.
Process
Propose-and-wait as the base model. Rather than acting autonomously or waiting to be asked, the system proposes a change and holds until approved. Every automated action has a visible pending state, so nothing happens silently.
A/B testing the autonomy threshold. I varied how much the system did before pausing — across rescheduling, priority changes and task grouping — and watched for where the reaction turned from relief to resistance.
The finding set the defaults. Rather than shipping a settings panel and making people tune their own tolerance, the tested threshold became the out-of-box behaviour.
Decisions & Tradeoffs
Propose-and-wait over full autonomy. Full autonomy is faster and demos better — the system just handles it. I chose the slower model because the failure modes aren’t symmetrical. An assistant that asks too often is annoying. An assistant that acts wrongly without asking breaks trust in a way that’s very hard to rebuild, and users don’t come back to find out whether it improved. I traded perceived speed for recoverable failure.
Defaults set by testing, not a settings panel. The safer product decision is to expose the control and let people choose. I deliberately didn’t. A settings panel moves the design problem onto the user and calls it flexibility, and most people never open it — so the default is the experience for nearly everyone. If the default is the product, it should be the part you tested hardest. The cost is that people outside the tested range get a system tuned for someone else, and they have no way to adjust it.
Testing reaction, not retention. I measured where automation started reading as presumptuous inside a session, because that’s what prototype testing can honestly measure. The threshold almost certainly moves with familiarity, and I couldn’t test that. I set the defaults at the conservative end for that reason — easier to earn more autonomy later than to claw back trust.
Result
An agentic task model with a tested autonomy threshold rather than an assumed one, and defaults set where the evidence put them rather than where a settings panel would have passed the decision to the user.
What I’d Do Next
The threshold I found belongs to one group of people at one moment. The question I’d want answered next is whether it moves with familiarity — whether someone tolerates more automation in week four than on day one.
If it does, static defaults are the wrong model entirely, and the system should earn autonomy over time rather than assume a fixed amount up front. That’s a longitudinal study, not a session, and it’s the study that would actually settle it.
Next project →
