System Requirements Document for suggestionbox

1. Introduction

SuggestionBox is a platform for students to submit suggestions and complaints anonymously, protecting their privacy throughout. Students log in and can immediately submit feedback, optionally attaching a proposed solution. Submissions are automatically categorized and summarized into folders — for example, a "Cleanliness" folder carrying a brief summary — and the number of folders varies with the categories of feedback actually received. Users can still open any folder to read individual complaints manually.

The product is deliberately as simple and minimalist as possible while keeping a modern, intuitive look. It includes a step-by-step guide covering everything from submitting feedback to viewing previously submitted items. On first launch the app prompts the user to select a language — Indonesian or English — and the entire interface then switches to the chosen language.

The audience is two-fold: students (18–25) who need trust, speed, and zero exposure when speaking up, and staff reviewers who need to triage variable feedback folders. The emotional register is safe, calm, orderly, and slightly institutional but warm — privacy as a promise, not a feature.

2. System Overview

SuggestionBox is delivered as a first-party custom web application with application-owned identity and background automation. The current delivery includes:

• Anonymous student submission. A logged-in student submits a suggestion or complaint, optionally with a proposed solution. The submission is anonymous to protect student privacy.
• Automatic categorization and summarization. Each submission is automatically categorized and summarized into folders. Folder count is not fixed; it varies with the categories of feedback received.
• Folder browsing and manual reading. Reviewers browse the generated folders with their brief summaries and open any folder to read individual complaints manually.
• Student history. Students can return to view previously submitted items.
• Step-by-step guide. A guide covers everything from submitting feedback to viewing previously submitted items.
• First-launch language selection. On first launch the app prompts for Indonesian or English, and the entire interface switches to the chosen language.

Actors. The accepted active-human catalog is closed: Student Submitter and Feedback Reviewer. Background categorization and summarization run as system processes supporting the reviewer's browsing; they are not human actors.

Narrow exclusions. Language selection is limited to Indonesian or English — no other languages. Submissions must remain anonymous; no identity is attached to or displayed with a submission. No adjacent account-management, moderation, voting, or analytics capabilities are in scope.

2a. Product Interpretation and Delivery Boundary

SuggestionBox is a first-party application. Students establish and verify their own identity through the app (self-service enrollment and returning verification), because a student must privately own and resume their own submission history, and because the anonymity promise requires that the app — not an external provider — hold the boundary between a verified student and an unattributed submission. Reviewers reach the folder workspace through the same returning verification, with reviewer authorization provisioned before folder access.

The language choice made on first launch is persisted so the interface remains switched to the chosen language across later journeys.

Categorization and summarization are background automation: they complete or update before generated folders and summaries can be browsed. This is supporting system work, not a human-facing capability.

Everything described in this document is current. No future-horizon capabilities are accepted.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

The page contract is fixed and ordered: Landing, Language Setup, Login, Sign Up, Submit Feedback, My Submissions, Feedback Folders, Folder Details, Guide.

Landing

• Information/state: Anonymous first impression explaining SuggestionBox as a privacy-protecting platform for student suggestions and complaints. Split composition: left 7 columns of type, right 5 columns of a ruled "how it works" index.
• Primary action: Enter the product (proceed toward language setup on first launch, or toward identity access on return).
• Supporting actions: Read the four-step index (01 Submit / 02 We categorize / 03 It lands in a folder / 04 You can read it back).
• Domain entities: None persisted; presents the product promise and the flow diagram Submit → Categorize → Folder → Read.
• Component responsibilities: Hero headline block; two-sentence supporting paragraph; solid orange submit-entry block button; white ruled panel containing the four-step index with hairline separators and Archivo 700 numerals; full-viewport-width 1px black rule beneath the hero; ruled flow diagram drawn with 1px lines and small squares, with the student's node marked by an orange dot and their identity deliberately not drawn.
• States: Loading — static content, no data fetch. Empty — not applicable. Success — page renders fully. Error — not applicable. Recovery — not applicable.

Language Setup

• Information/state: First-launch destination for choosing Indonesian or English. Presents the two permitted options only.
• Primary action: Select Indonesian or English.
• Supporting actions: Confirm the selection so the interface switches.
• Domain entities: Selected language preference (persisted).
• Component responsibilities: Language toggle using the single 6px radius family; 11px uppercase module label; confirmation control.
• States: Loading — static. Empty — not applicable. Success — the entire interface switches to the chosen language with a 240ms fade where every string swaps in place rather than sliding. Error — selection not registered; the user can re-select. Recovery — re-select either language; the choice persists once registered.

Login

