System Requirements Document for home-care

1. Introduction

home-care is a first-party web product for a home care agency that provides nursing staff and GDA (General Duty Assistant) staff at home. The product serves two audiences in one system:

• Families and clients who need nursing or GDA staff to be provided at home for a patient, and who must be able to request that staffing.
• The home care agency administrator who runs the service and must maintain the durable roster of nursing and GDA staff that the agency supplies to homes.

The product intent is therefore twofold and inseparable: a public, trustworthy front door that explains the at-home nursing and GDA staffing service and lets a family begin a care request, and a warm, calm agency workspace where the administrator keeps the nursing and GDA staff records that make those home placements possible.

The audience is non-technical and often under stress. Families arrive in a worried moment, choosing who will touch their parent's body. Administrators arrive to work a roster of real people with roles, certifications, shifts and availability. The system is designed to be competent, calm and human-scale for both.

2. System Overview

home-care is delivered as a custom first-party web application with application-owned identity and custom UI. It comprises six pages in a fixed, ordered contract:

1. Landing — anonymous public entry explaining the nursing and GDA staff service provided at home.
2. Login — shared returning-verification surface for clients, family members and agency administrators.
3. Care Request — protected workspace where a client or family member requests nursing or GDA staff for home care.
4. Staff — protected agency workspace for browsing and managing the durable nursing and GDA staff records used for home care assignments.
5. Staff Details — protected focused agency workspace for creating or editing an individual nursing or GDA staff record.
6. Sign Up — anonymous self-service enrollment surface for actors beginning to use the service.

Actors. Two accepted active human personas: the Home Care Agency Administrator and the Home Care Client / Family Member. No other human personas are in scope.

Accepted behavior. The system (a) presents the at-home nursing and GDA staffing service publicly, (b) lets a client or family member request nursing or GDA staff for home care, (c) lets the agency administrator browse and manage the durable nursing and GDA staff records used for home care assignments, and (d) lets the administrator create or edit an individual nursing or GDA staff record. Identity is application-owned: self-service enrollment establishes a new actor, and returning verification through Login is required before protected workflows.

Ownership. All six pages are application-owned custom pages. There is no provider-owned or external destination in the current scope. Backend integration is required to persist identity, care requests, and staff records.

Narrow exclusions. This document does not add scheduling calendars, billing or invoicing, payroll, messaging or chat, medical records or clinical charting, ratings or reviews, notifications, or any adjacent account-management capability beyond first-use enrollment and returning verification. No such capability is accepted by the source.

2a. Product Interpretation and Delivery Boundary

Delivery. home-care is a first-party web application with custom UI, served by the agency itself. Every page in the contract is owned and rendered by the application. Nothing in the current scope is delegated to a provider surface or an external destination.

Access ownership. Identity is application-owned. The Landing and Sign Up pages are anonymously reachable — a visitor can read about the at-home nursing and GDA staffing service and can enroll without holding an account. Login is also anonymously reachable, because it is the interaction that establishes access to protected work and therefore cannot itself require that access. Care Request, Staff and Staff Details are protected and role-restricted: Care Request belongs to the client / family member, while Staff and Staff Details belong to the agency administrator. Application identity and session continuity establish who the actor is and keep their durable work bound to them; they do not by themselves establish any finer permission scheme beyond the role distinction between agency administration and client or family-member access.

Current versus future. Everything described in this document is current. No future-horizon requirement was accepted by the source, so no future section is carried.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Explains that the agency provides nursing staff and GDA staff at home. Presents the service as a trustworthy, human-scale offer rather than a clinical or promotional one. No actor-specific state is shown; the page is identical for every visitor.
• Primary action. A single primary call to action that begins the path toward obtaining nursing or GDA staff at home, leading to Sign Up for a first-time visitor or Login for a returning one.
• Supporting actions. A secondary text link for a visitor who identifies as an agency administrator, leading to Login. Navigation to Sign Up and Login.
• Domain entities. The service offering itself: nursing staff provided at home, GDA staff provided at home. No persisted entity is created on this page.
• Component responsibilities. A hero region carrying the headline, a lead line, the primary call to action and the administrator link. A supporting region describing the two staff categories the agency provides at home. A region explaining how a family obtains staff at home, from request through assignment. A footer carrying the agency's identity and the routes to Sign Up and Login.
• States. Loading: static content, no data fetch required for the explanatory regions. Empty: not applicable — the page always carries its explanatory content. Success: the visitor understands the service and selects a route into Sign Up or Login. Error: if any live roster figure cannot be retrieved, the page renders its explanatory content without that figure rather than failing. Recovery: the visitor can always reach Sign Up and Login from the footer regardless of any partial failure.

Login

