Case study sections

Trail Sections case study

Bridging the gap between trail closures and detours.

Bridging the gap between trail closures and detours.

Bridging the gap between trail closures and detours.

4 weeks · Solo project

4 weeks · Solo project

UX/UI · Data visualisation · Figma prototype

UX/UI · Data visualisation · Figma prototype

View the prototype

View outcomes

← Top

1. Project summary & introduction

1. Project summary & introduction

1. Project summary & introduction

2. Testing, feedback & iteration

→

Overview

The project at a glance

Role: End‑to‑end Product/UX Designer (research → IA → prototyping → testing → visuals)

Scope: Mobile web tool to help trail users quickly understand closures and choose detours while preserving a sense of discovery.

Timeline: 4 weeks (2024)

Team: Solo; informal collaboration with trail users during interviews and on‑site testing.

Deliverables: Research notes & synthesis, flows, wireframes, high‑fidelity prototype, icon set, data‑viz patterns, presentation deck

Tools: Figma, Miro, Google Sheets, on‑site photo survey

Section 1 of 8

Project summary & introduction

A video showing various screens, components and the logo animation for the project.

Summary

Trail Sections is a mobile concept that turns closure and detour data for Toronto’s Lower Don Valley Trail into a glanceable, decision-first view. It leans on bridges—familiar landmarks—to anchor orientation and choices, centralising only what matters so people keep moving.

Why bridges: Based on my own experience using the Lower Don over time, bridges consistently functioned as the natural wayfinding anchors. I validated this by reviewing Strava: user‑created segments frequently use bridges as start and end points, and uploaded photos often centre bridges as reference markers. In interviews, most participants couldn’t name nearby streets but brought up bridges unprompted.

Problem

During prolonged closures, information is scattered across multiple city pages and inconsistent on‑site signage. Users arrive at barricades with no clear detours and either backtrack or abandon the trail. Existing sources over‑index on granular updates and under‑serve the immediate, on‑the‑spot need: Which way should I go right now?

Role and responsibilities

  • Planned and conducted desk research and semi‑structured interviews

  • Analysed Strava segments and user‑uploaded images to validate the bridge mental model

  • Mapped insights in Miro and quantified patterns in Google Sheets

  • Defined IA and visual patterns (bridge‑based segments; modified network diagram)

  • Built interactive prototype and ran moderated and A/B tests

Goals

  • Be scannable at a glance (reduce time to decision)

  • Preserve a sense of discovery (avoid over‑specifying the journey)

  • Minimise phone reliance (only surface what’s essential)

Key challenges

  • Reducing intimidation for newcomers while respecting expert workflows.

  • Explaining service types, pricing, and lead times in plain language.

  • Capturing the right job details early without overwhelming users.

  • Balancing a friendly tone with a minimal, “white-cube” aesthetic familiar to galleries.

Constraints

  • On-site signage can be vandalised/removed — prioritise personal devices.

  • No official live data feeds — rely on field observation and user reports.

The before and after

Without the prototype trail users were met with a crudely barricaded trail entrances difficult to navigate information online when a cause was searched for.

Before: Barricaded entrances, sparse/ineffective signage, and a low‑visibility Bayview detour; information fragmented across 3–5 sites.

After: A single mobile place to check which bridge sections are open, what the detour looks like, and how to re‑enter—reducing search time and cognitive load.

Section 2 of 8

Testing, feedback, and iteration

Understanding the stakeholders

  • Trail users: walkers, runners, cyclists with varying familiarity

  • City context: closures for flood mitigation and upgrades; limited, changing notices

Insight → decision → evidence

1) People orient by bridges, not maps
Decision: Divide the trail into bridge‑anchored sections and show “next bridge” context.
Evidence: User photos and interviews highlighted bridges as the most memorable landmarks; on‑site walkthroughs confirmed this mental model.

2) Full maps slow decisions at the moment of need
Decision: Remove full map from the primary flow; use a simplified linear diagram with detour bifurcations.
Evidence: Moderated tests showed faster comprehension with the linear diagram vs. map tiles.

3) Summaries should use standard charts
Decision: Replace image‑heavy summaries with familiar chart formats.
Evidence: A/B sessions—participants interpreted standard charts more quickly and accurately.


Process