• Information/state: Returning verification surface for both Student Submitter and Feedback Reviewer. Anonymous entry — this page does not itself require an established session.
• Primary action: Verify returning identity.
• Supporting actions: Move to Sign Up when the student has no prior enrollment.
• Domain entities: Student identity credential; reviewer identity credential; session continuity.
• Component responsibilities: Label/value credential rows (11px uppercase label flush-left, control right-aligned on a shared baseline); verification submit control; link to Sign Up.
• States: Loading — verification in progress. Empty — not applicable. Success — identity verified; the student continues to Submit Feedback or My Submissions, the reviewer continues to Feedback Folders. Error — credentials not recognized; a plain message is shown and the fields remain editable. Recovery — retry verification or proceed to Sign Up.

Sign Up

• Information/state: First-use enrollment path for a self-starting student, because no external provisioning or pre-existing account boundary is established.
• Primary action: Establish a student identity.
• Supporting actions: Return to Login if already enrolled.
• Domain entities: Student identity credential.
• Component responsibilities: Label/value enrollment rows; enrollment submit control; link back to Login.
• States: Loading — enrollment in progress. Empty — not applicable. Success — identity established; the student continues to Login for returning verification, then to protected submission and history. Error — enrollment rejected (for example, incomplete required input); a plain message is shown. Recovery — correct the input and resubmit, or return to Login.

Submit Feedback

• Information/state: Focused student workspace for submitting an anonymous suggestion or complaint with an optional proposed solution. Single-column form of stacked label/value rows. Role-restricted to the Student Submitter.
• Primary action: Submit the feedback.
• Supporting actions: Attach an optional proposed solution; review the entered text before submitting.
• Domain entities: Feedback submission (suggestion or complaint text; optional proposed solution; anonymous status).
• Component responsibilities: 11px uppercase label flush-left with the control right-aligned on a shared baseline; submission textarea with line length capped at 68ch; optional proposed-solution field; anonymous-status dot in signal orange; solid orange submit block button with a 2px inset bottom edge on press.
• States: Loading — submission in flight. Empty — blank form with the optional solution field clearly optional. Success — the submission is accepted and confirmed; the student continues to My Submissions or submits another item. Error — submission not accepted; the entered text is preserved and a plain message is shown. Recovery — correct and resubmit without re-entering the text.

My Submissions

• Information/state: Revisitable student destination for viewing previously submitted items. Role-restricted to the Student Submitter.
• Primary action: Read a previously submitted item.
• Supporting actions: Return to Submit Feedback to add another item.
• Domain entities: The student's own prior submissions, each with its text, optional proposed solution, and anonymous status.
• Component responsibilities: Ordered list of the student's own items separated by 1px hairline rules; label/value metadata rows with tabular numerals; "solution proposed" tag in deep green #1F5C4A.
• States: Loading — history being retrieved. Empty — no prior submissions; a plain statement with a route to Submit Feedback. Success — the student's items are listed and readable. Error — history could not be retrieved; a plain message with retry. Recovery — retry retrieval; the student can still proceed to Submit Feedback.

Feedback Folders

• Information/state: Reviewer workspace for browsing variable automatically generated folders and reading their brief summaries. Role-restricted to the Feedback Reviewer, who must be provisioned with reviewer authorization before access.
• Primary action: Open a folder to read its individual complaints.
• Supporting actions: Read each folder's brief summary; read the active folder count.
• Domain entities: Generated folders (category name, count, one-line summary clamped to two lines); the active folder count.
• Component responsibilities: Dense ordered grid of flat white folder cards, each with a 3px left edge in the category's signal hue, category name, count in Archivo 700 tabular figures, and a two-line auto-summary; 90ms background tint on hover (#16181A at 4%); active folder count in signal orange; small geometric glyphs (square, triangle, circle, half-circle) rather than emoji or illustration.
• States: Loading — folders and summaries being retrieved. Empty — no folders yet because no feedback has been categorized; a plain statement. Success — folders render with names, counts, and summaries. Error — folders could not be retrieved; a plain message with retry. Recovery — retry retrieval; the reviewer can reopen the workspace.

Folder Details

• Information/state: Reviewer destination for opening a folder and manually reading its individual complaints. Two-pane split at 1280px (list left, selected complaint right), collapsing to a single stacked column at 768px and 375px, with the list becoming a horizontally scrollable row of compact complaint chips. Role-restricted to the Feedback Reviewer.
• Primary action: Select and read an individual complaint.
• Supporting actions: Move between complaints in the folder; return to Feedback Folders.
• Domain entities: The folder's individual complaints, each with its text and optional proposed solution; the folder's category name and count.
• Component responsibilities: Complaint list pane; selected-complaint reading pane with a subtle ruled-paper texture at 3% opacity behind complaint bodies to signal "document"; label/value metadata rows with tabular numerals; "solution proposed" tag in deep green; hairline rules between complaints.
• States: Loading — complaints being retrieved. Empty — the folder contains no readable complaints; a plain statement. Success — complaints are listed and the selected one is readable. Error — complaints could not be retrieved; a plain message with retry. Recovery — retry retrieval or return to Feedback Folders.