• Information and state. Anonymous returning-verification surface shared by clients, family members and agency administrators. Collects the credentials of an actor who already has an account. Holds no durable state of its own.
• Primary action. Verify the returning actor and continue into the protected work that actor owns.
• Supporting actions. Navigate to Sign Up for a visitor who has no account. Return to Landing.
• Domain entities. The actor's identity and the role that determines which protected workspace they reach.
• Component responsibilities. A credential form. A submit control. A route to Sign Up. A message region for verification failure.
• States. Loading: the submit control shows a pending state while verification is in flight and is not submitted twice. Empty: the form renders empty and ready for input. Success: the actor is verified and continues to the protected workspace their role owns — Care Request for a client or family member, Staff for an agency administrator. Error: invalid credentials produce a clear, non-revealing message that does not disclose whether the account exists; the entered identifier is preserved so the actor can correct the credential without retyping everything. Recovery: the actor may retry immediately, or leave for Sign Up to enroll.

Care Request

• Information and state. Protected workspace owned by the client or family member. Shows the state of the actor's own care request for nursing or GDA staff at home, including which staff category was requested and where the request currently stands. Scoped to the requesting actor's own requests.
• Primary action. Submit a request for nursing staff or GDA staff to be provided at home.
• Supporting actions. Review a previously submitted request and its current state. Begin a further request.
• Domain entities. Care request (the request for at-home staffing), requested staff category (nursing or GDA), the patient the care is for, the home at which the care is to be provided, the request's current state, and the requesting actor.
• Component responsibilities. A request form capturing the staff category and the details needed to place staff at a home. A request state display showing the current standing of the actor's request. A soft rounded line diagram showing how a request moves from the family to assigned staff, with the current step marked. An empty-state frame for an actor who has not yet requested care.
• States. Loading: the workspace shows a pending state while the actor's existing requests are retrieved. Empty: an actor with no request sees an empty state that explains what a request is for and offers the action to begin one. Success: the submitted request is confirmed and its new state is visible to the actor. Error: a submission that cannot be completed reports the failure, preserves everything the actor entered, and offers retry. Recovery: the actor can correct the request and resubmit, and any previously submitted request remains visible and unchanged.

Staff

• Information and state. Protected agency workspace owned by the Home Care Agency Administrator. Shows the durable roster of nursing and GDA staff records the agency uses for home care assignments. Each row carries the staff member's role, distinguishing nursing staff from GDA staff, together with the record's identifying and shift information.
• Primary action. Open a staff record for creation or editing, leading to Staff Details.
• Supporting actions. Browse and scan the roster. Identify which records are nursing staff and which are GDA staff. Select a record to work on it.
• Domain entities. Staff record (a nursing or GDA staff member supplied by the agency for home care), staff role (nursing or GDA), staff identifier, shift count, availability, and certification.
• Component responsibilities. A roster list presenting staff records as hairline-ruled rows rather than boxed cards, so a long roster stays scannable. A role indicator on each row distinguishing nursing from GDA. A control to begin a new staff record. An empty-state frame for an agency with no staff records yet.
• States. Loading: the roster shows a pending state while records are retrieved. Empty: an agency with no staff records sees an empty state explaining that this is where nursing and GDA staff are kept, with the action to create the first record. Success: the roster reflects the current set of staff records, including any record just created or edited. Error: a roster that cannot be retrieved reports the failure and offers retry rather than showing a misleadingly empty list. Recovery: the administrator retries retrieval; no record is altered by a failed read.

Staff Details

• Information and state. Protected focused agency workspace owned by the Home Care Agency Administrator. Shows one individual nursing or GDA staff record in full, whether it is being created for the first time or edited.
• Primary action. Save the staff record — creating it when new, or applying the administrator's changes when editing.
• Supporting actions. Set or change the staff member's role as nursing or GDA. Review the record's current values before saving. Return to Staff.
• Domain entities. Staff record, staff role (nursing or GDA), staff identifier, shift count, availability, certification, and the record's creation and last-updated facts.
• Component responsibilities. A record form covering the staff member's identity, role and shift information. A role selector that distinguishes nursing staff from GDA staff. A save control. A message region for validation and save outcomes.
• States. Loading: when editing an existing record, the form shows a pending state while the record is retrieved. Empty: when creating a new record, the form renders empty and ready for input. Success: the saved record is confirmed and the change is reflected in the Staff roster. Error: validation failures identify the offending field and preserve all entered values; a save that cannot be completed reports the failure and preserves the form so nothing is lost. Recovery: the administrator corrects the field and saves again, or abandons the edit and returns to Staff without altering the stored record.

Sign Up

