System Requirements Document for school-management-educonnect

1. Introduction

Educonnect is school management software that handles the entire school ecosystem. It serves a single institution's daily life — its staff, its classrooms, its students and its families — through two coordinated delivery surfaces:

• An Admin dashboard web app for the school administrator who runs school-wide records and operations.
• A mobile app for Teachers, Principals and Parents, each of whom reaches their own protected, role-specific view of school life from a phone.

The product intent is to give every person in a school one connected place to do their part: the Admin keeps the institution's records and operations in order from a consolidated dashboard; the Teacher manages their classes and students between lessons; the Principal oversees school-wide operations and outcomes; the Parent follows their child's school activity and progress. The audience is school staff and families, not enterprise buyers, so the product is warm, legible and calm rather than clinical or corporate.

The product name is Educonnect.

2. System Overview

Educonnect is delivered as two first-party application surfaces backed by a shared application backend:

• Web (Admin): a dashboard web app where the Admin signs in and works with school-wide records and a consolidated view of school activity.
• Mobile (Teacher, Principal, Parent): a mobile app where each signed-in role reaches its own protected destinations — classes and students for the Teacher, school-wide oversight for the Principal, and a child's school activity and progress for the Parent.

All four personas are active human actors. Identity is application-owned: the Admin is provisioned or invited by the school and signs in through Admin Login; Teachers, Principals and Parents sign in through Mobile Login. An anonymous Landing page explains what Educonnect is, who it is for and what it does before any identity is established.

Current scope covers: the public Landing entry, the two identity-access surfaces, the Admin's Dashboard and Records management of school ecosystem records (staff, students, classes and school operations), the Teacher's My Classes and My Students, the Principal's Oversight, and the Parent's My Child.

Narrow exclusions: no separate public self-enrollment path for the Admin role; no third-party or provider-owned identity surface; no capabilities beyond the accepted school-ecosystem management, oversight and family-following behaviors described in this document.

2a. Product Interpretation and Delivery Boundary

Educonnect is one product with two delivery shapes, and that split is a hard constraint rather than a preference. The Admin's work is a desk-bound, record-heavy job, so it is delivered as a web dashboard. The Teacher, Principal and Parent work happens between lessons, in corridors, at breakfast, so it is delivered as a mobile app. Both surfaces read and write the same school state through one shared backend, so a record the Admin maintains is the same record a Teacher sees in their class list and a Parent sees on their child's page.

Access is application-owned. The Landing page is the only anonymously reachable surface; it establishes what Educonnect is and routes each visitor toward the correct sign-in. Admin Login is the web entry into protected school-wide management state, and the Admin account is provisioned or invited by the school rather than self-started, because the Admin role controls school-wide records. Mobile Login is the single mobile entry for Teacher, Principal and Parent, and the signed-in role determines which protected destinations that person reaches. Protected destinations are never reachable before identity is established.

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

2b. Source Content Inventory

Not applicable. The only reference directive for this project is an inspiration-only Figma sample link that was requested but never supplied; it carries no factual content to inventory.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains what Educonnect is, who it is for (Admin, Teacher, Principal, Parent) and what it does, before any identity is established. No protected school state is shown.
• Primary action: Route the visitor toward the correct identity surface — Admin Login for the web dashboard, Mobile Login for the mobile app.
• Supporting actions: Read the role explanation; move between the hero, the role strip and the sign-in routing.
• Domain entities: Role (Admin, Teacher, Principal, Parent); delivery surface (web dashboard, mobile app).
• Component responsibilities: Asymmetric two-column hero (oversized headline left, modular illustration scene right, bleeding off the right edge on a chalkboard-green rounded block); single tangerine pill CTA; role chip strip; wavy handwritten section dividers; sign-in routing controls.
• States: Loading — static content, no data fetch. Empty — not applicable. Success — visitor understands the product and reaches a sign-in surface. Error — if a sign-in route is unavailable, the routing control states the failure and remains retryable. Recovery — visitor can re-attempt routing or continue reading the page.

Admin Login

• Information/state: Anonymous identity-access surface for the Admin role. Collects Admin credentials and reports verification state.
• Primary action: Admin verifies identity and enters the protected web dashboard.
• Supporting actions: Correct a failed credential entry; return to Landing.
• Domain entities: Admin identity; provisioned/invited Admin account.
• Component responsibilities: Credential form with pill inputs; submit control; inline verification and error messaging; link back to Landing.
• States: Loading — verification in progress, submit disabled. Empty — form awaiting input. Success — identity verified, Admin routed to Dashboard. Error — invalid credentials or unprovisioned account, with a clear message and no access to protected state. Recovery — Admin re-enters credentials; if the account is not provisioned, the message directs them to their school's provisioning contact.