Guide

• Information/state: Step-by-step guide covering everything from submitting feedback to viewing previously submitted items. Role-restricted to the Student Submitter.
• Primary action: Read the steps in order.
• Supporting actions: Move to the relevant destination from a step.
• Domain entities: The four-step guide (submit → categorize → browse folders → open a folder to read individual complaints).
• Component responsibilities: Numbered ruled index with hairline separators and counting-up numerals; 11px uppercase module labels ("STEP 2"); step bodies in Fira Sans.
• States: Loading — static. Empty — not applicable. Success — the numbered index renders and the numerals count up once on scroll-into-view. Error — not applicable. Recovery — not applicable.

3. Functional Requirements

FR-1 — Anonymous student submission platform (explicit) As a Student Submitter, I should submit suggestions and complaints anonymously so that my privacy is protected.

• Trigger/input: The student has verified identity and opens Submit Feedback.
• Observable result: A suggestion or complaint is accepted with no identity attached to or displayed with it.
• Access state: Role-restricted to the Student Submitter; requires verified identity.
• Failure/recovery: If the submission is not accepted, the entered text is preserved and a plain message is shown; the student corrects and resubmits.
• Continuation: The student proceeds to My Submissions or submits another item.

FR-2 — Log in and immediately submit feedback with optional proposed solution (explicit) As a Student Submitter, I should log in and immediately submit my feedback, including an optional proposed solution, so that speaking up takes as little effort as possible.

• Trigger/input: The student verifies returning identity on Login, then opens Submit Feedback.
• Observable result: The submission is accepted; the optional proposed solution is stored with it when provided, and its presence is marked with a "solution proposed" tag.
• Access state: Role-restricted to the Student Submitter; requires verified identity.
• Failure/recovery: If verification fails, the student retries or proceeds to Sign Up; if the submission fails, the text is preserved.
• Continuation: The student continues to My Submissions or submits another item.

FR-3 — Automatic categorization and summarization into folders (explicit) As a Feedback Reviewer, I should have submissions automatically categorized and summarized into folders, each carrying a brief summary, so that I can understand incoming feedback without reading every item first.

• Trigger/input: A submission is accepted.
• Observable result: The submission is placed in a category folder with a brief summary; for example, a "Cleanliness" folder with a brief summary.
• Access state: Background system process; results are visible to the provisioned Feedback Reviewer on Feedback Folders.
• Failure/recovery: If categorization or summarization has not completed, the folder and summary are not yet browsable; the reviewer retries retrieval.
• Continuation: The reviewer browses the generated folders.

FR-4 — Open folders to view individual complaints manually (explicit) As a Feedback Reviewer, I should open a folder and read its individual complaints manually, so that I can examine the underlying feedback rather than only the summary.

• Trigger/input: The reviewer selects a folder on Feedback Folders.
• Observable result: Folder Details lists the folder's individual complaints and the selected complaint is readable.
• Access state: Role-restricted to the Feedback Reviewer; requires provisioned reviewer authorization.
• Failure/recovery: If complaints cannot be retrieved, a plain message with retry is shown; the reviewer can return to Feedback Folders.
• Continuation: The reviewer moves between complaints or returns to Feedback Folders.

FR-5 — Variable folder count (explicit) As a Feedback Reviewer, I should see a number of folders that varies with the categories of feedback received, so that the folder structure reflects the actual feedback rather than a fixed taxonomy.

• Trigger/input: Submissions are categorized over time.
• Observable result: The set and count of folders on Feedback Folders changes as categories of feedback are received.
• Access state: Role-restricted to the Feedback Reviewer.
• Failure/recovery: If folders cannot be retrieved, a plain message with retry is shown.
• Continuation: The reviewer browses the current folder set.

FR-6 — Simple, minimalist, modern, intuitive design (explicit) As a Student Submitter, I should use an interface that is as simple and minimalist as possible while maintaining a modern, intuitive look, so that the app stays out of the way of speaking up.

• Trigger/input: Any interaction with the app.
• Observable result: Every surface follows the single 6px radius family, hairline rule system, label/value rows, and reserved signal-orange meaning.
• Access state: Applies to all pages.
• Failure/recovery: Not applicable.
• Continuation: Not applicable.

FR-7 — Step-by-step guide (explicit) As a Student Submitter, I should read a step-by-step guide covering everything from submitting feedback to viewing previously submitted items, so that I know how the whole flow works.