• Information and state. Anonymous self-service enrollment surface for an actor beginning to use the home care service. Collects what is needed to establish a new actor and the role that actor will hold — client or family member, or agency administrator.
• Primary action. Create the actor's account and establish their identity in the service.
• Supporting actions. Choose the role the actor is enrolling as. Navigate to Login for an actor who already has an account. Return to Landing.
• Domain entities. The new actor's identity, the actor's role, and the credentials that will later verify them at Login.
• Component responsibilities. An enrollment form. A role selection distinguishing a client or family member from an agency administrator. A submit control. A message region for validation and enrollment outcomes.
• States. Loading: the submit control shows a pending state while enrollment is in flight and is not submitted twice. Empty: the form renders empty and ready for input. Success: the actor's account is established and the actor continues into the protected workspace their role owns — Care Request for a client or family member, Staff for an agency administrator. Error: validation failures identify the offending field and preserve all entered values; an enrollment that cannot be completed reports the failure without discarding the form. Recovery: the actor corrects the field and submits again, or leaves for Login if it turns out they already have an account.

3. Functional Requirements

Each requirement is a distinct story point with its provenance, lifecycle facts and observable acceptance.

FR-1 — Public explanation of the at-home staffing service (explicit) As a visitor, I should be able to read, without holding an account, that the agency provides nursing staff and GDA staff at home, so that I understand what the service is before I commit to anything.

• Trigger/input: the visitor opens the Landing page.
• Observable result: the page states that the agency provides nursing staff and GDA staff at home, and distinguishes the two staff categories.
• Access state: anonymous; no identity required.
• Failure/recovery: if any live figure cannot be retrieved, the explanatory content still renders and the visitor can still reach Sign Up and Login.
• Continuation: the visitor proceeds to Sign Up or Login.

FR-2 — Begin obtaining staff at home from the public entry (explicit) As a client or family member, I should be able to start the path toward obtaining nursing or GDA staff at home directly from the public entry, so that I am not stranded on an informational page.

• Trigger/input: the visitor selects the primary call to action on Landing.
• Observable result: the visitor arrives at Sign Up if new, or Login if returning.
• Access state: anonymous at the point of selection.
• Failure/recovery: the routes to Sign Up and Login remain reachable from the footer even if the primary region fails to render.
• Continuation: enrollment or verification, then the protected workspace.

FR-3 — Self-service enrollment (required_inference) As a client, family member or agency administrator, I should be able to establish my own account and choose the role I am enrolling as, so that I can begin using the service without an invitation or provisioning step.

• Trigger/input: the actor submits the enrollment form on Sign Up.
• Observable result: the actor's account is established with the chosen role, and the actor continues into the protected workspace that role owns.
• Access state: anonymous entry; the resulting identity is application-owned.
• Failure/recovery: validation failures identify the offending field and preserve all entered values; a failed enrollment reports the failure without discarding the form, and the actor may retry or leave for Login.
• Continuation: Care Request for a client or family member; Staff for an agency administrator.

FR-4 — Returning verification before protected work (required_inference) As a returning client, family member or agency administrator, I should be able to verify myself at Login before reaching protected work, so that my durable requests and staff records stay bound to me.

• Trigger/input: the actor submits credentials on Login.
• Observable result: the actor is verified and continues to the protected workspace their role owns.
• Access state: Login is anonymously reachable; the destinations it opens are protected.
• Failure/recovery: invalid credentials produce a clear, non-revealing message that does not disclose whether the account exists, the entered identifier is preserved, and the actor may retry immediately or leave for Sign Up.
• Continuation: Care Request or Staff, according to role.

FR-5 — Role-aware routing between agency and family access (required_inference) As the system, I should route a verified actor to the workspace their role owns, so that agency administration and client or family-member access remain distinct.

• Trigger/input: a successful verification or enrollment carrying a role.
• Observable result: an agency administrator reaches Staff; a client or family member reaches Care Request.
• Access state: protected destinations are role-restricted; Care Request is not reachable by the agency administrator's role and Staff and Staff Details are not reachable by the client or family-member role.
• Failure/recovery: an actor attempting a destination outside their role is returned to the workspace their role owns rather than shown the other workspace's contents.
• Continuation: the actor works within their own workspace.

FR-6 — Request nursing or GDA staff for home care (explicit) As a client or family member, I should be able to request nursing staff or GDA staff to be provided at home, so that the patient receives the staffing they need in the home.

• Trigger/input: the actor submits a care request on Care Request, specifying the staff category and the details needed to place staff at a home.
• Observable result: the request is recorded and its state is visible to the requesting actor.
• Access state: protected; requires a verified client or family-member identity.
• Failure/recovery: a submission that cannot be completed reports the failure, preserves everything the actor entered, and offers retry; any previously submitted request remains visible and unchanged.
• Continuation: the actor reviews the request's state and may begin a further request.

