Soft Deadline Room: designing a timer that does not shout

The pressure hidden inside a timer

Most focus timers are mechanically simple. Pick a duration, press start, watch the numbers fall. The harder design question is what the timer communicates while it is doing that.

A countdown can easily become another manager. Bright warnings, streaks, scores, alerts, productivity claims, and language about winning the day all add pressure to a task that may already carry enough of it. I wanted to try the opposite approach. Soft Deadline Room is for one piece of work that needs movement, not a total personal operating system.

The prototype asks for a task, a duration, and a room mood. That is the whole setup. The task can be something plain and specific, such as clearing an inbox or opening a report. The available sessions are 10, 15, 25, 45, or 60 minutes. The familiar 25-minute Pomodoro interval is there, but it is one choice rather than a rule.

I called it a "soft deadline" because the time box is meant to create a boundary without pretending that every piece of work is urgent. When the clock reaches zero, the interface says the task has been moved forward. It does not award points or scold the person for stopping.

Making the room feel different

The visual design is dark, quiet, and deliberately spare. A large clock sits in a softly lit panel, with a narrow progress bar and a short line of copy underneath. The three room moods, Quiet, Steady, and Night, change the color and atmosphere without changing the timer's function. Mood selection is not presented as a psychological intervention. It is simply a modest way to let someone choose the surroundings they would rather look at for the next half hour.

The copy changes as the session advances. At the beginning, it asks only for a start. Around the middle, it acknowledges that the task is in motion. Near the end, it suggests one last pass. Completion is framed as enough for now. I wanted those messages to be useful without sounding like a coach leaning over someone's shoulder.

The page also respects reduced-motion preferences. Its ambient glow normally moves at a slow pace, but the CSS removes that animation when the browser reports that the user prefers less motion. On a narrow screen, the controls stack rather than squeezing into a desktop layout. These are small decisions, but they belong in the first version rather than on a someday list.

Keeping the product boundary small

Soft Deadline Room is an internal, local prototype, not a launched public product. It is marked noindex,nofollow, and I have not attached analytics or presented private testing as market traction.

The technical boundary is just as intentional. There are no accounts, no backend, no model inference, no external audio, and no third-party service calls. The HTML, CSS, and classic browser JavaScript can run from a local web server or directly from an unzipped folder. The classic script choice matters here: it avoids an unnecessary module-loading constraint when the page is opened through file://.

The only persistence is local and limited. When a session starts, the browser stores the task name in localStorage, then restores it the next time the page opens. If storage is unavailable, the timer continues to work. The prototype does not send the task elsewhere, and it does not claim to provide cloud sync.

There is a local event hook for actions such as start, pause, reset, completion, duration changes, and mood changes. It dispatches browser events but does not transmit them. That preserves a clean option for approved measurement later without quietly adding tracking now.

Building and checking the behavior

I set the product direction, constraints, interaction language, and acceptance criteria, then used AI assistance to help implement and review the static prototype. I treat generated code as a draft, not evidence that a product works. The useful part of AI assistance here was speed: it helped turn a tightly bounded idea into HTML, CSS, JavaScript, and tests. The responsibility for deciding what belonged in the product, checking the result, and keeping the claims narrow remained mine.

The timer has start, pause, and reset controls. Starting a session disables the start button, enables pause, and decrements the remaining time once per second. Pausing clears the active interval. Reset returns the selected duration to its full value. Changing the duration stops the running timer before rebuilding it, while changing the room mood leaves the remaining time intact.

I used dependency-free Node tests for the parts that can be checked cleanly as logic: duration formatting, task cleanup, session length conversion, valid mood selection, and the four encouragement phases. Static smoke checks confirm that the required controls and three moods are present, the internal page remains noindex, the script contains no external URLs, local persistence exists, and responsive and reduced-motion rules are included. The prototype's browser verification also confirmed that start initiates the countdown, the displayed time decreases, pause becomes available, and the console remains clear of errors.

That test scope is intentionally described rather than inflated. It proves the current behavior covered by the checks. It does not prove that the idea improves attention, reduces stress, or changes anyone's habits.

What I learned from the constraint

The most useful lesson was that humane product design can come from subtraction. I did not need a dashboard, account system, notification engine, AI companion, or behavioral claim to explore the interaction. Removing those features made the premise easier to judge: one task, one bounded period, and a calmer way to watch time pass.

Soft Deadline Room remains a private prototype. I would want broader accessibility review and real user feedback before considering it a public tool. Even in its current form, it gave me a concrete way to practice something I care about: building software that supports action without turning ordinary difficulty into personal failure.