• Trigger/input: The student opens Guide.
• Observable result: A numbered ruled index presents the steps from submitting feedback through viewing previously submitted items.
• Access state: Role-restricted to the Student Submitter.
• Failure/recovery: Not applicable.
• Continuation: The student moves to the relevant destination from a step.

FR-8 — First-launch language selection (explicit) As a Student Submitter, I should be prompted on first launch to select Indonesian or English, so that I can use the app in my language.

• Trigger/input: First launch of the app.
• Observable result: Language Setup presents exactly Indonesian and English.
• Access state: Anonymous; no identity required.
• Failure/recovery: If the selection is not registered, the user re-selects either language.
• Continuation: The interface switches to the chosen language.

FR-9 — Entire interface switches to the chosen language (explicit) As a Student Submitter, I should have the entire interface switch to the chosen language, so that every string I read is in that language.

• Trigger/input: A language is selected on Language Setup.
• Observable result: Every string across the interface swaps in place to the chosen language with a 240ms fade.
• Access state: Applies to all pages.
• Failure/recovery: If the switch does not take effect, the user re-selects the language.
• Continuation: The user continues in the chosen language.

FR-10 — First-use enrollment before returning verification (required_inference) As a Student Submitter, I should complete first-use enrollment before returning verification and protected submission or history access, so that my own history can be bound to me while my submissions stay anonymous.

• Trigger/input: The student has no prior enrollment and opens Sign Up.
• Observable result: A student identity is established; the student then passes Login before protected access.
• Access state: Sign Up is anonymously reachable; protected destinations remain unavailable until identity is established.
• Failure/recovery: If enrollment is rejected, a plain message is shown and the student corrects the input or returns to Login.
• Continuation: The student proceeds to Login, then to Submit Feedback or My Submissions.

FR-11 — Returning verification before protected access (required_inference) As a Student Submitter, I should pass Login before submitting feedback or viewing previously submitted items, so that my history remains mine.

• Trigger/input: The student opens Login.
• Observable result: Identity is verified and protected destinations become available.
• Access state: Login is anonymously reachable; Submit Feedback and My Submissions require verified identity.
• Failure/recovery: If credentials are not recognized, a plain message is shown and the student retries or proceeds to Sign Up.
• Continuation: The student continues to Submit Feedback or My Submissions.

FR-12 — Reviewer authorization provisioning (required_inference) As a Feedback Reviewer, I should be provisioned with reviewer authorization before accessing Feedback Folders or Folder Details, so that folder review stays with the correct participant.

• Trigger/input: The reviewer verifies returning identity on Login.
• Observable result: Reviewer authorization is present and the folder workspace becomes available.
• Access state: Feedback Folders and Folder Details are role-restricted to the provisioned Feedback Reviewer.
• Failure/recovery: If authorization is absent, the folder workspace remains unavailable and the reviewer returns to Login.
• Continuation: The reviewer browses Feedback Folders.

FR-13 — Persisted language choice (required_inference) As a Student Submitter, I should have my selected Indonesian or English language persist, so that the interface remains switched to the chosen language across later journeys.

• Trigger/input: A language is selected on Language Setup.
• Observable result: Later journeys render in the chosen language without re-prompting.
• Access state: Applies to all pages.
• Failure/recovery: If the persisted choice is unavailable, the user re-selects the language.
• Continuation: The user continues in the chosen language.

FR-14 — Categorization and summarization complete before browsing (required_inference) As a Feedback Reviewer, I should have background categorization and summarization complete or update before generated folders and summaries can be browsed, so that what I read reflects the current feedback.

• Trigger/input: A submission is accepted.
• Observable result: Folders and summaries become browsable once the background work completes or updates.
• Access state: Background system process; results visible to the provisioned Feedback Reviewer.
• Failure/recovery: If the work has not completed, the folder and summary are not yet browsable; the reviewer retries retrieval.
• Continuation: The reviewer browses the generated folders.

4. User Personas

Student Submitter

Product context. A student (18–25) at a school or university who needs to raise a suggestion or complaint without exposure. The app is a utility for them, not a destination: they arrive, say the thing, and leave. Trust is the precondition — anonymity must feel engineered, not marketed.

Primary goal. Submit a suggestion or complaint anonymously, optionally with a proposed solution, and be able to return later to view previously submitted items.

Distinct accepted responsibilities. This role is the only one that creates feedback. It initiates submissions, decides whether to attach a proposed solution, and owns its own submission history. It also owns the first-launch language decision and reads the step-by-step guide.

Relevant inputs or decisions. The feedback text; whether to attach an optional proposed solution; the choice of Indonesian or English on first launch; the decision to enroll on first use versus verify as a returning student.