FR-7 — Review the state of one's own care request (required_inference) As a client or family member, I should be able to see where my request for at-home staffing currently stands, so that I know whether staff are being arranged for the patient.

• Trigger/input: the actor opens Care Request.
• Observable result: the actor's own request and its current state are displayed, including the staff category requested.
• Access state: protected and scoped to the requesting actor's own requests.
• Failure/recovery: a request list that cannot be retrieved reports the failure and offers retry rather than showing a misleadingly empty state.
• Continuation: the actor waits for the request to progress, or submits a further request.

FR-8 — Browse the durable nursing and GDA staff roster (explicit) As the Home Care Agency Administrator, I should be able to browse the durable roster of nursing and GDA staff records used for home care assignments, so that I can see who the agency can supply to homes.

• Trigger/input: the administrator opens Staff.
• Observable result: the roster of staff records is displayed, with each record's role distinguishing nursing staff from GDA staff.
• Access state: protected and role-restricted to the agency administrator.
• Failure/recovery: a roster that cannot be retrieved reports the failure and offers retry rather than showing a misleadingly empty list; no record is altered by a failed read.
• Continuation: the administrator selects a record to work on it, or begins a new record.

FR-9 — Create an individual nursing or GDA staff record (explicit) As the Home Care Agency Administrator, I should be able to create an individual nursing or GDA staff record, so that a new staff member the agency supplies to homes is represented in the roster.

• Trigger/input: the administrator begins a new record from Staff and saves it on Staff Details.
• Observable result: the new staff record exists with its role set as nursing or GDA, and it appears in the Staff roster.
• Access state: protected and role-restricted to the agency administrator.
• Failure/recovery: validation failures identify the offending field and preserve all entered values; a save that cannot be completed reports the failure and preserves the form so nothing is lost.
• Continuation: the administrator returns to Staff and sees the new record in the roster.

FR-10 — Edit an individual nursing or GDA staff record (explicit) As the Home Care Agency Administrator, I should be able to edit an individual nursing or GDA staff record, so that the roster stays up to date as the agency's staff and their availability change.

• Trigger/input: the administrator opens an existing record from Staff and saves changes on Staff Details.
• Observable result: the record's updated values, including its role as nursing or GDA, are stored and reflected in the Staff roster.
• Access state: protected and role-restricted to the agency administrator.
• Failure/recovery: validation failures identify the offending field and preserve all entered values; a save that cannot be completed reports the failure and preserves the form. The administrator may abandon the edit and return to Staff without altering the stored record.
• Continuation: the administrator continues working the roster.

FR-11 — Distinguish nursing staff from GDA staff throughout (explicit) As the Home Care Agency Administrator, I should be able to tell nursing staff and GDA staff apart wherever staff records appear, so that I assign the right category of staff to a home.

• Trigger/input: the administrator views the roster on Staff or an individual record on Staff Details.
• Observable result: each staff record carries a visible role indicator distinguishing nursing from GDA.
• Access state: protected and role-restricted to the agency administrator.
• Failure/recovery: a record whose role cannot be determined is not silently presented as either category.
• Continuation: the administrator acts on the correct category of staff.

FR-12 — Persist identity, care requests and staff records (required_inference) As the system, I should persist actor identities, care requests and staff records, so that a family's request and the agency's roster survive across sessions and remain bound to the correct actor.

• Trigger/input: enrollment, verification, care-request submission, and staff-record creation or editing.
• Observable result: the actor's own durable state is available again on return, and the agency's roster reflects every saved change.
• Access state: durable state is reachable only through the protected workspace that owns it.
• Failure/recovery: a persistence failure surfaces as a reported failure on the originating page with the actor's input preserved, never as a silent success.
• Continuation: the actor retries the action or resumes later.

4. User Personas

Home Care Agency Administrator

Product context. This persona runs the home care service that supplies nursing staff and GDA (General Duty Assistant) staff to homes. Their work is operational and recurring: the agency's ability to place staff into homes depends entirely on the roster being accurate. They are in the product often and for extended stretches, scanning and updating records, so the agency surfaces are built to be read for hours without fatigue.

Primary goal. A maintained, up-to-date staff management record for the agency's home care operations — a roster of nursing and GDA staff that truthfully reflects who the agency can supply to homes.

Distinct accepted responsibilities. The administrator browses the durable roster of nursing and GDA staff records on Staff, creates new individual staff records on Staff Details, and edits existing ones. They are the only persona who touches the staff roster; the client / family member never sees it. Their work is about the supply side of the service — the people the agency sends into homes.

Relevant inputs and decisions. They decide whether a staff member is nursing staff or GDA staff, and they enter and maintain each record's identifying and shift information. Their recurring decision is whether a record is accurate enough to rely on when placing staff into a home.