Desk research & competitive scan — catalogue sources; identify gaps

  • Strava segment + image review — analysed user‑created segments and uploaded photos showing bridges used as start/end anchors

  • Semi‑structured interviews — understand closure pain points (n≈?)

  • On‑site observation/photo survey — document signage & access points

  • Moderated usability tests — validate IA/visual patterns (n≈?)

  • A/B comparisons — chart vs. image‑heavy summaries (n≈?)

Design artefacts in Miro and Google forms used for user testing.

Section 3 of 8

Prototyping & early validation

Turning a hunch into insights

Low‑ to mid‑fidelity screens explored hierarchy and iconography before moving hi‑fi. Early rounds suggested users wanted:

  • High‑level info (open/closed, detour type, re‑entry points)

  • Clear separation between Trail Map (bridge segments) and Images

  • Minimal on‑screen time—make the next step obvious

Directional results (validation): Moderated wireframe sessions confirmed the bridge‑first IA—participants oriented by the nearest bridge without knowing street names. A/B tests of data visualisation showed standard charts improved scanning speed and accuracy versus image‑heavy summaries.

Low fidelity wireframes made for usability testing and determining layouts.

Section 4 of 8

Refinements & design system

Turning findings and structures into systems

  • IA — Shallow, two‑track structure: Trail Map (bridge segments) and Images live separately to reduce cognitive load. A breadcrumb pins your current bridge → next bridge.

  • Diagram — Modified linear/network diagram mirrors real bifurcations at detours and shows re‑entry points at the next bridge.

  • Components — Status chip (Open / Closed / Detour), Detour card (surface, distance, estimated time), Re‑entry marker, Bridge selector, Global alert banner.

  • States & behaviours — Offline notice with essential info cached; graceful handling when location is disabled; empty‑state for “no current closures”.

  • Content pattern — For each bridge section: status → detour option → surface (road vs nature) → distance/time → re‑entry.

Video showing the refinements from the Initial mapping of the data in Miro to the design of the visualization in the project.

Section 5 of 8

Visual language

Function and familiarity

A restrained, map‑adjacent palette with strong contrast and non‑colour encodings (shape, line, labels). Typography favours quick scanning with generous spacing and large tap targets. Icons are always paired with text; photos are used for context only and are captioned to highlight what to notice. Data‑viz uses standard chart forms to minimise interpretation time.

Above: A large billboard advertisement showing the brand's playful yet task-oriented identity.
Below: A mockup of a truck used in shipping. Due to the nature of services offered, the logo needed to be highly legible and work well on transport trucks.

Section 6 of 8

The prototype

Most important flow — find a way around a closure

Flow: Open → Open site→ See see current location → Find detour

Why it works: Immediately bring you to needed information without navigation on the site.

This video shows the flow from navigating to the site starting from opening a QR code.

Interactive prototype

Try it yourself! Explore the app on your own. (location is not functional in prototype)

Figma prototype link

Section 7 of 8

Accessibility considerations

Considering ability from the start

  • WCAG AA contrast; avoid colour‑only meaning (icons + labels + patterns)

  • Tap targets ≥ 44px; visible focus indicators; keyboard and screen‑reader friendly

  • Clear, plain‑language labels; error messages with next steps

  • Reduced‑motion friendly; motion is decorative only

  • Offline‑friendly: essential info available without network where possible

Tap target size FAB and other buttons in the UI

Section 8 of 8

Learning and outcomes

Key numbers (prototype tests)

  • Time‑to‑decision: ~10s median (baseline unkown as all participants reported abandoning the task without the prototype)

  • Chart comprehension accuracy: 100% vs image‑heavy summaries, n=8

Impact of the project

  • Faster information access: One place for closure status, detour, and re‑entry.

  • Lower cognitive load: Linear diagram and bridge anchors reduce decision friction.

  • Likely impact post‑ship: Higher detour adherence; fewer abandoned trips.

What I delivered

  • Prototype covering bridge‑based sections, detours, and images

  • IA, iconography, and data‑viz components

  • Research synthesis and a presentation deck

What I’d do next

  • Develop site including location functionality

  • Expand to adjacent trails and re‑test with a larger, more diverse cohort

  • Create a small signage kit aligned with the digital model (bridge codes, re‑entry markers)

Key learnings

  • Match the mental model users already hold (even when it is counter-intuitive) rather than fight it

  • Standard chart forms outperform decorative visuals for fast comprehension

  • Outdoors, fewer choices per screen keeps people in the environment—not in their phones