Hum Rahi

────────────────────────────────────────────────────────────
US-032.DESIGN.1 — High-Priority SOS Alert Card — Interaction &
Visual Design Specification
────────────────────────────────────────────────────────────

Role
As a product designer for Ham Rahi,
I need to define the visual design, information hierarchy, interaction
states, and attention mechanics for the SOS alert card on the police
panel,
So that ASI Akram cannot miss an incoming SOS regardless of what
else is on screen, and can immediately read the situation and act
without navigating away or hunting for information.

User Story
As ASI Akram,
I want an incoming SOS to interrupt my current panel view with an
unmissable, information-dense alert card that shows me the citizen's
identity, live location, and audio status at a glance,
So that I can assess the emergency and begin my response in the
first seconds after activation, without clicking through multiple
screens.

In-Scope

• Visual design for the SOS alert card in all states:
  (a) Incoming — newly arrived, unacknowledged
  (b) Acknowledged — operator has seen and accepted the alert
  (c) Active — session is live and audio is streaming
  (d) Location-stale — GPS fix is older than one cycle
  (e) Location-unavailable — permission-denied or signal lost
  (f) Audio-degraded — stream connected but signal quality low
  (g) Resolved — session closed by operator
• Information layout on the card: citizen display name or masked ID,
  activation timestamp, GPS coordinates and accuracy radius,
  a live map thumbnail showing the citizen's pin, audio stream
  status indicator, and session ID
• Attention mechanics for the incoming state: visual treatment
  (colour, motion, z-layer) that interrupts the operator's current
  view without requiring a separate notification system
• Priority visual language distinguishing an SOS card from routine
  incident cards and lower-priority panel items
• Audio alert specification for incoming SOS: alert sound character,
  duration, and repeat behaviour until acknowledged (design
  specification only — sound asset production is out of scope)
• Acknowledgement interaction: what the operator presses, the
  transition animation, and the resulting card state
• Staleness and unavailability indicator design: how the card
  communicates degraded or missing location to the operator clearly
  without causing panic about the UI itself
• Audio stream status indicator: connected, buffering, degraded,
  and disconnected states represented distinctly on the card
• Responsive behaviour: card must be designed for the police panel
  viewport (desktop browser, minimum 1280 px wide) as the primary
  target; tablet is secondary
• Accessibility: colour is never the sole differentiator for any
  status; all states must be distinguishable by operators with
  common colour vision deficiencies

Out-of-Scope

• Full incident detail page (the card is the entry point only;
  the detail view is a separate design story)
• Audio playback controls beyond status indication (operator audio
  upgrade to two-way is Phase 2 and operator-restricted)
• Citizen-facing UI design
• Mobile panel design (police panel is desktop-first in MVP)
• Sound asset production or audio engineering
• Push notification design outside the panel (SMS, email)
• Dispatch or unit assignment UI (Phase 2)

Acceptance Criteria

AC1 The design defines a distinct high-priority visual treatment for
the SOS card that is immediately differentiable from all other
card types on the panel without relying on colour alone.

AC2 The incoming state design includes an attention mechanic — motion,
overlay, or equivalent — that surfaces the card in the operator's
field of view even when they are focused on another panel section.

AC3 The card layout in the acknowledged / active state presents
citizen ID, activation timestamp, GPS coordinates, accuracy
radius, live map thumbnail, audio status indicator, and session ID
without requiring scroll or expansion.

AC4 An audio alert specification is documented for the incoming state,
including alert character, duration, and repeat interval until
acknowledgement; it is referenced in the handoff for the frontend
team to source or produce the asset.

AC5 All seven card states listed in scope are fully designed and
annotated in the handoff artefact; each state transition is
documented with the triggering condition.

AC6 Location staleness and location-unavailable states are visually
distinct from each other and from the nominal active state;
neither state is represented by colour change alone.

AC7 Audio stream status — connected, buffering, degraded,
disconnected — is represented by distinct iconography or
labelling that does not rely on colour as the sole differentiator.

AC8 The design passes an internal accessibility review confirming
all status differentiators are perceptible to operators with
deuteranopia and protanopia (common colour vision deficiencies).

AC9 The design handoff artefact is reviewed and signed off by the
CTO (Fiza Khan) before US-032.FE.1 enters development.

Definition of Done

• All seven card states designed and annotated in the design tool
• State transition map documented in the handoff file
• Audio alert specification written and attached to handoff
• Accessibility review passed and documented
• Responsive behaviour defined for 1280 px and above
• CTO sign-off obtained
• Handoff file linked in the Redmine ticket for US-032.FE.1