Interactions with other accepted participants. The Student Submitter does not interact directly with the Feedback Reviewer. The relationship is one-directional and deliberately unattributed: the student's submission becomes the reviewer's categorized material, and the student's identity is never attached to it. The student's own observable success is that the submission is accepted and later readable in My Submissions.

Observable success. The submission is accepted with no identity attached, the optional proposed solution is stored and marked when provided, and the item appears in My Submissions on return.

What makes this role different. The Student Submitter is the only participant whose work is protected by anonymity and whose history is private to them. Their success is measured by the absence of exposure, not by any downstream outcome.

Feedback Reviewer

Product context. A staff reviewer who needs to triage variable feedback folders. They never submit anything; their work is reading. They need the folder structure to reflect the actual feedback received rather than a fixed taxonomy, and they need to be able to drop from a summary into the underlying complaints.

Primary goal. Understand the categorized feedback by browsing generated folders with their brief summaries and opening folders to read individual complaints manually.

Distinct accepted responsibilities. This role browses the folder set, reads each folder's brief summary, reads the active folder count, opens a folder, selects individual complaints, and moves between them. It is the only role that reads other people's submissions.

Relevant inputs or decisions. Which folder to open; which complaint to select and read; whether to move to another complaint or return to the folder list.

Interactions with other accepted participants. The Feedback Reviewer receives the Student Submitter's categorized material but never sees who submitted it. The reviewer's access is provisioned with reviewer authorization before the folder workspace is available.

Observable success. Folders render with names, counts, and brief summaries; opening a folder lists its individual complaints and the selected complaint is readable.

What makes this role different. The Feedback Reviewer is the only participant who reads across submissions and the only one whose access depends on provisioned reviewer authorization. Their success is comprehension of the categorized whole, not the act of speaking up.

5. Core User Flows

Flow 1 — First launch and language selection (Student Submitter)

1. The student launches SuggestionBox for the first time and lands on Landing, which explains SuggestionBox as a privacy-protecting platform for student suggestions and complaints.
2. The student proceeds to Language Setup, the first-launch destination.
3. The student selects Indonesian or English — the only two permitted options.
4. The entire interface switches to the chosen language with a 240ms fade where every string swaps in place rather than sliding.
5. The choice persists, so later journeys render in the chosen language without re-prompting.
6. Failure/recovery: If the selection is not registered, the student re-selects either language; the choice persists once registered.
7. Continuation: The student continues toward identity access.

Flow 2 — First-use enrollment (Student Submitter)

1. The student has no prior enrollment and opens Sign Up from Login.
2. The student enters the required enrollment input in the label/value rows.
3. The student submits the enrollment.
4. A student identity is established.
5. Failure/recovery: If enrollment is rejected (for example, incomplete required input), a plain message is shown; the student corrects the input and resubmits, or returns to Login.
6. Continuation: The student proceeds to Login for returning verification, then to protected submission and history.

Flow 3 — Log in and immediately submit feedback (Student Submitter)

1. The student opens Login and verifies returning identity.
2. On success, the student continues directly to Submit Feedback — the focused workspace for submitting an anonymous suggestion or complaint.
3. The student enters the feedback text in the submission textarea, with line length capped at 68ch.
4. The student decides whether to attach an optional proposed solution and, if so, enters it in the optional proposed-solution field.
5. The student presses the solid orange submit block button, which shows a 2px inset bottom edge on press.
6. The submission is accepted and confirmed; no identity is attached to or displayed with it. When a proposed solution was provided, it is stored and marked with a "solution proposed" tag in deep green.
7. Failure/recovery: If verification fails, a plain message is shown and the student retries or proceeds to Sign Up. If the submission is not accepted, the entered text is preserved and a plain message is shown; the student corrects and resubmits without re-entering the text.
8. Continuation: The student continues to My Submissions or submits another item.

Flow 4 — View previously submitted items (Student Submitter)

1. The student opens My Submissions with verified identity.
2. The student's own prior submissions are retrieved and listed in order, separated by 1px hairline rules, with label/value metadata rows using tabular numerals.
3. The student reads a previously submitted item, including its optional proposed solution where one was provided, marked with the deep green "solution proposed" tag.
4. Failure/recovery: If history could not be retrieved, a plain message with retry is shown; the student retries retrieval or proceeds to Submit Feedback.
5. Continuation: The student returns to Submit Feedback to add another item, or ends the session.

Flow 5 — Read the step-by-step guide (Student Submitter)