Mobile Login

• Information/state: Anonymous identity-access surface for Teacher, Principal and Parent. Collects mobile credentials and reports verification state; the verified role determines which protected mobile destinations open.
• Primary action: Teacher, Principal or Parent verifies identity and enters their protected role-specific mobile state.
• Supporting actions: Correct a failed credential entry; return to Landing.
• Domain entities: Teacher, Principal and Parent identities; role assignment.
• Component responsibilities: Credential form with pill inputs; submit control; inline verification and error messaging; link back to Landing.
• States: Loading — verification in progress, submit disabled. Empty — form awaiting input. Success — identity verified and role resolved, routing to My Classes / My Students (Teacher), Oversight (Principal) or My Child (Parent). Error — invalid credentials or unresolvable role, with a clear message and no access to protected state. Recovery — re-enter credentials; if the role cannot be resolved, the message directs the person to their school administrator.

Dashboard

• Information/state: Protected Admin web view of consolidated school-wide activity. One hero stat card dominates each row, with supporting metric cards beneath it.
• Primary action: Read the consolidated school-wide picture and move into the record area that needs attention.
• Supporting actions: Move between metric cards; open Records for the relevant record type.
• Domain entities: School-wide metrics; staff, student, class and school-operation summaries.
• Component responsibilities: Chalkboard-green left rail with pill nav items; card grid with one hero stat card per row; sticker-shadow cards with 2px rounded outlines; wavy handwritten section dividers; role header.
• States: Loading — metric cards show placeholder shapes while school-wide figures load. Empty — a metric with no data yet shows a spot illustration and a plain-language explanation rather than a zero. Success — Admin sees current school-wide figures. Error — a failed metric load shows an inline retry on that card without blanking the rest of the dashboard. Recovery — retry the failed card; navigate to Records to correct the underlying data.

Records

• Information/state: Protected Admin management of school ecosystem records — staff, students, classes and school operations.
• Primary action: Create, view and update school ecosystem records.
• Supporting actions: Filter and locate records by type; open an individual record; return to Dashboard.
• Domain entities: Staff records; student records; class records; school operation records.
• Component responsibilities: Record-type navigation; record lists and detail views; create and edit forms with pill inputs; sticker-shadow cards; wavy handwritten section dividers; empty-state spot illustrations.
• States: Loading — record lists show placeholder rows while loading. Empty — a record type with no entries shows a spot illustration and a prompt to add the first record. Success — the record is saved and the updated list reflects it. Error — a failed save or load shows an inline message on the affected record with the entered values preserved. Recovery — retry the save or reload the record; no partial record is left in an ambiguous state.

My Classes

• Information/state: Protected Teacher mobile view of the classes the signed-in Teacher is responsible for, and their recurring classroom duties.
• Primary action: Open a class and work through its recurring classroom duties.
• Supporting actions: Move between classes; move to My Students for the students in those classes.
• Domain entities: Class; class roster reference; recurring classroom duty.
• Component responsibilities: Card stack of classes; bottom pill tab bar in the Teacher's mint role colour; tangerine action buttons; sticker-shadow cards; wavy handwritten section dividers.
• States: Loading — class cards show placeholder shapes. Empty — a Teacher with no assigned classes sees a spot illustration and a plain-language explanation. Success — the Teacher sees their classes and can open each one. Error — a failed class load shows an inline retry. Recovery — retry the load; if classes are still missing, the message directs the Teacher to the school administrator.

My Students

• Information/state: Protected Teacher mobile view of the students in the Teacher's classes.
• Primary action: Open a student within the Teacher's classes and view that student's information.
• Supporting actions: Move between students; move back to My Classes.
• Domain entities: Student; class membership.
• Component responsibilities: Card stack of students; class scoping; bottom pill tab bar in the Teacher's mint role colour; sticker-shadow cards; empty-state spot illustration.
• States: Loading — student cards show placeholder shapes. Empty — a class with no students yet shows a spot illustration and explanation. Success — the Teacher sees the students in their classes. Error — a failed student load shows an inline retry. Recovery — retry the load; the Teacher can return to My Classes and re-enter.

Oversight

