05. User Interface Design - khalillabban/Snorting-Code GitHub Wiki

User Personas

Bruce - New Student

Usage Pattern:

  • Opens the app to search for locations by name (unfamiliar with building codes)
  • Enters both starting point and destination for point-to-point navigation
  • Needs clear building identification and wayfinding

Alex - Regular Student

Usage Pattern:

  • Uses app to find classes throughout the day
  • Navigates to campus amenities between classes (restrooms, microwaves, vending machines, printers)
  • Prefers elevators over escalators
  • Looks for accessibility features that match her preferences

Jordan - Wheelchair User

Usage Pattern:

  • Uses app for campus navigation with accessibility needs
  • Searches for wheelchair-accessible routes when stairs/escalators appear
  • Expects app to remember accessibility preferences across sessions
  • Needs persistent accessibility settings (shouldn't need to re-select each time)

Alfred - Visually Impaired User

Usage Pattern:

  • Uses icons as visual aids to navigate the app
  • Relies on voice input settings
  • Listens to speech output from phone
  • Needs clear auditory feedback for navigation

Alexus - Blind User

Usage Pattern:

  • Uses earphones to listen to instructions
  • Relies on screen readers for app interaction
  • Uses gesture-based navigation
  • Requires full screen reader compatibility

Marge - Older Adult with Low Vision

Usage Pattern:

  • Frustrated by small text, needs adjustable font sizes
  • Seeks settings menu to increase text size
  • Prefers audio functionality turned off
  • Looks for clear visual prompts (arrows, icons, highlighted paths)
  • Benefits from high-contrast, obvious UI elements

Equity

Moving past a "one-size-fits-all" approach and recognizing that users like Alexus, Jordan, and Alfred experience the world through various physical and sensory lenses is a necessary part of designing for equity. Accessibility is not a "feature" of the SOEN 390 mapping program; rather, it is the fundamental framework.

Our research into inclusive software design focuses on four primary pillars: visual, motor, auditory, and cognitive/literacy accessibility.

5.2.1 Visual Accessibility

To accommodate users with Red-Green-Deficiency (Alex), Blindness (Alexus), and Low Vision (Marge), the application must adhere to the WCAG 2.1 (Web Content Accessibility Guidelines).

Non-Color Reliant Indicators: We cannot rely on color alone (e.g., green for "go" or red for "blocked"). Research suggests using distinctive patterns, shapes, or text labels to convey status.

High Contrast and Scalability: For users like Marge, the UI must support a contrast ratio of at least 4.5:1 for standard text. Furthermore, the application must support dynamic type, allowing the system-wide font size to scale without breaking the layout.

Screen Reader Optimization (ARIA): For Alexus, every button and navigational node must have descriptive ARIA (Accessible Rich Internet Applications) labels. Instead of a button labeled "Button 1," the screen reader should announce "Navigate to Hall Building Entrance."

5.2.2 Physical and Motor Accessibility

For users like Jordan, who uses a wheelchair, "accessible" is a binary state: a route is either 100% usable or it is a dead end.

Persistent Accessibility Profiles: Research shows that "fatigue" is a major factor for users with disabilities. The app should remember Jordan’s preference for elevators and ramps across sessions so he doesn't have to re-configure his needs every time he opens the app.

Pathfinding Logic (Avoidance vs. Inclusion): Standard algorithms prioritize the "shortest path." Our research indicates that equity-focused algorithms must prioritize "path quality" (e.g., door width, lack of stairs, and automatic door availability).

Large Touch Targets: To assist users with hand injuries or tremors, interactive elements should be at least 44x44 points to ensure they are easily clickable without precision.

5.2.3 Literacy and Cognitive Inclusion

To support Alfred (who faces illiteracy) and Bruce (who needs high-detail spatial data), the interface must be intuitive enough to navigate without heavy reading.

Iconography and Skeuomorphism: Using universally recognized symbols (a fork/knife for food, a man/woman symbol for restrooms) allows Alfred to navigate the interface through visual recognition rather than text decoding.

Voice Integration (VUI): Voice-to-Text for searching and Text-to-Speech for directions are essential. For Alfred, the app should be able to "read" the room numbers and names aloud as he approaches them.

Spatial Consistency: For Bruce, the "Naval Engineer," the maps must maintain high spatial fidelity. Providing a 3D perspective or a "bird’s-eye view" helps users with high spatial intelligence orient themselves faster than a simple 2D line.

5.2.4 Auditory and Age-Related Design

Users like Marge often face a combination of hearing loss and a lower "tech-fluency" comfort level.

Visual-First Feedback: Any audio cue (a "ding" for a turn) must be accompanied by a visual haptic (a flash or a vibration).

Extended Timeouts: Marginalized or elderly users may take longer to process complex digital information. Alerts and pop-ups should stay on screen until dismissed, or have significantly longer durations than standard settings.

Feature Mockups

US-1.1 β†’ Toggle between campuses
US-1.2 β†’ buildings visually distinct
US-1.3 β†’ toggle campus
US-2.2 β†’ auto current location

US-2.6 β†’ shuttle

US-1.4 β†’ current building
US-1.5 β†’ building popup
US-2.1 β†’ select start/destination
US-2.7 β†’ building code labels

US-2.4 β†’ transport modes

US-2.3 β†’ outdoor directions

US-2.5 β†’ inter-campus

US-3.1 β†’ Google Calendar
US-3.2 β†’ classroom location
US-3.4 β†’ multiple calendars

US-3.3 β†’ next class directions

US-4.1 β†’ indoor maps (floors)
US-4.2 β†’ shortest indoor path
US-4.3 β†’ accessible routes
US-4.4 β†’ locate rooms
US-4.5 β†’ indoor POIs
US-4.6 β†’ multi-floor navigation

US-4.7 β†’ indoor ↔ outdoor (cross-campus)
US-4.8 β†’ indoor ↔ outdoor (same campus)

US-5.1 β†’ nearest outdoor POIs

US-5.2 β†’ directions to POIs

US-5.3 β†’ Color blind support