Interactions with other accepted participants. The administrator does not interact with the client or family member inside the product. The relationship is indirect but real: the roster the administrator maintains is what makes it possible for a family's request for at-home staffing to be met. The two personas share the Landing, Login and Sign Up surfaces but work in separate protected workspaces.

Observable success. The roster on Staff reflects the agency's actual nursing and GDA staff, with each record's role correctly distinguished, and every created or edited record is saved and visible.

Home Care Client / Family Member

Product context. This persona seeks nursing staff or GDA staff to be provided at home for a patient — often a parent or relative. They arrive in a worried, vulnerable moment, and they are choosing who will touch that person's body in their own home. They are not frequent users; they come when care is needed, and they need the path from "I need help at home" to "I have asked for it" to be short and unambiguous.

Primary goal. Obtaining suitable nursing or GDA staff at home for the patient.

Distinct accepted responsibilities. The client or family member reads the public explanation of the at-home staffing service on Landing, enrolls on Sign Up or verifies on Login, submits a request for nursing or GDA staff on Care Request, and reviews the state of that request. Their work is about the demand side of the service — asking for staff to come to a home.

Relevant inputs and decisions. They decide which category of staff the patient needs — nursing or GDA — and supply the details needed to place staff at a home. Their central decision is what kind of care the patient requires at home.

Interactions with other accepted participants. They do not interact with the agency administrator inside the product. Their request is the counterpart to the administrator's roster: the family asks for staff at home, and the agency's maintained roster is what answers that ask. They share the Landing, Login and Sign Up surfaces with the administrator but work in their own protected workspace.

Observable success. Their request for nursing or GDA staff at home is recorded, and they can see where it currently stands.

5. Core User Flows

Flow A — A family member requests nursing or GDA staff at home

1. Starting context. A family member needs nursing or GDA staff at home for a patient and has no account. They arrive at Landing anonymously.
2. On Landing, they read that the agency provides nursing staff and GDA staff at home, and see the two staff categories distinguished.
3. They select the primary call to action to obtain staff at home and arrive at Sign Up.
4. On Sign Up, they enter the details needed to establish their account and select the client / family-member role, then submit.
5. Observable result. Their account is established and they continue into Care Request, the protected workspace their role owns.
6. On Care Request, they see an empty state explaining what a request is for, with the action to begin one.
7. They choose the staff category the patient needs — nursing or GDA — and supply the details needed to place staff at a home, then submit the request.
8. Observable result. The request is recorded and its state is visible to them, with the soft rounded line diagram showing the current step in how a request moves from the family to assigned staff.
9. Continuation. They may review the request's state on a later visit, or begin a further request.

Failure and recovery. If the enrollment form fails validation, the offending field is identified and everything they entered is preserved so they can correct it and submit again. If the care-request submission cannot be completed, the failure is reported, their entered details are preserved, and they can retry; any previously submitted request remains visible and unchanged. If they already had an account, they leave for Login instead.

Flow B — A returning family member checks their care request

1. Starting context. A family member who previously requested at-home staffing returns to the service and opens Login anonymously.
2. They enter their credentials and submit.
3. Observable result. They are verified and continue into Care Request.
4. On Care Request, they see their own request and its current state, including the staff category they requested.
5. Continuation. They wait for the request to progress, or submit a further request for additional staffing.

Failure and recovery. If their credentials are rejected, they see a clear message that does not disclose whether the account exists, their entered identifier is preserved, and they may retry immediately or leave for Sign Up to enroll.

Flow C — The agency administrator creates a new nursing or GDA staff record

1. Starting context. The agency administrator has a new staff member to add to the roster and opens Login anonymously.
2. They enter their credentials and submit.
3. Observable result. They are verified and continue into Staff, the protected workspace their role owns.
4. On Staff, they see the durable roster of nursing and GDA staff records as hairline-ruled rows, each carrying a role indicator distinguishing nursing from GDA.
5. They select the control to begin a new staff record and arrive at Staff Details.
6. On Staff Details, the form renders empty and ready for input. They enter the staff member's identifying and shift information and set the role as nursing or GDA.
7. They save the record.
8. Observable result. The new staff record exists with its role set, and it appears in the Staff roster.
9. Continuation. They return to Staff and continue working the roster.

Failure and recovery. If validation fails, the offending field is identified and all entered values are preserved so they can correct it and save again. If the save cannot be completed, the failure is reported and the form is preserved so nothing is lost.

Flow D — The agency administrator edits an existing staff record