• Information/state: Protected Principal mobile view of school-wide oversight information covering school operations and staff/student outcomes.
• Primary action: Review school-wide oversight information and act on what needs attention.
• Supporting actions: Move between oversight areas; drill into the staff or student outcome that needs a decision.
• Domain entities: School operation status; staff outcome; student outcome.
• Component responsibilities: Card stack of oversight areas with one hero card dominating each row; bottom pill tab bar in the Principal's lilac role colour; tangerine action buttons; sticker-shadow cards; wavy handwritten section dividers.
• States: Loading — oversight cards show placeholder shapes. Empty — an oversight area with no data yet shows a spot illustration and explanation. Success — the Principal sees current school-wide oversight information. Error — a failed oversight load shows an inline retry on that card. Recovery — retry the failed card; the Principal can move to another oversight area meanwhile.

My Child

• Information/state: Protected Parent mobile view of the signed-in Parent's child — the child's school activity and progress.
• Primary action: Follow the child's school activity and progress.
• Supporting actions: Move between the child's activity and progress areas; return to the child's overview.
• Domain entities: Child (student); school activity; progress.
• Component responsibilities: Card stack of the child's activity and progress; bottom pill tab bar in the Parent's sky role colour; sticker-shadow cards; empty-state spot illustration.
• States: Loading — child cards show placeholder shapes. Empty — a child with no recorded activity yet shows a spot illustration and explanation. Success — the Parent sees their child's current school activity and progress. Error — a failed load shows an inline retry. Recovery — retry the load; if the child link is missing, the message directs the Parent to the school administrator.

3. Functional Requirements

FR-1 — Product identity As a visitor or signed-in user, I should see the product presented as Educonnect everywhere, so that I always know which product I am using.

• Provenance: explicit.
• Lifecycle: actor — any visitor or signed-in user; trigger — any surface is opened; observable result — the name Educonnect is used consistently across Landing, Admin Login, Mobile Login and all protected destinations; failure/recovery — not applicable; continuation — the user proceeds with their task.
• Acceptance: the name Educonnect appears as the product name on every surface.

FR-2 — Whole-ecosystem school management As an Admin, I should manage the school's ecosystem records from the web dashboard, so that the institution's staff, students, classes and operations stay accurate and current.

• Provenance: explicit.
• Lifecycle: actor — Admin; trigger — the Admin opens Records; input — staff, student, class and school-operation record details; observable result — the record is created or updated and the school-wide state reflects it; failure/recovery — a failed save shows an inline error with entered values preserved and can be retried; continuation — the Admin returns to Dashboard and sees the updated school-wide picture.
• Acceptance: the Admin can create, view and update staff, student, class and school-operation records, and saved changes are visible in the school-wide state.

FR-3 — Admin dashboard web app As an Admin, I should work in a web dashboard, so that I can run the whole school ecosystem from a consolidated desk view.

• Provenance: explicit.
• Lifecycle: actor — Admin; trigger — the Admin signs in on the web; observable result — the Admin reaches the protected web dashboard; failure/recovery — if the dashboard data fails to load, individual cards retry inline without blanking the page; continuation — the Admin moves from the dashboard into Records.
• Acceptance: the Admin experience is delivered as a web app dashboard, and the Admin reaches it only after verifying identity.

FR-4 — Mobile app for Teacher, Principal and Parent As a Teacher, Principal or Parent, I should use a mobile app, so that I can complete my school responsibilities away from a desk.

• Provenance: explicit.
• Lifecycle: actor — Teacher, Principal or Parent; trigger — the person signs in on the mobile app; observable result — the person reaches their protected role-specific mobile destinations; failure/recovery — a failed load shows an inline retry on the affected card; continuation — the person moves between their role's destinations.
• Acceptance: the Teacher, Principal and Parent experiences are delivered as a mobile app, and each reaches only their own role's protected destinations.

FR-5 — Admin identity verification As an Admin, I should verify my identity through Admin Login before reaching the protected web dashboard, so that school-wide records stay protected.

• Provenance: required_inference.
• Lifecycle: actor — Admin; trigger — the Admin opens Admin Login; input — Admin credentials; observable result — identity verified and the Admin routed to Dashboard; failure/recovery — invalid credentials or an unprovisioned account show a clear message with no access to protected state, and the Admin can re-enter credentials; continuation — the Admin proceeds into the dashboard.
• Acceptance: protected web destinations are unreachable until Admin identity is verified.

FR-6 — Mobile identity verification As a Teacher, Principal or Parent, I should verify my identity through Mobile Login before reaching protected mobile destinations, so that each person's school state stays private to them.

