Uira Labs | Campus Navigator PRD

Document meta

Product: Campus Navigator
Type: Web app (mobile-first)
Owner: UiraLabs
Status: Draft v1
Target launch: MVP for 1 campus, then expand

1) Problem statement

Students waste time and experience stress navigating campus, especially during the first weeks of term and between back-to-back classes. Generic maps often fail on campuses because they do not reflect how students actually move: pedestrian paths, correct entrances, connectors (tunnels/skybridges), restricted zones, construction closures, and confusing building naming conventions.

We need a student-friendly way to get from "Where am I?" to "I'm here" quickly, reliably, and with clear directions.

2) Goals and non-goals

Goals (MVP)

Provide fastest walking route from current location to a campus destination.
Make it easy to find destinations by student intent (buildings, dining, services).
Give clear step-by-step directions students can follow without ambiguity.
Establish trust: routes generally match real campus traversal (paths + entrances).

Non-goals (MVP)

Indoor room-by-room navigation (turn-by-turn inside buildings).
AR navigation.
Social / friend location.
Public transit routing.
Full cross-campus scaling automation (start with one campus + repeatable process).

3) Target users and use cases

Primary persona: Student (under time pressure)

"I'm late - get me to Building X fast."
"Where is the financial aid office?"
"Which entrance should I use?"

Secondary personas

New students / visitors: first-week orientation, campus tours.
Faculty/staff: finding offices/services occasionally.
Campus ops (later): path closure updates (optional future).

4) Success metrics

North Star (MVP)

Successful route completion rate. Proxy: user reaches destination (or confirms "Found it") with minimal reroutes / abandonment.

Supporting metrics

Time-to-first-route: open app to start navigation (lower is better).
Search success rate: queries that result in a destination selection.
Route abandonment rate: navigation started but not finished.
Reroute rate: route recalculated due to deviation.
"Wrong destination" reports (trust-breakers).
Week-1 retention (first two weeks of term): WAU/DAU + routes per active user.

Guardrails

Page load time (P95), route compute latency (P95).
Location permission opt-in rate (do not tank usability).
Battery usage (keep minimal; web constraints).

5) Scope (MVP)

User flows

Open app to locate me.
Search / browse destination.
Choose destination to see route overview.
Start navigation with step-by-step directions.
Arrive and confirm completion.
Optional: report issue (missing path, wrong entrance, closed walkway).

Core features

Destination discovery

Search by name + synonyms (e.g., "Student Center").
Browse categories: Buildings, Dining, Services.
Destination detail: name, description, hours (optional), entrances (if known).

Routing

Walking route from current location to destination.
Route follows campus paths (not driving roads).
Choose best entrance when destination has multiple entrances (if data exists).
Reroute when user deviates beyond threshold.

Directions

Step list ("Walk 200 ft along...", "Turn left at...").
Simple map view with route line + user dot.
Progress indicator: distance/time remaining.

Feedback loop

"Report a problem" with preset types: wrong location pin / wrong entrance; path missing / inaccessible; closure / construction; destination not found / naming issue.
Lightweight optional comment + screenshot toggle.

6) Functional requirements

Search and discovery

FR1: Search returns relevant destinations within 300ms (P95) on cached dataset (client or edge).
FR2: Support synonyms/aliases (building codes, common student names).
FR3: Category browse works without typing (Buildings/Dining/Services).
FR4: Results show distance/ETA once location available.

Location

FR5: Request location permission gracefully; provide fallback if denied (manual start point selection or browse-only).
FR6: Handle GPS drift with smoothing and a "recenter" control.

Routing engine

FR7: Compute walking route using campus graph: nodes (intersections/entrances), edges (paths) with weights (distance/time).
FR8: Avoid restricted edges (private, closed, stairs if accessibility enabled).
FR9: Reroute when user deviates > X meters for Y seconds (tunable).
FR10: Return ETA based on typical walking speed, optionally personalized later.

Directions presentation

FR11: Render route polyline + step list.
FR12: Steps should be short, human-readable, and stable (avoid flip-flopping).
FR13: Provide "Start over / End navigation" controls.
FR14: "Arrived" state triggers when within radius of destination entrance (tunable).

Reporting

FR15: Report flow completes in < 20 seconds.
FR16: Reports store minimal PII; include timestamp, geo area, selected destination, route id.

7) Non-functional requirements

Performance

Initial load: P95 < 2.5s on mid-tier mobile.
Route compute: P95 < 500ms for typical campus route.

Reliability

Works with intermittent connectivity after first load (basic offline cache of campus graph + destinations).

Privacy and security

Location used only for routing; do not sell data.
Minimize retention of raw location traces (prefer coarse + ephemeral).

Accessibility

WCAG-friendly contrast, keyboard navigable search, screen-reader labels.
Optional "Accessible routes" toggle if data supports.

8) UX requirements (MVP screens)

Home: Search bar (sticky), categories, "Use my location" prompt + fallback.
Search results: Top results + categories, distance/ETA once location known.
Destination detail: Name, category, optional hours, primary entrance (if known), CTA: "Get directions".
Route overview: Map + summary (ETA, distance), CTA: "Start".
Navigation: Map + step list, recenter + reroute indicator.
Arrived: "You're here" + "Found it" confirmation, "Report issue" shortcut.

9) Data model (minimum viable)

Entities

Place: id, name, aliases[], category, lat/lng, entrances[], metadata.
Entrance: id, place_id, lat/lng, type (main/accessible), notes.
Path graph: nodes (id, lat/lng), edges (from, to, distance, constraints flags).
Closures (optional in MVP): edge_id, start/end time, reason.

Data sources (assumptions)

Seed with campus GIS/OpenStreetMap + manual corrections.
Maintainable admin process (even if internal-only initially).

10) Technical approach (implementation-neutral)

Assumptions

Start with one campus to validate the end-to-end loop (data to routing to trust).
Use a graph-based routing algorithm (e.g., Dijkstra/A*).
Host data behind a simple API; cache on client/CDN.

Components

Client (web): map rendering + UX + offline cache.
Routing service (or edge function): route computation + step generation.
Places service: search, alias handling.
Feedback service: issue reports + triage queue.

11) Rollout plan

Phase 0 - Prototype (internal)

One campus, limited destinations, validate routing correctness on real walks.

Phase 1 - MVP launch (campus beta)

Full campus graph, major buildings + dining + services.
Feedback enabled, weekly map fixes.

Phase 2 - Harden + scale

Better aliasing, closures pipeline, accessibility routes where possible.
Repeatable "new campus onboarding" playbook.

12) Risks and mitigations

Trust failure from wrong routes: launch with limited scope + heavy QA routes; prioritize correctness over features.
Map data drift (construction, closures): lightweight reporting + scheduled termly audits; optional closures feed later.
GPS drift causing confusion: smoothing, recenter, manual start override.
Scaling to multiple campuses: define a standard campus data spec + onboarding checklist early.

13) Open questions (safe assumptions for now)

Which campus is the first target? (impacts data availability + QA)
Will we support accessibility routing in MVP or post-MVP?
Do we need classroom-level destinations (e.g., "ENGR 101") or just buildings?

Back

Campus Navigator - PRD (v1)