1. Starting context. The agency administrator needs to update a staff member's record — a change in availability or shift information — and opens Login anonymously.
2. They enter their credentials and submit, and are verified into Staff.
3. On Staff, they locate the staff member's row and select it, arriving at Staff Details.
4. Observable result. The form shows a pending state while the record is retrieved, then displays the record's current values in full.
5. They change the values that need updating, including the role as nursing or GDA if it has changed, and review the record before saving.
6. They save the record.
7. Observable result. The updated values are stored and reflected in the Staff roster.
8. Continuation. They continue working the roster.

Failure and recovery. If validation fails, the offending field is identified and all entered values are preserved. If the save cannot be completed, the failure is reported and the form is preserved. If they decide not to proceed, they abandon the edit and return to Staff without altering the stored record.

Flow E — The agency administrator scans the roster

1. Starting context. The agency administrator opens Login anonymously and verifies into Staff.
2. On Staff, they scan the roster of nursing and GDA staff records, reading each row's role indicator and shift information.
3. Observable result. They can tell which staff are nursing staff and which are GDA staff, and can see the agency's current supply of staff for home care assignments.
4. Continuation. They select a record to edit it, or begin a new record.

Failure and recovery. If the roster cannot be retrieved, the failure is reported and they can retry, rather than being shown a misleadingly empty list. If the agency has no staff records yet, they see an empty state explaining that this is where nursing and GDA staff are kept, with the action to create the first record.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Yves Béhar, and the headline idea is humane technology: soft forms around serious care. The register is trustworthy warmth — competent, calm, human-scale — never clinical coldness and never startup cheerfulness. This single language serves both audiences: it reads as reassuring to a family in a worried moment and as calm, non-fatiguing tooling for an administrator scanning a roster all day.

Colour tokens — light mode

Proportion. Roughly 70% warm ground, 20% sage, 7% surface white, 3% terracotta. No blue anywhere in the system — sage and terracotta carry every state, including focus rings and links. Clinical hospital white and cold greys are excluded; the ground is always warm oat.

Typography

• Headings: Work Sans at medium-to-semibold (500–600), never black. Tracking slightly tight (−0.01em) at display sizes so large headlines feel composed rather than shouty. Sentence case, never all-caps for headings.
• Body: Karla.
• Scale: 1.25 modular with a deliberate display jump — 112 / 44 (display, clamp(44px, 7vw, 112px)), 36 / 28 (section), 24 / 20 (card title), 18 (lead paragraph), 16 (body), 14 (label), 13 (micro-label, +0.08em tracking, muted). Body line-height 1.65; headings 1.05–1.15.
• Headline scale contrast is large while everything below drops sharply, so a page reads as one confident statement plus calm supporting text. Section headings sit at 28–36px with a small terracotta rule above them.

Shape language

Soft continuous curves on a human radius scale: 28px on hero panels and image frames, 20px on cards, 14px on inputs and buttons, 999px on pills and tags. Corners read as soft product, never blobby or cartoonish. Shapes are containers for real content — a rounded panel holding a roster table, a capsule holding a staff role tag. One recurring soft arc motif (a wide, low-curvature curve) is used as a section divider and as the shape of the hero's image mask, echoing a hand resting on a shoulder rather than any decorative blob.

Layout

Warm, human-scale spacing on a 12-column grid with a 1240px max content width and generous 32–40px gutters, collapsing to a single column at 768px and 375px. The landing page is a sequence of full-width bands alternating between warm ground and a full-bleed sage panel, so the page breathes in long horizontal strokes rather than stacking identical cards. Inside the app — Care Request, Staff, Staff Details — the same grid becomes denser: a left rail for navigation, a wide content column, and a right-hand context panel for shift and availability detail. Roster rows are ruled with hairlines rather than boxed in cards, so a long staff list stays scannable. Every numeric value (hours, shift counts, staff IDs) is set in tabular figures.

Imagery

Natural-light photography of care actually happening at home: a nurse's hands checking a blood-pressure cuff on a kitchen table, a GDA helping someone stand beside a sunlit window, a folded uniform and a stethoscope on a linen surface. Warm, slightly desaturated, shot at human height — no stock-photo smiles to camera, no blue-lit hospital corridors, no clip art. Staff profiles use plain, softly lit portraits on a warm ground with a consistent crop. Supporting imagery is material and tactile: oat textiles, wood, ceramic, worn hands. Where a diagram is needed — how a request moves from family to assigned staff — it is drawn as a soft, rounded line diagram in sage and terracotta on the warm ground.

7. Signature Design Concept

The public entry is a split, product-led hero on the warm oat ground, not a centred headline-and-button stack.

Left six columns. A two-line headline at clamp(44px, 7vw, 112px) in Work Sans medium, set flush left and allowed to run to the column edge, with a terracotta rule 64px wide above it. Beneath it, one 18px lead line in Karla and a single terracotta capsule CTA — "Request home care" — pinned directly under the text, plus a text link, "I'm an agency administrator", for the visitor who runs the service.