• Provenance: required_inference.
• Lifecycle: actor — Teacher, Principal or Parent; trigger — the person opens Mobile Login; input — mobile credentials; observable result — identity verified, role resolved, and the person routed to their role's protected destinations; failure/recovery — invalid credentials or an unresolvable role show a clear message with no access to protected state, and the person can re-enter credentials; continuation — the person proceeds into their role's destinations.
• Acceptance: protected mobile destinations are unreachable until identity is verified and the role is resolved.

FR-7 — Admin provisioning As an Admin, I should be provisioned or invited by the school, so that control of school-wide records is not obtainable through public self-enrollment.

• Provenance: required_inference.
• Lifecycle: actor — Admin; trigger — the school provisions or invites the Admin account; observable result — the Admin account exists and can verify identity through Admin Login; failure/recovery — an unprovisioned account cannot reach protected state and is directed to the school's provisioning contact; continuation — the Admin signs in.
• Acceptance: there is no public self-enrollment path to the Admin role.

FR-8 — Anonymous product explanation As a visitor, I should understand what Educonnect is, who it is for and what it does before signing in, so that I can reach the right sign-in surface.

• Provenance: required_inference.
• Lifecycle: actor — visitor (any of Admin, Teacher, Principal, Parent); trigger — the visitor opens Landing; observable result — the visitor understands the product and its four roles and is routed to Admin Login or Mobile Login; failure/recovery — if a sign-in route is unavailable, the routing control states the failure and remains retryable; continuation — the visitor proceeds to the correct sign-in surface.
• Acceptance: Landing is reachable without identity and exposes no protected school state.

FR-9 — Consolidated school-wide dashboard view As an Admin, I should see a consolidated dashboard view of school activity, so that I can keep the institution running and know where to act next.

• Provenance: required_inference.
• Lifecycle: actor — Admin; trigger — the Admin reaches Dashboard after signing in; observable result — the Admin sees current school-wide figures with one hero stat card dominating each row; failure/recovery — a failed metric load shows an inline retry on that card without blanking the rest; continuation — the Admin opens Records for the area needing attention.
• Acceptance: the Admin sees consolidated school-wide activity and can move from it into Records.

FR-10 — Teacher class management As a Teacher, I should manage my classes and recurring classroom duties from the mobile app, so that I can keep teaching work moving between lessons.

• Provenance: required_inference.
• Lifecycle: actor — Teacher; trigger — the Teacher opens My Classes; observable result — the Teacher sees their classes and can open each one to work through its recurring duties; failure/recovery — a failed class load shows an inline retry, and missing classes direct the Teacher to the school administrator; continuation — the Teacher moves to My Students or back to their classes.
• Acceptance: the Teacher sees only their own classes and can act on their recurring classroom duties.

FR-11 — Teacher student access As a Teacher, I should see the students in my classes from the mobile app, so that I know who I am teaching.

• Provenance: required_inference.
• Lifecycle: actor — Teacher; trigger — the Teacher opens My Students; observable result — the Teacher sees the students in their classes and can open an individual student; failure/recovery — a failed student load shows an inline retry; continuation — the Teacher returns to My Classes.
• Acceptance: the Teacher sees the students belonging to their classes.

FR-12 — Principal oversight As a Principal, I should oversee school operations and staff/student outcomes from the mobile app, so that I can act on school-wide matters wherever I am.

• Provenance: required_inference.
• Lifecycle: actor — Principal; trigger — the Principal opens Oversight; observable result — the Principal sees school-wide oversight information covering operations and staff/student outcomes and can act on what needs attention; failure/recovery — a failed oversight load shows an inline retry on that card while other areas remain usable; continuation — the Principal moves to another oversight area.
• Acceptance: the Principal sees school-wide oversight information and can act on it from the mobile app.

FR-13 — Parent child following As a Parent, I should follow my child's school activity and progress from the mobile app, so that I stay informed about my child's school life.

• Provenance: required_inference.
• Lifecycle: actor — Parent; trigger — the Parent opens My Child; observable result — the Parent sees their child's school activity and progress; failure/recovery — a failed load shows an inline retry, and a missing child link directs the Parent to the school administrator; continuation — the Parent moves between the child's activity and progress areas.
• Acceptance: the Parent sees their own child's school activity and progress.

4. User Personas

Admin

The Admin runs the whole school ecosystem from the web dashboard. Their working context is a desk and a large screen, and their job is record-heavy and school-wide: staff, students, classes and day-to-day school operations all pass through them. Their primary goal is to keep the institution's records accurate and to know, at a glance, where the school needs attention.

