Roam

Getting around a city shouldn't require five different apps — but for most urban travelers, it does.

My Role

UX Researcher/Designer

Methods

Persona development · Scenario creation · Wireframing · Usability testing · Prototyping

Tools

Axure · FigJam · Zoom · Microsoft Excel

Can't wait to see it?

The Problem

One app for rideshare, another for the subway, a third for bike share, maybe a fourth for scooters. Each has its own interface, its own payment system, its own way of displaying routes and wait times. Comparing across modes means bouncing between apps and doing mental math across multiple screens.

Roam was designed to address this fragmentation — a single mobile app with a smartwatch companion that consolidates rideshare, taxi, and public transit into one experience. The challenge wasn't just interface design. It was understanding who actually uses these different modes, in what contexts, and where the fragmented experience creates the most friction.

Research Questions

What factors drive urban travelers' transportation decisions across modes?

Where does the current multi-app experience create the most friction?

Does the proposed interface allow users to successfully find and compare route options?

What We Did

Personas and Design Tenets

Before any wireframing, we grounded the design in three personas representing the range of travelers the app would need to serve: Erin (budget traveler, prioritizes cost), Xavier (daily commuter, prioritizes speed and reliability), and Mary Jane (infrequent tourist, needs clear guidance and error recovery).

From the persona work, we defined three design tenets to guide every subsequent decision: clarity over comprehensiveness, trust through transparency, and flexibility without confusion.

Lo-Fi to Mid-Fi

We started with rough sketches to explore the core interaction model — how a user would enter a destination, what the route selection screen would look like, how multiple transportation options would display side by side. We also built a narrative prototype, a storyboard-style walkthrough of an end-to-end experience, which helped us identify early that the transition between browsing route options and confirming a selection needed more visual clarity than our lo-fi suggested.

We built out mobile and smartwatch mid-fidelity prototypes in Axure based on the narrative design. This served as the primary artifact for usability testing.

Mood Board

Before moving into digital prototyping, each team member put together their own mood board with no shared constraints or starting points. The goal was to explore colors, aesthetics, and visual references freely before converging on a direction. We then combined all four into one collective mood board to use as shared inspiration for the visual design. The result pulled toward a clean, urban feel: city photography, transit systems, bold typography, and a palette grounded in deep navy and teal.

Scenarios

We wrote four scenarios tied directly to our personas to make sure key design decisions were grounded in realistic use cases. Erin's focus on affordability shaped the fare comparison and saved routes features. Xavier's need to move fast drove the quick ETA lookup flow. Mary Jane's reliance on glanceable information while navigating an unfamiliar city informed the smartwatch integration and cross-device experience. The scenarios were used to validate the narrative prototype and guide what we prioritized in mid-fidelity.

Usability Testing

We recruited four participants and ran three task-based scenarios: finding and selecting a route, applying filters or sort criteria, and saving a frequently used route. Participants completed tasks while thinking aloud, and we recorded observations, confusion points, and completion times.

Participants described the app as intuitive, visually clean, and easy to navigate, with most completing their tasks quickly and with minimal difficulty. The fare comparison screen and saving feature were well received, reinforcing Roam’s value as a convenient, all-in-one travel companion. However, several usability challenges emerged, including confusion between the sort and filter functions, uncertainty about saving routes, and minor interface issues.

Key Findings

Task performance was generally strong. Participants rated each scenario an average of 4.0 - 4.5 out of 5 for ease, and most core interactions were understood quickly.

Two issues came up consistently:

Sort vs. filter confusion

Multiple participants conflated the two controls, attempting to use one when they needed the other. The visual distinction between them wasn't sufficient to signal meaningfully different interactions. Some participants explored both before landing on the right one.

Route saving uncertainty

The save feature was less discoverable than we expected. Participants who found it weren't confident the action had actually worked. One asked directly, "Did that actually save?" — a clear sign the system's feedback wasn't doing enough.

Design Changes

Testing directly drove four changes before moving to high-fidelity:

"Schedule Later" feature

Testing revealed participants mentally associated route planning with immediate departure. We added the ability to schedule a trip in advance, which also helped clarify the distinction between browsing now versus planning for later.

Responsive bottom panel

The expansion and resting behavior of the route selection panel was refined based on how participants naturally tried to interact with it.

Route categories

Participants wanted results grouped by priority rather than a flat relevance-ranked list. We organized into: Fastest, Cheapest, and Recommended.

Confirmation modal

To address save uncertainty, we added explicit confirmation when a route was successfully saved. One extra step, significantly less confusion.

Style Guide

A logo designed to evoke a map waypoint

The shape abstracts a location pin while the negative space forms an "R" for Roam. Clean and immediately recognizable, it communicates navigation and place without over-explaining.

Urban, calm, and clear

A deep navy anchors the palette, grounded and trustworthy, with a bright blue accent to signal movement and clarity. Secondary colors orange, yellow, and green are used sparingly for status indicators and notifications, keeping the overall identity neutral and purposeful without feeling sterile.

Readable by design

Poppins is used for the logo and display text, bringing a geometric softness to the brand. Roboto handles all UI text — readable, neutral, and reliable at any size. Icons follow the same logic: simple, outlined, and immediately legible, covering the core actions of navigation, booking, and saving without visual noise.

Prototype

01

Introductory screens were designed to welcome users upon opening the app, introducing Roam’s purpose and core features before they begin navigating.

02

We introduced a “Schedule Later” option, allowing users to view future ride estimates, an enhancement inspired by participants who wanted to plan trips in advance.

03

The option to save routes allows users to save time and store frequent origin-destination pairs.

04

A side-by-side fare comparison across all available modes, with sort/filter options and one tap to book through the provider.

Reflection

Roam was my first experience running a structured usability study from start to finish — designing the test plan, writing task scenarios, facilitating sessions, and synthesizing findings into concrete design revisions.

The gap between "makes sense to us" and "makes sense to users" is real.

The sort/filter confusion was something I genuinely didn't anticipate. From a design perspective, the two controls felt distinct. From a first-time user's perspective, they looked like variations of the same thing. Watching that play out across multiple participants was a useful reminder that familiarity with your own design is a bias worth actively fighting.

Concrete numbers help.

Having task scores, even from a small sample, gave us an objective reference point. Rather than debating which design was "better," we could point to what participants actually struggled with and why.

Testing at mid-fidelity was the right call.

We had enough interface detail for participants to engage with real interaction patterns, but not so much polish that they were reluctant to give critical feedback. Mid-fi produced more honest responses than a finished prototype would have.

If I continued this project, I'd focus on testing the redesigned flows with participants who match the tourist persona — users unfamiliar with both the city and the app since they represent the most demanding use case and the one where our design assumptions are least likely to hold.