1. The student opens Guide.
2. The numbered ruled index presents the steps in order — submit → categorize → browse folders → open a folder to read individual complaints — with hairline separators and counting-up numerals that count up once on scroll-into-view.
3. The student reads the steps covering everything from submitting feedback to viewing previously submitted items.
4. Continuation: The student moves to the relevant destination from a step.

Flow 6 — Browse generated folders (Feedback Reviewer)

1. The reviewer opens Login and verifies returning identity.
2. Reviewer authorization is present, so the folder workspace becomes available.
3. The reviewer opens Feedback Folders, which retrieves the generated folders and their brief summaries.
4. The reviewer reads the dense ordered grid of flat white folder cards — each with a 3px left edge in the category's signal hue, the category name, the count in Archivo 700 tabular figures, and a two-line auto-summary — and reads the active folder count in signal orange.
5. The set and count of folders varies with the categories of feedback received; for example, a "Cleanliness" folder with a brief summary.
6. Failure/recovery: If folders could not be retrieved, a plain message with retry is shown; the reviewer retries retrieval. If no feedback has been categorized yet, a plain statement explains that no folders exist yet.
7. Continuation: The reviewer opens a folder.

Flow 7 — Open a folder and read individual complaints manually (Feedback Reviewer)

1. The reviewer selects a folder on Feedback Folders.
2. Folder Details opens with the folder's category name and count, listing its individual complaints.
3. At 1280px the reviewer sees a two-pane split — list left, selected complaint right; at 768px and 375px it collapses to a single stacked column, with the list becoming a horizontally scrollable row of compact complaint chips.
4. The reviewer selects an individual complaint and reads it manually, with a subtle ruled-paper texture at 3% opacity behind the complaint body to signal "document".
5. The reviewer moves between complaints in the folder, reading each one's text and optional proposed solution where provided, marked with the deep green "solution proposed" tag.
6. Failure/recovery: If complaints could not be retrieved, a plain message with retry is shown; the reviewer retries retrieval or returns to Feedback Folders. If the folder contains no readable complaints, a plain statement is shown.
7. Continuation: The reviewer returns to Feedback Folders to open another folder.

Flow 8 — Background categorization and summarization (system process)

1. A submission is accepted on Submit Feedback.
2. Background categorization and summarization run as a system process.
3. The submission is placed in a category folder with a brief summary; for example, a "Cleanliness" folder with a brief summary.
4. The folder and summary become browsable on Feedback Folders once the background work completes or updates.
5. Failure/recovery: If the work has not completed, the folder and summary are not yet browsable; the reviewer retries retrieval.
6. Continuation: The reviewer browses the generated folders.

6. Visuals Colors and Theme

Muse and headline. Dieter Rams — Less, but better — a quiet instrument for anonymous student voice. The direction is authoritative for this section. SuggestionBox is a utility with a trust problem: anonymity must feel engineered, not marketed. Rams' language — strict grid, honest controls, muted surfaces, one saturated signal accent — reads as a trustworthy instrument rather than a startup product. The result is a minimalist interface with a distinct personality: warm grey paper, black type, one orange signal for the act of speaking up.

Palette (light mode).

Proportion: 70% background, 20% white surface, 8% ink, 2% signal. Signal orange #E4572E is reserved for exactly three meanings: the primary submit action, the active folder count, and focus rings, plus the anonymous-status dot. Deep green #1F5C4A carries confirmation states and "solution proposed" tags so orange never has to mean two things. No gradients anywhere; colour is either a flat block or a 1px rule.

Typography.

• Headings: Archivo at 600–700, tight tracking (-0.02em), sentence case for headlines and UPPERCASE with +0.08em tracking at 11–12px for module labels ("FEEDBACK", "FOLDERS", "STEP 2"). Headline scale: clamp(34px, 6vw, 64px) on the landing hero, clamp(24px, 3.4vw, 40px) for page titles. Numbers (folder counts, complaint totals) set in Archivo 700 with tabular figures so columns align like a control panel.
• Body: Fira Sans.
• Scale: 1.25 modular on a 4pt baseline — 64/40/28/20/16/14/12 with 11px uppercase micro-labels. Body 16px/1.6; labels 12px/1.3 uppercase; line length capped at 68ch for the submission textarea and complaint bodies.