Their distinct responsibilities are maintaining school ecosystem records and reading the consolidated dashboard view of school activity. Their key inputs are record details for staff, students, classes and school operations, and their key decision is which record area needs attention next. They interact with the other personas indirectly but materially: the records they maintain are the same records the Teacher sees in My Classes and My Students, the Principal reviews in Oversight, and the Parent follows in My Child. They also provision or invite the accounts that let those people in.

Their observable success is a current, accurate school-wide record set and a dashboard that reflects it. Their access is provisioned or invited by the school rather than self-started, because they control school-wide records, and they verify identity through Admin Login before reaching protected state.

Teacher

The Teacher is a classroom practitioner whose work happens between lessons, in corridors and on the move. Their working context is a phone, not a desk, and their responsibilities are recurring and personal: the classes they are responsible for and the students in those classes. Their primary goal is to keep their own classroom duties moving without returning to a computer.

Their distinct responsibilities are managing their classes and their recurring classroom duties, and seeing the students in their classes. Their key inputs are their own class and student information; their key decision is which class or student needs their attention now. They interact with the Admin, whose records define the classes and students they see, and with the Principal, who oversees the outcomes of their classroom work. They do not see school-wide records or other teachers' classes.

Their observable success is being able to open their classes and students and act on them from their phone. They verify identity through Mobile Login, and the mobile app's tab bar takes the Teacher's mint role colour so the app visibly reads as theirs.

Principal

The Principal is the school's oversight role. Their working context is mobile and intermittent — they check in between meetings and walkthroughs — but the scope of what they look at is school-wide rather than classroom-specific. Their primary goal is to see how the school is operating and how staff and students are doing, and to act on what needs attention.

Their distinct responsibilities are reviewing school-wide oversight information covering school operations and staff/student outcomes, and making the oversight decisions that follow. Their key inputs are school-wide operation status and staff and student outcomes; their key decision is what needs intervention. They interact with the Admin, whose records feed the oversight picture, and with Teachers, whose classroom outcomes they oversee. They do not manage records themselves.

Their observable success is current school-wide oversight information they can act on from their phone. They verify identity through Mobile Login, and the mobile app's tab bar takes the Principal's lilac role colour.

Parent

The Parent is a family member following one child's school life. Their working context is domestic and brief — checking in at breakfast or after work — and their scope is deliberately narrow: their own child. Their primary goal is to stay informed about their child's school activity and progress without having to ask the school.

Their distinct responsibilities are following their child's school activity and progress. Their key inputs are their child's recorded school activity and progress; their key decision is whether anything needs their attention or a conversation with the school. They interact with the Admin, whose records define what they can see, and with Teachers, whose classroom work produces their child's activity. They see only their own child, never other students or school-wide records.

Their observable success is seeing their child's current school activity and progress on their phone. They verify identity through Mobile Login, and the mobile app's tab bar takes the Parent's sky role colour.

5. Core User Flows

Flow 1 — Admin signs in and reaches the school-wide dashboard

1. The Admin opens the Educonnect web app and lands on Landing, which explains what Educonnect is, who it is for and what it does.
2. The Admin chooses the Admin sign-in route and arrives at Admin Login.
3. The Admin enters their provisioned credentials and submits.
4. Educonnect verifies the Admin's identity. If the credentials are invalid or the account is not provisioned, Admin Login shows a clear message, no protected state is exposed, and the Admin can re-enter credentials or contact their school's provisioning contact.
5. On success the Admin reaches Dashboard, the protected web view of consolidated school-wide activity, with one hero stat card dominating each row.
6. The Admin reads the school-wide picture and identifies the area that needs attention.
7. Next step: the Admin opens Records for that area.

Flow 2 — Admin maintains school ecosystem records

1. From Dashboard, the Admin opens Records.
2. The Admin selects the record type they need — staff, students, classes or school operations.
3. If that record type has no entries yet, Records shows a spot illustration and a prompt to add the first record.
4. The Admin opens an existing record or starts a new one and enters the record details.
5. The Admin saves. If the save fails, Records shows an inline error on the affected record with the entered values preserved, and the Admin retries without re-entering everything.
6. On success the record is saved and the list reflects the change.
7. Next step: the Admin returns to Dashboard, where the updated school-wide figures now reflect the change. The same records are what Teachers see in My Classes and My Students, what the Principal reviews in Oversight, and what Parents follow in My Child.

Flow 3 — Teacher signs in and works through their classes

