System Requirements Document for study-focus

1. Introduction

study-focus is an application for study focus that blocks distracting apps. Its product intent is subtraction: during a study focus session, the distracting apps a user has chosen are blocked, and when the session ends, normal app usability is restored. The product exists so that a student or self-directed learner can sit down, start a timed focus session, and study without the phone pulling them away.

The audience is students and self-directed learners (roughly 16–30) who study alone, often at night, and who already feel buried in notifications. They judge the product by whether it feels peaceful the second it opens. The interface therefore behaves like a cleared desk rather than a dashboard: one idea per screen, one action per screen, and emptiness treated as content.

The product is delivered as a first-party custom web application with application-owned identity. Durable blocking preferences and focus-session history belong to the individual user, so self-service enrollment and returning verification are part of the current scope. The blocking mechanism itself is a system responsibility that must remain active for the session duration and restore blocked-app usability when the session ends.

2. System Overview

study-focus is a custom-UI web application backed by a server-side service. A user arrives anonymously at Landing, learns what the product does, and either enrolls at Sign Up or verifies at Login. Once identified, the user prepares which apps count as distracting on App Blocking, starts a timed session from Session Setup, watches the session run on Focus Session, and reviews past sessions on Focus History.

The active human actors are the Focus Session User and the Focus Planner. The Focus Session User runs sessions in the moment: they start a timed session, see that blocking is active, see when it ends, and end it so app access returns. The Focus Planner prepares in advance: they define which apps count as distracting, decide how long sessions should run, and review past sessions to judge whether the blocking setup is helping.

The blocking mechanism is owned by the system: it enforces the user's selected blocking for the whole session duration and restores blocked-app usability when the session ends. The user's side of that lifecycle is observable on Focus Session — the running state, the remaining time, and the session-ending action.

Narrow exclusions for the current scope: no streaks, badges, confetti, or gamified celebration on session completion; no charts, donuts, or coloured bar graphs in focus history; no illustrated characters, mascots, or 3D renders; no cards, shadows, hover-lift tiles, or elevation system; no gradients, glassmorphism, blur, or glow; no blue or indigo anywhere in the palette; no rounded pill buttons, badges, or sticker shapes; no bouncy, springy, or parallax motion. No adjacent account-management capabilities (password reset flows, profile editing, social features, team or shared study features) are part of the current scope.

2a. Product Interpretation and Delivery Boundary

Delivery. study-focus is delivered as a first-party custom web application with a server-side service behind it. All seven destinations — Landing, Sign Up, Login, Session Setup, App Blocking, Focus Session, and Focus History — are application-owned custom pages. There is no provider-owned or external-only surface in the current scope, and no headless-only delivery.

Access ownership. Landing, Sign Up, and Login are anonymously reachable. Session Setup, App Blocking, Focus Session, and Focus History require the user to be identified, because the blocking choices and the session record must remain bound to the correct person and be resumable across visits. Identity is application-owned: the user establishes it themselves at Sign Up and verifies it at Login. No differentiated permissions, roles, or role-based visibility exist — every identified user controls only their own blocking choices and their own session history.

Current vs. future. Everything described in this document is current. The blocking mechanism's enforcement and restoration behavior is current and required. Nothing in this document is deferred; no future-horizon features are claimed.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. A nearly empty paper-coloured field (#F4F1EA) with a single full-bleed still-life photograph bleeding off the right edge — a cleared desk, one closed notebook, morning light — occupying roughly 45% of the viewport at desktop and collapsing to a 40vh band above the fold at 375px. A 12px tracked uppercase label above the headline reads "A QUIETER WAY TO STUDY". The headline sits flush-left in the remaining emptiness at clamp(32px, 6vw, 64px), light weight, two short lines, with a single hairline rule beneath it at exactly the text's width. No button block, no sub-headline paragraph, no gradient.
• Primary action. A text link to Sign Up, underlined in #B5643C, sitting beneath the rule.
• Supporting action. A text link to Login, separated from the primary link by a thin vertical rule.
• Domain entities. None. Landing reads no user data.
• Component responsibilities. Hero field (paper ground, emptiness as the dominant element); full-bleed still-life photograph (the only object, printed onto the page rather than placed on it); tracked label; two-line headline; hairline rule; two text links with a thin vertical divider.
• States. Loading: the photograph fades in over 600ms as the screen's single object settles; the type is present immediately. Empty: not applicable — the page is intentionally near-empty by design. Success: the visitor reads the promise and follows one of the two links. Error: if the photograph fails to load, the paper field, label, headline, rule, and both links remain fully readable and usable. Recovery: the visitor can retry the photograph on reload; no other content depends on it.