Shape language. Rounded-rectangle controls with a single 6px radius — the same radius on inputs, buttons, folder cards, and the language toggle, so the whole app reads as one machined family. 1px hairline rules (#E0DDD6) separate every module instead of shadows. Buttons are solid blocks with a 2px inset bottom edge on press (mechanical, not bouncy). Folder cards are flat white rectangles with a 3px left edge in the category's signal colour; no drop shadows, no lift, no pills.

Layout. A 12-column modular grid, max content width 1120px, 24px gutters at 375px and 40px at 1280px. Landing is asymmetric: 7 columns of type, 5 columns of a ruled "how it works" index. Submit Feedback is a single-column form of stacked label/value rows — label in 11px uppercase left, control right-aligned on a shared baseline. Feedback Folders is a dense ordered grid of flat cards, each showing category name, count in tabular figures, and a one-line summary clamped to two lines. Folder Details is a two-pane split at 1280px (list left, selected complaint right) that collapses to a single stacked column at 768px and 375px, with the list becoming a horizontally scrollable row of compact complaint chips.

Imagery style. Diagrammatic, not photographic. A ruled "flow diagram" on the landing page drawn with 1px lines and small squares showing Submit → Categorize → Folder → Read, with the student's node marked by an orange dot and their identity deliberately not drawn. Category folder cards carry small geometric glyphs (a square, a triangle, a circle, a half-circle) rather than emoji or illustration. Folder Details uses a subtle ruled-paper texture at 3% opacity behind complaint bodies to signal "document", never stock photos of students.

Avoid. Blue/indigo primary on white (the #2563EB SaaS default); Inter, Roboto, Poppins, Open Sans or system-ui for headings or body; drop shadows, hover-lift cards, glassmorphism and gradient blobs; rounded pill buttons and 16px+ radii; emoji or illustrated characters standing in for category icons; a centred hero with headline, subtext and button stacked in the middle; decorative animation, parallax or bouncing micro-interactions; photographs of students or stock imagery anywhere in the product.

Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, cards' text 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, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut exactly as the direction asks, as long as it covers no readable text or control. Moving and scrollable content may cross the viewport or container edge by design: it is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. With prefers-reduced-motion it stops and shows whole items: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.

7. Signature Design Concept

The ruled instrument. The public entry is a split composition, not a centred stack. The left 7 columns carry a 64px Archivo headline — "Speak up. Stay unknown." — set flush-left across four ragged lines, with a 16px Fira Sans paragraph of two sentences beneath it, and a solid orange #E4572E "Submit a suggestion" block button pinned directly under the text with no vertical gap larger than 24px. The right 5 columns hold a white panel ruled with 1px lines containing the four-step index — 01 Submit / 02 We categorize / 03 It lands in a folder / 04 You can read it back — each step separated by a hairline, the numerals in Archivo 700 at 28px. A single 1px black rule runs the full viewport width beneath the hero, separating it from the body.

The signature is the hairline rule system: every module on every page is separated by 1px #E0DDD6 rules instead of cards-with-shadows, so the app looks like a printed control panel at 375px, 768px and 1280px. The ruled flow diagram — Submit → Categorize → Folder → Read, drawn with 1px lines and small squares, the student's node marked by an orange dot and their identity deliberately not drawn — is the concept's argument made visible: the student is present in the flow and absent from the record. No gradient, no blob, no centred subtext-plus-button cluster, no hero image.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief. The focal subject is the ruled four-step index in the right-hand white panel, with the ruled flow diagram beneath the hero. The input→transformation→outcome thesis: as the reader scrolls the index into view, the step numerals count up once — 01, 02, 03, 04 — transforming a static ruled list into a sequence that reads as a process, so the outcome is that the reader understands the flow Submit → Categorize → Folder → Read without any element moving across the screen. The motion vocabulary is instant, mechanical feedback only: 120ms linear state changes, a 1px press displacement on buttons, a 240ms fade for the language switch where every string swaps in place rather than sliding, and a 90ms background tint on folder-card hover (#16181A at 4%). Nothing bounces, nothing floats, no parallax. The composed first frame is the full split hero at rest: headline flush-left across four ragged lines, two-sentence paragraph, orange block button, and the white ruled panel with its four hairline-separated steps and Archivo 700 numerals — all readable and whole at 375px, 768px and 1280px. The reduced-motion state is the same first frame with the numerals already at their final values and no count-up: the index renders complete, the language switch swaps strings without the fade, and the folder-card hover tint is omitted.

9. Non-Functional Requirements

NFR-1 — Anonymity of submissions (explicit) Submissions must be anonymous to protect student privacy. No identity is attached to or displayed with a submission, and the landing flow diagram deliberately does not draw the student's identity. Rationale: this is the product's core promise and an explicit hard constraint.

NFR-2 — Minimalist, modern, intuitive interface (explicit) The interface must be as simple and minimalist as possible while maintaining a modern, intuitive look. Rationale: explicit hard constraint; realized through the hairline rule system, the single 6px radius family, label/value rows, and reserved signal-orange meaning.

NFR-3 — Language selection limited to Indonesian or English (explicit) Language selection is limited to Indonesian or English. No other languages are offered. Rationale: explicit hard constraint.

NFR-4 — Entire interface switches to the chosen language (explicit) The entire interface must switch to the chosen language after selection, and the choice persists so later journeys remain in that language. Rationale: explicit hard constraint plus the persistence needed to keep it true across journeys.

NFR-5 — Readable text and controls stay whole (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: direction-level accessibility and legibility constraint.

NFR-6 — Reduced-motion support (explicit, from the creative direction) With prefers-reduced-motion, motion stops and whole items are shown: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling. Rationale: direction-level accessibility constraint.

NFR-7 — Background categorization before browsing (required_inference) Background categorization and summarization must complete or update before generated folders and summaries can be browsed. Rationale: without this ordering, the reviewer could read a folder set that does not reflect the current feedback, breaking the accepted browsing outcome.

NFR-8 — Identity continuity for private history and reviewer authorization (required_inference) A student must complete first-use enrollment before returning verification and protected submission or history access, and a reviewer must be provisioned with reviewer authorization before accessing Feedback Folders or Folder Details. Rationale: a student's history must remain bound to the correct participant while submissions stay unattributed, and folder review must stay with the correct participant.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults for the accepted delivery shape (first-party custom UI, application-owned identity, background automation):

• Frontend: React — a single-page application serving the nine contracted pages, with the 12-column modular grid, hairline rule system, and the Archivo/Fira Sans type scale.
• Backend: Python with FastAPI — submission intake, identity enrollment and verification, reviewer authorization provisioning, and the folder/summary read endpoints.
• Storage: A relational database for student identities, submissions, generated folders, and summaries, plus a durable store for the persisted language preference.
• Background automation: A background worker performing categorization and summarization after a submission is accepted, writing folders and brief summaries that the reviewer workspace reads.
• Packaging: Docker and docker-compose for local and single-host deployment.

Kubernetes is not required by any accepted requirement and is therefore not included.

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference). Students self-enroll through Sign Up because no external provisioning or pre-existing account boundary is established by the source.
• A-2 (required_inference). Reviewers are provisioned with reviewer authorization outside the student self-enrollment path; the source does not describe how provisioning occurs, only that folder access is reviewer work.
• A-3 (required_inference). The language choice is persisted locally or with the student's identity so that later journeys remain in the chosen language.
• A-4 (required_inference). Categorization and summarization run as background automation after a submission is accepted, and their results are what the reviewer browses.
• A-5 (required_inference). A student's own submission history is bound to their verified identity, while the submission content itself carries no identity — this is what makes "view previously submitted items" possible without breaking anonymity.

Constraints

• C-1 (explicit). Submissions must be anonymous to protect student privacy.
• C-2 (explicit). The interface must be as simple and minimalist as possible while maintaining a modern, intuitive look.
• C-3 (explicit). Language selection is limited to Indonesian or English.
• C-4 (explicit). The entire interface must switch to the chosen language after selection.
• C-5 (explicit). The number of folders varies based on the categories of feedback received — no fixed folder taxonomy.
• C-6 (explicit). A step-by-step guide must cover everything from submitting feedback to viewing previously submitted items.
• C-7 (direction). The generic indigo/blue-on-white SaaS template is forbidden for this project; the palette is warm grey paper with signal orange and deep green, and the type is Archivo and Fira Sans.

12. Glossary

• SuggestionBox — The product: a platform for students to submit suggestions and complaints anonymously.
• Student Submitter — The accepted persona who logs in, submits anonymous feedback with an optional proposed solution, and views previously submitted items.
• Feedback Reviewer — The accepted persona who browses automatically generated folders and reads individual complaints manually.
• Submission — A suggestion or complaint submitted anonymously by a Student Submitter, optionally carrying a proposed solution.
• Proposed solution — An optional attachment to a submission, marked with a deep green "solution proposed" tag when present.
• Folder — An automatically generated category container holding submissions, carrying a category name, a count, and a brief summary. The number of folders varies with the categories of feedback received.
• Brief summary — The short auto-generated description shown on a folder card, clamped to two lines.
• Categorization and summarization — The background automation that places an accepted submission into a category folder and produces that folder's brief summary.
• Anonymous-status dot — The signal-orange indicator marking the anonymous state of a submission.
• Language Setup — The first-launch destination where the user selects Indonesian or English.
• Guide — The step-by-step numbered ruled index covering everything from submitting feedback to viewing previously submitted items.
• Hairline rule system — The 1px #E0DDD6 rules that separate every module instead of cards-with-shadows.
• Signal orange — #E4572E, reserved for the primary submit action, the active folder count, focus rings, and the anonymous-status dot.
• Deep green — #1F5C4A, the secondary signal for confirmation states and "solution proposed" tags.