1. The Teacher opens the Educonnect mobile app and lands on Landing.
2. The Teacher chooses the mobile sign-in route and arrives at Mobile Login.
3. The Teacher enters their credentials and submits.
4. Educonnect verifies identity and resolves the Teacher role. If the credentials are invalid or the role cannot be resolved, Mobile Login shows a clear message, no protected state is exposed, and the Teacher can re-enter credentials or contact the school administrator.
5. On success the Teacher reaches My Classes, presented as a card stack with the bottom pill tab bar in the Teacher's mint role colour.
6. The Teacher opens a class and works through its recurring classroom duties. If the class load fails, an inline retry appears; if the Teacher has no assigned classes, a spot illustration explains why and directs them to the school administrator.
7. Next step: the Teacher moves to My Students.

Flow 4 — Teacher reviews the students in their classes

1. From My Classes, the Teacher moves to My Students.
2. The Teacher sees the students in their classes as a card stack. If a class has no students yet, a spot illustration explains it.
3. The Teacher opens an individual student and views that student's information.
4. If the student load fails, an inline retry appears and the Teacher can retry without losing their place.
5. Next step: the Teacher returns to My Classes to continue their classroom duties.

Flow 5 — Principal signs in and reviews school-wide oversight

1. The Principal opens the Educonnect mobile app and lands on Landing.
2. The Principal chooses the mobile sign-in route and arrives at Mobile Login.
3. The Principal enters their credentials and submits.
4. Educonnect verifies identity and resolves the Principal role. If verification fails or the role cannot be resolved, Mobile Login shows a clear message with no protected state exposed, and the Principal can re-enter credentials.
5. On success the Principal reaches Oversight, presented as a card stack with one hero card dominating each row and the bottom pill tab bar in the Principal's lilac role colour.
6. The Principal reviews school-wide oversight information covering school operations and staff/student outcomes. If one oversight area fails to load, that card shows an inline retry while the other areas stay usable.
7. The Principal acts on what needs attention.
8. Next step: the Principal moves to another oversight area, or leaves the app and returns later to the same protected view.

Flow 6 — Parent signs in and follows their child

1. The Parent opens the Educonnect mobile app and lands on Landing.
2. The Parent chooses the mobile sign-in route and arrives at Mobile Login.
3. The Parent enters their credentials and submits.
4. Educonnect verifies identity and resolves the Parent role. If verification fails or the role cannot be resolved, Mobile Login shows a clear message with no protected state exposed, and the Parent can re-enter credentials.
5. On success the Parent reaches My Child, presented as a card stack with the bottom pill tab bar in the Parent's sky role colour.
6. The Parent sees their child's school activity and progress. If the load fails, an inline retry appears; if the child link is missing, the message directs the Parent to the school administrator.
7. The Parent moves between the child's activity and progress areas.
8. Next step: the Parent returns later to the same protected view to check in again.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Pablo Stanley. Headline direction: "One school. Every person in it." The register is trust plus everyday warmth — children, classrooms, parents checking in at breakfast, teachers between lessons — human, legible and calm, never clinical or corporate.

Colour tokens (light mode)

Pastel supports appear only inside illustration and small status chips, never as large flat panels. Tangerine is used for large text and controls only, never small body copy. No blue or indigo primary buttons on white; no gradient-blob heroes; no glassmorphism; no neon or high-saturation colour fields.

Typography

• Headings: Baloo 2 at 700–800, slightly rounded terminals, tight leading (0.95–1.05), sentence case.
• Body: Nunito.
• Labels and chips: Nunito 800 uppercase at 11–12px with 0.08em tracking.
• Scale: 1.333 modular — display 40/56/72/88, h1 40, h2 32, h3 24, body 17, small 14, label 12. Mobile display starts at 40px; desktop reaches 88px via clamp().
• Inter, Roboto, Arial, Helvetica, Poppins and system-ui are excluded for all heading and body text.

Shape language

• Cards 20–24px radius; buttons and inputs fully pill (999px); avatars and role badges circular; illustration blobs and sticker shapes with 2px ink outlines.
• Cards use a soft offset shadow 0 8px 0 rgba(31,36,48,0.06) that reads as a printed sticker lift rather than a glassy blur.
• Section dividers are hand-drawn wavy rules, not hairlines.

Layout