Right six columns. A large 28px-radius image frame, bleeding off the right edge of the viewport by 80px, holding a natural-light photograph of a nurse assisting a patient at home. Overlapping its lower-left corner by 48px is a small #FFFDF9 panel (20px radius, soft shadow) showing three real roster facts — "Nursing staff on call: 24", "GDA staff available: 61", "Avg. response: 4 hrs" — with numbers in tabular figures at 32px. Behind the image frame, a single wide sage arc sweeps from the bottom-left of the hero to the right edge at 12% opacity, as the section's one decorative gesture.

Mobile. The frame becomes full-bleed 16:9 above the headline, the stat panel becomes a horizontally scrollable row of three chips, and the CTA stays whole and full-width.

Readability guarantee. The photograph is cropped off the right edge, but every number and label inside the stat panel stays whole at 375px, 768px and 1280px. Headlines, the wordmark, labels, numbers, card text and controls stay entirely inside the viewport and their container at every width, wrapping or scaling to fit, and no other element covers any part of them. Where the direction asks for a cropped or bleeding gesture, the gesture is carried by imagery and decoration, never by readable text or a control.

This concept recomposes only accepted content and controls: the explanation that the agency provides nursing staff and GDA staff at home, the route into Sign Up or Login, and the two staff categories. It introduces no new behaviour, page or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The natural-light photograph of a nurse assisting a patient at home, held in the 28px-radius frame that bleeds off the right edge, with the warm-white stat panel overlapping its lower-left corner and the wide sage arc behind it.
• Input → transformation → outcome thesis. On load, the hero's elements rise 16px and fade in, staggered by 80ms — the terracotta rule, then the headline, then the lead line and CTA, then the image frame, then the stat panel. The outcome is a composed first frame in which the family's eye lands on the headline and the single terracotta CTA, while the photograph and the roster numbers establish that real staff are behind the service. Nothing moves that the visitor must chase.
• Motion vocabulary. Breathing, slow easing — 400–600ms cubic-bezier(0.22, 0.61, 0.36, 1), never bounce. Section bands fade up once on scroll with an 8% translate, then stay still. Hover on cards lifts them 3px with a shadow softening, no scale pop. The one continuous motion is a slow, low-amplitude drift on the hero's arc motif — a 12s loop with 6px travel.
• Composed first frame. Warm oat ground; the terracotta rule and headline flush left; the lead line and terracotta capsule CTA beneath; the bleeding image frame on the right with the stat panel overlapping its lower-left corner; the sage arc sweeping behind at 12% opacity. Every readable element whole and inside its container.
• Reduced-motion state. With prefers-reduced-motion, all of this collapses to instant state changes with no translation: the hero appears fully composed, the arc drift stops, and scroll-triggered bands are simply present. No content is hidden behind motion.

9. Non-Functional Requirements