Sign Up

• Information and state. Anonymous identity-access surface. One idea per screen: a short sentence-case heading, a hairline rule at the heading's width, and the enrollment fields as plain ruled rows — label left, input right, 1px #D8D2C6 hairline between — never cards.
• Primary action. Create the account and continue into the product.
• Supporting action. A text link to Login for a visitor who already has an account.
• Domain entities. Account identity (the user's own credentials), which becomes the owner key for that user's blocking preferences and focus-session history.
• Component responsibilities. Heading; hairline rule; enrollment field rows; inline validation messages in muted #8C8578 for labels and ink #1C1B18 for the message text; primary action as a flat rectangle with generous internal padding and no shadow; link to Login.
• States. Loading: the primary action shows a restrained in-progress state while the account is created; fields remain visible. Empty: fields start empty with no placeholder noise. Success: the account is created and the user continues to Session Setup. Error: a taken identifier, a malformed identifier, or a mismatched confirmation is reported inline next to the offending field, and the entered values are preserved. Recovery: the user corrects the field and resubmits; a network failure leaves the form intact and re-submittable.

Login

• Information and state. Anonymous identity-access surface. Same ruled-row composition as Sign Up: short heading, hairline rule, credential rows separated by hairlines.
• Primary action. Verify the returning user and resume access to their saved blocking choices and focus-session history.
• Supporting action. A text link to Sign Up for a visitor who has not enrolled.
• Domain entities. Account identity; the returning user's saved blocking preferences and focus-session history, which become reachable after verification.
• Component responsibilities. Heading; hairline rule; credential rows; inline error text; primary action as a flat rectangle; link to Sign Up.
• States. Loading: the primary action shows a restrained in-progress state. Empty: fields start empty. Success: the user is verified and lands on Session Setup with their saved blocking choices and history available. Error: incorrect credentials are reported inline without revealing which part was wrong, and the entered identifier is preserved. Recovery: the user retries; repeated failure keeps the form usable and does not lock the user out of the page.

Session Setup

• Information and state. Identified surface. Shows the prepared blocking choices for the upcoming session and the session length, so the user can confirm what will be blocked and for how long before committing. The composition is one idea per screen: the session length as the single heavy element, the blocking summary as ruled rows beneath it.
• Primary action. Start the focus session, which hands off to Focus Session and activates the blocking mechanism.
• Supporting action. A text link to App Blocking to adjust which apps are blocked before starting.
• Domain entities. Focus session (length, start time, the set of blocked apps for this session); blocking preference (the user's saved set of distracting apps).
• Component responsibilities. Session-length control; blocking summary as plain ruled rows with hairline separators; primary start action as a flat rectangle; link to App Blocking; inline message when no apps are selected for blocking.
• States. Loading: the saved blocking choices are fetched and the summary rows settle in with a 600ms opacity fade. Empty: when the user has no saved blocking choices, the summary area states that no apps are selected and offers the link to App Blocking; starting remains possible only after at least one app is selected. Success: the session starts and the user is taken to Focus Session. Error: if the session cannot be started, an inline message explains it and the start action remains available to retry. Recovery: the user adjusts the blocking set or the length and retries.

App Blocking

• Information and state. Identified surface. The list of apps that can be treated as distracting, rendered as a ruled ledger: app name left, flat rectangular toggle right, 1px #D8D2C6 hairline between each row. No cards, no icons, no shadows. A small tracked uppercase label heads the list, with a hairline rule at the label's width.
• Primary action. Toggle an app into or out of the blocked set, which saves the choice to the user's blocking preferences.
• Supporting action. A text link back to Session Setup to start a session with the current choices.
• Domain entities. Blocking preference (the user's saved set of distracting apps); app entry (name and blocked/unblocked state).
• Component responsibilities. Section label; hairline rule; ruled app rows; flat rectangular toggles; save confirmation as a quiet inline state rather than a toast or badge; link to Session Setup.
• States. Loading: rows settle in with a 600ms opacity fade as the saved preferences arrive. Empty: when no apps are available to list, the page states that plainly in muted #8C8578 and keeps the link to Session Setup available. Success: a toggle change is saved and the row's state reflects it immediately. Error: if a change cannot be saved, the row reverts to its previous state and an inline message explains it. Recovery: the user retries the toggle; the rest of the list remains usable.

Focus Session

• Information and state. Identified surface, and the product's signature view: one enormous timer numeral (up to 200px, weight 200) alone in the centre of the viewport with nothing else on screen, one thin 1px ink ring around it with a slow clay-coloured (#B5643C) arc for elapsed time, and one "end session" text link at the bottom edge. The running-session dot in #B5643C is the only other accent. The state shown is: blocking is active, the session is running, and the session ends at a stated time.
• Primary action. End the session, which stops the blocking mechanism and restores blocked-app usability.
• Supporting action. None on this screen — the direction is one number, one arc, one link.
• Domain entities. Focus session (start time, planned length, remaining time, state); blocked-app set for this session; the session record that will appear in Focus History.
• Component responsibilities. Timer numeral in Zen Kaku Gothic New weight 200; hairline progress ring with the clay elapsed arc animating on a slow 1s ease; running-session dot; "end session" text link at the bottom edge; session-state crossfade on change.
• States. Loading: the session state settles in with a 600ms opacity fade. Empty: not applicable — this page only exists while a session is running or just ended. Success: the session runs to its planned end, blocking is lifted automatically, and the completed session is recorded in Focus History. Error: if the blocking mechanism cannot be confirmed active, the page states that blocking is not active rather than showing a false running state, and the user can end the session. Recovery: the user can end the session at any time; ending always restores blocked-app usability, and the session is recorded with the time actually spent.

Focus History

• Information and state. Identified surface. A quiet printed ledger of past focus sessions: date left, duration right in tabular figures, hairline between each row, months as small tracked uppercase labels. No charts, no coloured bars, no badges.
• Primary action. Read the record of past sessions to judge whether the blocking setup is helping.
• Supporting action. A text link to App Blocking to adjust the blocked-app list based on what the ledger shows.
• Domain entities. Focus session records (date, duration, state); the user's blocking preferences.
• Component responsibilities. Month labels in 12px tracked uppercase; ruled session rows with tabular figures; hairline separators; link to App Blocking.
• States. Loading: rows settle in with a 600ms opacity fade. Empty: when the user has not yet completed a session, the page states that plainly in muted #8C8578 and offers the link to App Blocking as the next step. Success: the ledger lists the user's past sessions in order. Error: if the history cannot be loaded, an inline message explains it and the page remains navigable. Recovery: the user can retry loading the ledger.

3. Functional Requirements

FR-1 — Block distracting apps during a focus session (explicit) As a Focus Session User, I should have the distracting apps I selected blocked for the duration of my study focus session, so that I can study without them pulling me away.

• Trigger/input: the user starts a focus session from Session Setup with at least one app selected for blocking.
• Observable result: the blocking mechanism is active for the whole session duration, and Focus Session shows the session running with the remaining time.
• Access state: identified user.
• Failure/recovery: if blocking cannot be confirmed active, Focus Session states that blocking is not active instead of showing a false running state, and the user can end the session.
• Continuation: the session runs until it reaches its planned end or the user ends it.

FR-2 — Restore blocked-app usability when the session ends (required_inference) As a Focus Session User, I should have the apps that were blocked become usable again when my session ends, so that I can return to normal app use afterward.

• Trigger/input: the session reaches its planned end, or the user ends it from Focus Session.
• Observable result: the blocking mechanism stops and the previously blocked apps are usable again; Focus Session no longer shows a running session.
• Access state: identified user.
• Failure/recovery: if restoration cannot be confirmed, the page states the session has ended and the user can retry ending it.
• Continuation: the ended session is recorded in Focus History, and the user can start another session from Session Setup.

FR-3 — Choose which apps are blocked (explicit) As a Focus Session User, I should select which distracting apps are blocked during my focus session, so that the blocking matches what actually distracts me.

• Trigger/input: the user toggles apps on App Blocking.
• Observable result: each toggled row immediately reflects its blocked or unblocked state, and the choice is saved to the user's blocking preferences.
• Access state: identified user.
• Failure/recovery: if a change cannot be saved, the row reverts and an inline message explains it; the user retries.
• Continuation: the saved set is used by the next session started from Session Setup.

FR-4 — Start a timed study focus session (required_inference) As a Focus Session User, I should start a timed study focus session after my blocking choices are prepared, so that I have a defined stretch of focused study.

• Trigger/input: the user confirms the session length and the blocking summary on Session Setup and starts the session.
• Observable result: the session begins, the user is taken to Focus Session, and the blocking mechanism activates.
• Access state: identified user.
• Failure/recovery: if the session cannot be started, an inline message explains it and the start action remains available to retry.
• Continuation: the running session is shown on Focus Session until it ends.

FR-5 — See that blocking is active and when the session ends (required_inference) As a Focus Session User, I should see that blocking is active and when my session ends, so that I know the blocking is working and when I get my apps back.

• Trigger/input: a session is running.
• Observable result: Focus Session shows the remaining time as the single enormous numeral, the elapsed arc, the running-session dot, and the session's end.
• Access state: identified user.
• Failure/recovery: if the running state cannot be confirmed, the page says so rather than showing a false running state.
• Continuation: the display updates until the session ends.

FR-6 — End a session early (required_inference) As a Focus Session User, I should be able to end my session before its planned end, so that I am not trapped if something genuinely needs my attention.

• Trigger/input: the user follows the "end session" text link on Focus Session.
• Observable result: the session stops, blocking is lifted, and the session is recorded with the time actually spent.
• Access state: identified user.
• Failure/recovery: if ending cannot be confirmed, the page states the session has ended and the user can retry.
• Continuation: the user returns to Session Setup to start another session.

FR-7 — Self-service enrollment before first use (required_inference) As a Focus Session User, I should be able to enroll myself before first use, so that my blocking choices and focus-session history are durably mine.

• Trigger/input: an anonymous visitor follows the Sign Up link from Landing or Login and submits the enrollment fields.
• Observable result: the account is created and the user continues into the product with their own blocking preferences and history.
• Access state: anonymous entry; the account is created by the user themselves.
• Failure/recovery: a taken or malformed identifier or a mismatched confirmation is reported inline next to the offending field with the entered values preserved.
• Continuation: the user proceeds to Session Setup.

FR-8 — Returning verification to resume saved state (required_inference) As a Focus Session User, I should be able to verify myself on return, so that I resume access to my saved blocking choices and focus-session history.

• Trigger/input: a returning user submits their credentials on Login.
• Observable result: the user is verified and their saved blocking choices and history are available again.
• Access state: anonymous entry to Login; identified state after verification.
• Failure/recovery: incorrect credentials are reported inline without revealing which part was wrong, and the entered identifier is preserved so the user can retry.
• Continuation: the user lands on Session Setup.

FR-9 — Prepare which apps count as distracting (required_inference) As a Focus Planner, I should define in advance which apps count as distracting, so that my blocking setup is ready before I sit down to study.

• Trigger/input: the user toggles apps on App Blocking outside of a running session.
• Observable result: the saved blocking preference persists and is applied to the next session started from Session Setup.
• Access state: identified user.
• Failure/recovery: if a change cannot be saved, the row reverts and an inline message explains it.
• Continuation: the prepared set appears in the blocking summary on Session Setup.

FR-10 — Decide how long focus sessions should run (required_inference) As a Focus Planner, I should decide how long my focus sessions should run, so that my study routine has a defined shape.

• Trigger/input: the user sets the session length on Session Setup.
• Observable result: the chosen length is used for the session that starts from that screen and is reflected in the remaining time shown on Focus Session.
• Access state: identified user.
• Failure/recovery: if the length cannot be applied, an inline message explains it and the start action remains available to retry.
• Continuation: the session runs for the chosen length and is recorded in Focus History.

FR-11 — Review past focus sessions (required_inference) As a Focus Planner, I should review a record of my past focus sessions, so that I can judge whether my blocking setup is helping me study.

• Trigger/input: the user opens Focus History.
• Observable result: a printed ledger of past sessions — date left, duration right in tabular figures, hairline between rows, months as small tracked uppercase labels.
• Access state: identified user.
• Failure/recovery: if the history cannot be loaded, an inline message explains it and the page remains navigable so the user can retry.
• Continuation: the user can follow the link to App Blocking and adjust the blocked-app list based on what the ledger shows.

FR-12 — Adjust the blocked-app list based on the record (required_inference) As a Focus Planner, I should adjust my blocked-app list after reviewing my sessions, so that my blocking setup keeps matching what actually distracts me.

• Trigger/input: the user follows the link from Focus History to App Blocking and toggles apps.
• Observable result: the adjusted set is saved and applied to the next session started from Session Setup.
• Access state: identified user.
• Failure/recovery: if a change cannot be saved, the row reverts and an inline message explains it.
• Continuation: the user returns to Session Setup to run a session with the adjusted set.

4. User Personas

Focus Session User

Product context. A student or self-directed learner who studies alone, often at night, and who feels buried in notifications. They open study-focus in the moment they intend to study, not to plan a routine. Their relationship with the product is short and repeated: start, study, end.

Primary goal. To sit down and study without the phone pulling them away, and to know exactly when they get their apps back.

Distinct accepted responsibilities. This persona starts a timed study focus session from Session Setup after confirming the blocking summary and the session length. They watch Focus Session to confirm blocking is active and to see the remaining time. They end the session — either by letting it run to its planned end or by following the "end session" link early — and thereby restore blocked-app usability. They also choose which apps are blocked for the session on App Blocking when the prepared set does not match what is distracting them right now.

Relevant inputs and decisions. The session length; the set of apps to block for this session; whether to end early. Their decision point is the moment before starting: is this the right blocking set and the right length for the study block ahead?

Interactions with other accepted participants. The Focus Session User is the sole human actor in the running-session lifecycle. The blocking mechanism is a system responsibility that acts on their behalf: it enforces their selected blocking for the session duration and restores usability when the session ends. The Focus Session User observes that system work as the running state, the remaining time, and the return of app access.

Observable success. The session runs with blocking confirmed active, the remaining time is visible, and when the session ends the previously blocked apps are usable again and the session appears in Focus History.

Focus Planner

Product context. A user who prepares their study routine in advance rather than only in the moment. They think about which apps count as distracting in general, how long a study block should be, and whether their setup is actually working over time. They open study-focus between study sessions as well as before them.

Primary goal. To keep a blocking setup that genuinely matches what distracts them, and to judge from their own record whether that setup is helping them study.

Distinct accepted responsibilities. This persona defines in advance which apps count as distracting on App Blocking, outside of any running session. They decide how long focus sessions should run on Session Setup. They review the printed ledger of past sessions on Focus History, and they adjust the blocked-app list on App Blocking based on what the ledger shows.

Relevant inputs and decisions. Which apps belong in the blocked set; what session length suits their routine; whether the record of past sessions suggests the setup is working. Their decision point is after reviewing the ledger: keep the setup or change it.

Interactions with other accepted participants. The Focus Planner prepares the state that the Focus Session User then runs with — the saved blocking preference and the session length. The two roles are the same person at different moments, and the handoff between them is the saved blocking preference and the session record. The Focus Planner's review depends on the session records produced by the running-session lifecycle.

Observable success. The prepared blocked-app set appears in the blocking summary on Session Setup, the chosen session length is used by the next session, and Focus History shows a readable ledger of past sessions that the planner can act on.

5. Core User Flows

Flow A — First-time enrollment and first focus session (Focus Session User)

1. The visitor arrives anonymously at Landing. The paper field, the still-life photograph, the tracked label "A QUIETER WAY TO STUDY", the two-line headline, and the hairline rule are visible; the photograph fades in over 600ms.
2. The visitor follows the primary text link, underlined in #B5643C, to Sign Up.
3. On Sign Up, the visitor fills the enrollment rows and submits. The primary action shows a restrained in-progress state.
4. The account is created. The user continues to Session Setup as an identified user with their own blocking preferences and history.
5. On Session Setup, the user sees the blocking summary. Because no apps are selected yet, the summary states that no apps are selected and offers the link to App Blocking.
6. The user follows the link to App Blocking and toggles the apps that distract them. Each toggled row immediately reflects its state and the choice is saved. If a change cannot be saved, the row reverts and an inline message explains it; the user retries.
7. The user returns to Session Setup via the link. The blocking summary now lists the selected apps as ruled rows.
8. The user sets the session length and starts the session. The blocking mechanism activates and the user is taken to Focus Session.
9. On Focus Session, the user sees one enormous timer numeral, the thin ink ring with the slow clay elapsed arc, the running-session dot, and the "end session" link at the bottom edge. Blocking is confirmed active and the session's end is shown.
10. The session runs to its planned end. Blocking is lifted automatically, the previously blocked apps are usable again, and the session is recorded in Focus History.
11. The user returns to Session Setup to start another session, or opens Focus History to see the record.

Failure and recovery: if blocking cannot be confirmed active at step 9, Focus Session states that blocking is not active rather than showing a false running state, and the user can end the session. If the session cannot be started at step 8, an inline message explains it and the start action remains available to retry.

Flow B — Returning user resumes a session (Focus Session User)

1. The returning user arrives at Landing and follows the secondary text link to Login.
2. On Login, the user submits their credentials. The primary action shows a restrained in-progress state.
3. The user is verified and lands on Session Setup with their saved blocking choices and focus-session history available.
4. The user confirms the blocking summary and the session length, then starts the session.
5. On Focus Session, the user sees the running state and the remaining time.
6. Partway through, something genuinely needs the user's attention. The user follows the "end session" link at the bottom edge.
7. The session stops, blocking is lifted, and the previously blocked apps are usable again. The session is recorded with the time actually spent.
8. The user returns to Session Setup to start another session.

Failure and recovery: if the credentials are incorrect at step 2, the error is reported inline without revealing which part was wrong, the entered identifier is preserved, and the user retries. If ending cannot be confirmed at step 7, the page states the session has ended and the user can retry.

Flow C — Preparing the study routine in advance (Focus Planner)

1. The identified user opens App Blocking between study sessions.
2. The user reviews the ruled ledger of apps — name left, flat rectangular toggle right, hairline between each row — and toggles the apps that count as distracting. Each change is saved and the row reflects it immediately.
3. The user opens Session Setup and sets how long focus sessions should run. The chosen length is used by the next session started from that screen.
4. The prepared blocked-app set appears in the blocking summary on Session Setup, ready for the next session.

Failure and recovery: if a toggle change cannot be saved, the row reverts to its previous state and an inline message explains it; the user retries and the rest of the list remains usable. If the session length cannot be applied, an inline message explains it and the start action remains available to retry.

Flow D — Reviewing the record and adjusting the setup (Focus Planner)

1. The identified user opens Focus History.
2. The user reads the printed ledger: date left, duration right in tabular figures, hairline between each row, months as small tracked uppercase labels. No charts and no coloured bars.
3. The user judges whether the blocking setup is helping them study.
4. The user follows the link to App Blocking and adjusts the blocked-app list based on what the ledger shows. Each change is saved.
5. The user returns to Session Setup to run a session with the adjusted set.

Failure and recovery: if the history cannot be loaded at step 2, an inline message explains it and the page remains navigable so the user can retry. If the user has not yet completed a session, the page states that plainly and offers the link to App Blocking as the next step.

6. Visuals Colors and Theme

Muse and headline. Kenya Hara — emptiness as content. The product's whole promise is subtraction, so the interface is a cleared desk, not a dashboard. Every pixel of emptiness is a claim about the product.

Colour tokens (light mode).

No gradients, no glass, no second accent. No blue or indigo anywhere in the palette.

Typography.

• Headings: Zen Kaku Gothic New, Light weight (300), at very large sizes with wide 0.08em tracking. Headings are short, lower-case or sentence-case, never shouted.
• Numbers in the timer: the same family at weight 200 and enormous scale — the timer is the largest type object in the product.
• Body: Noto Serif JP.
• Type scale: 1.5 modular — 40 / 28 / 20 / 15 / 13.
• Display timer: clamp(72px, 22vw, 200px).
• Section headings: clamp(32px, 6vw, 64px).
• Body: 15–17px, line-height 1.9, measure capped at 62ch.
• Labels: 12px, tracking 0.14em, uppercase.

Shape language. Square and near-square proportions only — 2px radii at the absolute maximum, so the composition reads as printed paper rather than UI chrome. Thin 1px hairline rules in #D8D2C6 divide sections the way a ruled page does. The one circular form in the product is the focus dial, and it is a true circle because it is a clock. Controls are flat rectangles with generous internal padding (16px vertical minimum) and no shadows.

Layout. Centered single column on a 12-column grid with unusually wide outer margins (8vw at 1280px, 20px at 375px). One idea per screen, one action per screen. Vertical rhythm is deliberately slow: 96–160px of empty space between sections at desktop, 48–64px at mobile, so scrolling feels like turning pages. The focus dial sits alone in the viewport with nothing beside it. App-blocking lists are plain ruled rows — name left, toggle right, hairline between — never cards. Session history is a quiet ledger of dates and durations in tabular figures, not a chart wall.

Imagery. No illustration, no stock people, no 3D. Imagery is material and still-life: one softly lit photograph of a cleared desk, a single sheet of paper, a stone, or a cup, shot on the same paper ground as the UI so the photo appears to be printed onto the page rather than placed on it. Photographs are used at most once per page and always full-bleed to one edge. Everything else is type, rule and space.

Readable text and controls. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery and decoration may be cropped, bled off an edge, or cut exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The cleared desk. The public entry is a nearly empty paper-coloured field (#F4F1EA) with a single full-bleed still-life photograph bleeding off the right edge — a cleared desk, one closed notebook, morning light — occupying roughly 45% of the viewport at desktop and collapsing to a 40vh band above the fold at 375px. The photograph is the only object on the page, and it is shot on the same paper ground as the UI so it appears printed onto the page rather than placed on it.

The headline sits flush-left in the remaining emptiness at clamp(32px, 6vw, 64px), light weight, two short lines, with a single hairline rule beneath it at exactly the text's width and one 12px tracked label above it reading "A QUIETER WAY TO STUDY". There is no button block, no sub-headline paragraph, no gradient. Beneath the rule sit two text links separated by a thin vertical rule, the primary one underlined in #B5643C.

The dominant element is the emptiness itself. The photograph is the only object, and the type is quiet enough that the space reads as intentional content rather than as a missing layout. The concept recomposes only accepted content — the product's promise, the Sign Up link, and the Login link — and introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the single full-bleed still-life photograph — a cleared desk, one closed notebook, morning light — bleeding off the right edge of the paper field.
• Input → transformation → outcome thesis: the visitor arrives at an almost empty page; the photograph settles in with a 600ms opacity fade as the screen's single object, while the label, headline, hairline rule, and two text links are present immediately; the outcome is a visitor who reads the promise and follows one of the two links. No other motion occurs on the entry.
• Motion vocabulary: a 600ms opacity fade as the screen's single object settles in; a 400ms crossfade when a session state changes; a slow 1s ease on the focus dial's remaining-time arc. No bounce, no spring, no parallax, no hover lift.
• Composed first frame: paper field #F4F1EA; photograph occupying roughly 45% of the viewport at desktop, bleeding off the right edge, collapsing to a 40vh band above the fold at 375px; 12px tracked uppercase label "A QUIETER WAY TO STUDY"; two-line headline flush-left at clamp(32px, 6vw, 64px) in Zen Kaku Gothic New Light; hairline rule in #D8D2C6 at the headline's width; two text links separated by a thin vertical rule, the primary underlined in #B5643C.
• Reduced-motion state: with prefers-reduced-motion, the photograph appears immediately with no fade; the label, headline, rule, and both links are fully readable and usable; the layout is unchanged and no content is hidden or moved.

The only continuous motion in the product is the focus dial's progress arc on Focus Session, which is information, not ornament.

9. Non-Functional Requirements

NFR-1 — Blocking enforcement for the session duration (required_inference) The blocking mechanism must remain active for the whole session duration and must restore blocked-app usability when the session ends. Rationale: the product's core promise is that distracting apps are blocked while studying and usable again afterward; a session that silently stops blocking would break the accepted outcome.

NFR-2 — Truthful session state (required_inference) Focus Session must never display a running state when blocking is not confirmed active. Rationale: the user relies on that screen to know their apps are blocked; a false running state would mislead them about the product's only guarantee.

NFR-3 — Durable, user-bound state (required_inference) Blocking preferences and focus-session history must remain bound to the correct user and be resumable across visits. Rationale: the accepted journeys require a returning user to resume their saved blocking choices and history after verification.

NFR-4 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Rationale: the direction's large display type and full-bleed imagery must not compromise readability.

NFR-5 — Reduced-motion support (explicit, from the creative direction) With prefers-reduced-motion, the product provides a usable static arrangement: the photograph appears immediately with no fade, and all content remains fully readable and usable. Rationale: the direction's motion is minimal but must degrade cleanly.

NFR-6 — Accessible contrast (explicit, from the creative direction) Ink #1C1B18 on the paper ground #F4F1EA provides 14.9:1 contrast for all reading text. Muted #8C8578 is used for metadata and labels only, never for body copy. Rationale: the direction specifies these roles and the contrast figure.

NFR-7 — No gamified or charted presentation (explicit, from the creative direction) No streaks, badges, confetti, or gamified celebration on session completion; no charts, donuts, or coloured bar graphs in focus history. Rationale: the direction's avoid list; focus history is a printed ledger, not a chart wall.

10. Tech Stack

• Frontend: React (custom UI, single-page application) — the product is a custom-UI web application with seven application-owned pages.
• Backend: Python / FastAPI — the server-side service that owns account identity, blocking preferences, focus-session records, and the blocking mechanism's enforcement and restoration.
• Storage: a persistent datastore for account identity, blocking preferences, and focus-session records. The specific engine is not specified by the user; a relational store is a reasonable default for the user-bound records described here. [Default — not specified by user]
• Containerization: Docker / docker-compose for local and deployment packaging. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any source-backed constraint in this project and is therefore not included. [Default — not specified by user]

No source-specified technology choice is overridden or substituted.

11. Assumptions and Constraints

Assumptions.

• A1. The blocking mechanism operates on the user's device or account context in a way that can be activated at session start and released at session end. The exact platform mechanism is not specified by the user. [Default — not specified by user]
• A2. The list of apps available to block on App Blocking is discoverable by the application. The source does not specify how that list is obtained. [Default — not specified by user]
• A3. The two personas are the same person at different moments — running a session versus preparing and reviewing a routine. The source describes them as distinct roles with distinct responsibilities, and this document preserves that distinction without treating them as separate accounts.
• A4. Session length is chosen by the user on Session Setup; the source does not specify a default length or a permitted range. [Default — not specified by user]

Constraints.

• C1. The blocking mechanism must remain active for the session duration and restore blocked-app usability when the session ends. (required_inference)
• C2. Focus Session must not show a running state when blocking is not confirmed active. (required_inference)
• C3. Blocking preferences and focus-session history are bound to the individual user; Session Setup, App Blocking, Focus Session, and Focus History require an identified user. (required_inference)
• C4. Landing, Sign Up, and Login are anonymously reachable. (required_inference)
• C5. No differentiated permissions, roles, or role-based visibility exist. Every identified user controls only their own blocking choices and their own session history. (required_inference)
• C6. No adjacent account-management capabilities — password reset flows, profile editing, social features, team or shared study features — are in the current scope. (explicit exclusion)
• C7. No streaks, badges, confetti, or gamified celebration on session completion; no charts, donuts, or coloured bar graphs in focus history. (explicit, from the creative direction)
• C8. No cards, shadows, hover-lift tiles, or elevation system; no gradients, glassmorphism, blur, or glow; no blue or indigo anywhere in the palette; no rounded pill buttons, badges, or sticker shapes; no illustrated characters, mascots, or 3D renders; no bouncy, springy, or parallax motion. (explicit, from the creative direction)
• C9. The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit, from the creative direction)
• C10. Readable text and controls stay whole at every viewport; imagery and decoration may be cropped or bled off an edge as the direction asks, as long as they cover no readable text or control. (explicit, from the creative direction)

12. Glossary

• Focus session — a timed stretch of study during which the user's selected distracting apps are blocked. It has a start, a planned length, a remaining time, and an end.
• Blocking mechanism — the system responsibility that enforces the user's selected blocking for the whole session duration and restores blocked-app usability when the session ends.
• Blocking preference — the user's saved set of apps that count as distracting and are blocked during focus sessions.
• Blocked-app set — the specific apps blocked for a given focus session, drawn from the user's blocking preference and adjustable before the session starts.
• Blocking summary — the ruled list on Session Setup showing which apps will be blocked for the upcoming session.
• Running-session dot — the single #B5643C accent on Focus Session indicating the session is running.
• Focus dial — the product's single circular form: a thin 1px ink ring with a slow clay-coloured arc for elapsed time, shown on Focus Session.
• Ledger — the printed-ledger presentation used for app blocking rows and focus history: date or name left, value or toggle right, 1px #D8D2C6 hairline between rows, no cards and no charts.
• Paper ground — the #F4F1EA background that carries 70% of every screen.
• Hairline rule — the 1px #D8D2C6 divider used under section headings and between ruled rows; the only divider in the product.
• Identified user — a user who has enrolled at Sign Up or verified at Login, and whose blocking preferences and focus-session history are bound to them.