• Cream canvas with a 12-column grid at 1280px, 8-column at 768px, single column at 375px.
• Landing: asymmetric two-column hero — left column holds the stacked oversized headline and CTA, right column holds a modular illustration scene that bleeds off the right edge.
• Admin dashboard: chalkboard-green left rail with pill nav items plus a card grid of school metrics with one hero stat card dominating each row.
• Mobile: card stacks with a bottom pill tab bar; each role gets its own tab colour from the pastel set (Teacher mint, Principal lilac, Parent sky, Admin green) while the accent stays tangerine for actions.

Imagery

Modular vector illustration in the Pablo Stanley tradition: diverse students, teachers, parents and admin staff built from reusable parts, warm skin-tone and pastel palettes, simple geometric faces with visible personality. Spot illustrations for empty states (an empty classroom, a waving parent). No stock photography, no 3D renders, no gradient blobs. Icons are chunky 2px-outline rounded pictograms.

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

7. Signature Design Concept

The public entry is the Landing page, and its signature is the asymmetric two-column hero on cream.

The left column occupies 7 of 12 columns and stacks an oversized Baloo 2 headline — "One school. Every person in it." — breaking across three lines, left-aligned and never centred, scaling from 40px on mobile to 88px on desktop via clamp(). A small line of Nunito body copy sits above it, and a single tangerine pill CTA — "See how Educonnect works" — is pinned beneath the last line. There is no blue button and no gradient blob.

The right column occupies 5 of 12 columns and holds a modular illustration scene: a teacher, a parent on a phone and an admin at a desk, built from reusable Pablo Stanley-style parts with warm skin tones and pastel palettes. The scene sits on a large chalkboard-green rounded block — not a gradient — and bleeds off the right viewport edge.

Beneath the hero, a soft cream-to-white band carries a horizontal scrolling strip of role chips — Admin, Teacher, Principal, Parent — in pastel colours, each chip routing the visitor toward the correct sign-in surface. Wavy handwritten rules divide the sections instead of hairlines.

The concept only recomposes accepted content, states and controls: it explains the product, names the four roles, and routes to Admin Login and Mobile Login. It introduces no new behaviour, page or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the modular illustration scene in the right column — a teacher, a parent on a phone and an admin at a desk, standing on a chalkboard-green rounded block that bleeds off the right viewport edge.
• Input → transformation → outcome thesis: as the visitor scrolls the Landing page, each illustration character enters with a single warm gesture — a wave or a nod — and then holds still; the oversized headline and the tangerine CTA settle into place with the same brief spring. The outcome is a composed, human first frame that reads as a school full of people rather than a software product, and the visitor is left facing the role chip strip and the sign-in routing controls.
• Motion vocabulary: springy but brief — cards and illustration characters settle with a 220ms cubic-bezier(0.34, 1.56, 0.64, 1) ease-out on scroll into view; illustration characters wave or nod exactly once on entry, then hold still; buttons compress 4% on press; hover on cards lifts the shadow, not the position; the role chip strip runs continuously as a marquee and pauses on hover.
• Composed first frame: cream ground, oversized Baloo 2 headline stacked in three left-aligned lines, small Nunito line above it, tangerine pill CTA pinned beneath the last line, illustration scene on its chalkboard-green block bleeding off the right edge, and the pastel role chip strip beginning to scroll in the band below.
• Reduced-motion state: with prefers-reduced-motion, all entry gestures and the marquee stop. The role chip strip becomes a static wrapped list or a horizontally scrollable row so every chip can be brought fully into view, and the hero renders as a still composed frame with no character animation.

9. Non-Functional Requirements

NFR-1 — Delivery shape split The Admin experience is delivered as a web app dashboard; the Teacher, Principal and Parent experiences are delivered as a mobile app. Provenance: explicit hard constraint. Rationale: the Admin's record-heavy work is desk-bound while the other three roles work on the move.

NFR-2 — Product naming The product name must be Educonnect. Provenance: explicit hard constraint. Rationale: the user confirmed the name twice in the authoritative thread.

NFR-3 — Application-owned identity and durable state Identity is application-owned, and school state is durable: records the Admin maintains persist and are the same records the Teacher, Principal and Parent see. Provenance: required_inference from the accepted journeys. Rationale: each role's protected view must remain bound to the correct person and reflect the same school state across surfaces.

NFR-4 — Protected state is unreachable before verification Protected web and mobile destinations are unreachable until identity is verified; Landing is the only anonymously reachable surface and exposes no protected school state. Provenance: required_inference. Rationale: school-wide records and a child's information must not be exposed to unverified visitors.