NFR-1 — Warm, light surfaces throughout (explicit, from creative direction) The agency surfaces stay warm and light so an administrator can read them for hours. Dense dark-mode admin chrome is excluded. The ground is always warm oat (#F7F3EC), never clinical hospital white or a cold grey.

NFR-2 — No blue in the system (explicit, from creative direction) No blue, indigo or violet primary appears anywhere in the system, including focus rings and links. Sage and terracotta carry every state. The generic indigo/blue-on-white SaaS template is forbidden for this project.

NFR-3 — Readable text and controls stay whole at every viewport (explicit, from creative direction) 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, and no other element covers any part of them. Imagery, decoration and motion 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. Moving and scrollable content may cross the viewport or container edge by design, 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, wrapping into rows or sitting in a horizontally scrollable row whose further items are reached by scrolling.

NFR-4 — Accessible contrast and legibility (required_inference) Text and controls meet accessible contrast against their warm grounds, and the terracotta accent is used for exactly one job per screen so that the primary action is never ambiguous. Every numeric value is set in tabular figures so roster columns align and remain scannable.

NFR-5 — Protected state is not reachable without identity (required_inference) Care Request, Staff and Staff Details are reachable only by a verified actor holding the role that owns them. Landing, Login and Sign Up are anonymously reachable, because Login and Sign Up are the interactions that establish access and cannot themselves require it.

NFR-6 — Durable state survives sessions and stays bound to its actor (required_inference) Actor identities, care requests and staff records persist across sessions. A family's request remains bound to the requesting actor; the agency's roster reflects every saved change. A persistence failure surfaces as a reported failure on the originating page with the actor's input preserved, never as a silent success.

NFR-7 — Responsive layout (explicit, from creative direction) The 12-column grid with a 1240px max content width and 32–40px gutters collapses to a single column at 768px and 375px. The landing page's full-width bands alternate between warm ground and full-bleed sage; the app's denser grid uses a left rail, a wide content column and a right-hand context panel.

NFR-8 — Motion respects user preference (explicit, from creative direction) With prefers-reduced-motion, all translation, stagger and drift collapse to instant state changes, and scroll-triggered content is simply present.

10. Tech Stack

No technology choice was specified by the user, so the following are coherent defaults for a custom-UI, application-owned-identity web product with backend integration. They are labeled as defaults and carry no product behavior.

• Frontend: React — [Default — not specified by user]. A custom web UI is required by the accepted delivery shape.
• Backend: Python with FastAPI — [Default — not specified by user]. Backend integration is required to persist identities, care requests and staff records.
• Storage: A relational database appropriate to durable actor-bound records — [Default — not specified by user]. It must support the persistence requirement in NFR-6.
• Containerization: Docker with docker-compose for local and single-host deployment — [Default — not specified by user].
• Orchestration: Kubernetes is not required by any accepted requirement and is therefore not included — [Default — not specified by user].

11. Assumptions and Constraints

Assumptions

• A-1. The agency operates a single home care service; no multi-agency or multi-tenant structure is accepted by the source. (narrow assumption)
• A-2. The two accepted personas — Home Care Agency Administrator and Home Care Client / Family Member — are the complete set of active human actors. (from the closed persona catalog)
• A-3. A client or family member acts on behalf of a patient at home; the patient is the subject of the care, not an actor in the product. (narrow assumption)
• A-4. The staff roster is maintained by the agency administrator; staff members themselves are not actors in the product and do not sign in. (narrow assumption)
• A-5. The three roster figures shown in the landing hero are illustrative of the roster facts the agency maintains; where they cannot be retrieved, the hero renders without them. (narrow assumption)

Constraints

• C-1. The page contract is fixed and ordered: Landing, Login, Care Request, Staff, Staff Details, Sign Up. No page may be added, removed, merged, split, renamed, reordered, or have its access changed.
• C-2. Landing, Login and Sign Up are anonymously reachable. Care Request is role-restricted to the client / family member. Staff and Staff Details are role-restricted to the agency administrator.
• C-3. Identity is application-owned, established by self-service enrollment on Sign Up and verified on Login. No invitation or provisioning boundary is established.
• C-4. Application identity and session continuity establish who the actor is and keep their durable work bound to them. They do not establish any finer permission scheme beyond the role distinction between agency administration and client or family-member access.
• C-5. No blue, indigo or violet appears anywhere in the system, including focus rings and links. No clinical hospital white ground and no cold greys.
• C-6. Headings use Work Sans; body uses Karla. Inter, Roboto, Arial, Helvetica, Poppins, Montserrat and system-ui are excluded for headings and body.
• C-7. Glassmorphism, frosted blur panels, gradient blobs and neon glows are excluded. A grid of identical hover-lift cards is not the primary layout device. Playful character illustration, mascots and sticker shapes are excluded. Dense dark-mode admin chrome is excluded.
• C-8. The following are out of scope because no accepted requirement establishes them: scheduling calendars, billing and invoicing, payroll, messaging and chat, medical records and clinical charting, ratings and reviews, notifications, and any account-management capability beyond first-use enrollment and returning verification.
• C-9. No future-horizon requirement was accepted; everything in this document is current.

12. Glossary

• GDA (General Duty Assistant) — A category of care staff the agency provides at home, distinct from nursing staff. GDA staff are represented in the roster with their own role indicator and are a selectable category in a care request.
• Nursing staff — A category of care staff the agency provides at home, distinct from GDA staff. Nursing staff are represented in the roster with their own role indicator and are a selectable category in a care request.
• Home care — Care delivered in the patient's own home rather than in a hospital or facility. The service this product represents provides nursing staff and GDA staff at home.
• Care request — A client's or family member's recorded request for nursing or GDA staff to be provided at home, carrying the requested staff category, the details needed to place staff at a home, and a current state.
• Staff record — The durable representation of one nursing or GDA staff member the agency supplies to homes, carrying their role, identifying information, shift information, availability and certification.
• Roster — The full set of staff records the agency maintains, presented on Staff as hairline-ruled rows rather than boxed cards.
• Role — The distinction that determines which protected workspace an actor owns: agency administrator, or client / family member. It also names the staff category distinction between nursing and GDA.
• Agency administrator — The persona who runs the home care service and maintains the nursing and GDA staff roster.
• Client / family member — The persona who seeks nursing or GDA staff to be provided at home for a patient and requests that staffing.
• Protected workspace — A page reachable only by a verified actor holding the role that owns it: Care Request, Staff, Staff Details.
• Anonymous surface — A page reachable without identity: Landing, Login, Sign Up.