NFR-5 — Role-scoped visibility Each signed-in person reaches only their own role's protected destinations: the Admin reaches Dashboard and Records; the Teacher reaches My Classes and My Students; the Principal reaches Oversight; the Parent reaches My Child. Provenance: required_inference from the accepted role-specific destinations. Rationale: the accepted journeys assign distinct protected state to each role.

NFR-6 — Readable text and controls at every viewport Headlines, wordmarks, labels, numbers, card 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. Provenance: explicit creative direction. Rationale: the product is used by staff and families on phones and on desk screens.

NFR-7 — Reduced-motion support With prefers-reduced-motion, all entry gestures and marquees stop, and moving content becomes a static wrapped list or a horizontally scrollable row in which every item can be brought fully into view. Provenance: explicit creative direction. Rationale: motion must never be the only way to reach content.

NFR-8 — Shared backend Both delivery surfaces read and write the same school state through one shared backend. Provenance: required_inference. Rationale: a record the Admin maintains must be the same record the Teacher, Principal and Parent see.

10. Tech Stack

• Web (Admin dashboard): React.
• Mobile (Teacher, Principal, Parent): React Native.
• Backend: Python with FastAPI, serving both the web dashboard and the mobile app from one shared service.
• Storage: a relational database appropriate to durable school records (staff, students, classes, school operations) and application-owned identity.
• Packaging and local run: Docker with docker-compose.
• Deployment: Kubernetes only if deployment requires it.

No source-specified technology was overridden; the stack above preserves the accepted delivery shapes and adds only the practical dependencies the current product needs.

11. Assumptions and Constraints

Assumptions

• A1 — The Admin account is provisioned or invited by the school; there is no public self-enrollment path to the Admin role. (required_inference)
• A2 — Teacher, Principal and Parent accounts are established by the school, and Mobile Login resolves which of the three roles the signed-in person holds. (required_inference)
• A3 — A Parent's My Child view is scoped to their own child only. (required_inference from the accepted Parent journey)
• A4 — A Teacher's My Classes and My Students views are scoped to the classes that Teacher is responsible for. (required_inference from the accepted Teacher journey)
• A5 — The Figma sample link the user asked for was never supplied; it is treated as inspiration only and does not block any requirement. (explicit reference directive)

Constraints

• C1 — The Admin experience is a web app dashboard; the Teacher, Principal and Parent experiences are a mobile app. (explicit)
• C2 — The product name is Educonnect. (explicit)
• C3 — The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit creative direction)
• C4 — Inter, Roboto, Arial, Helvetica, Poppins and system-ui are excluded for all heading and body text. (explicit creative direction)
• C5 — Gradient-blob heroes, glassmorphism panels, stock photography of students or corporate handshakes, neon or high-saturation colour fields, and dense enterprise tables without illustration or breathing room are excluded. (explicit creative direction)
• C6 — Pastels appear only inside illustration and small status chips, never as large flat panels. (explicit creative direction)
• C7 — Illustration characters gesture once on entry and then hold still; motion never bounces or loops continuously. (explicit creative direction)

Presentation and technology defaults

• D1 — [Default — not specified by user] The exact relational database engine is not specified; any relational store supporting durable school records and application-owned identity is acceptable.
• D2 — [Default — not specified by user] Kubernetes is included only if deployment requires it; docker-compose is the baseline local run.

12. Glossary

• Educonnect — The product name for this school management software.
• Admin — The school administrator persona who runs the whole school ecosystem from the web dashboard.
• Teacher — The classroom teacher persona who uses the mobile app for recurring teaching duties.
• Principal — The school principal persona who uses the mobile app for school-wide oversight.
• Parent — The parent or guardian persona who uses the mobile app to follow their child's school life.
• Landing — The anonymous public entry surface that explains Educonnect and routes visitors to the correct sign-in.
• Admin Login — The identity-access surface where the Admin verifies identity to reach the protected web dashboard.
• Mobile Login — The identity-access surface where Teacher, Principal and Parent verify identity to reach their protected mobile destinations.
• Dashboard — The Admin's protected web view of consolidated school-wide activity.
• Records — The Admin's protected management of school ecosystem records: staff, students, classes and school operations.
• My Classes — The Teacher's protected mobile view of their classes and recurring classroom duties.
• My Students — The Teacher's protected mobile view of the students in their classes.
• Oversight — The Principal's protected mobile view of school-wide oversight information.
• My Child — The Parent's protected mobile view of their child's school activity and progress.
• School ecosystem — The connected set of school records and activity spanning staff, students, classes and school operations.
• Role — One of the four accepted active human actors: Admin, Teacher, Principal, Parent.