Peak Season Is the Product

TL;DR

Public systems have a unique truth: when they fail, everyone sees it. “Customer experience” doesn’t stay on the website, it turns into long lines, overwhelmed agents, and frustrated travelers.

A regional transit authority needed to reduce effort in its booking experience, especially during peak periods. I led multi-stakeholder research and a mobile-first redesign of booking and checkout, and validated improvements with usability testing.

Impact:

• +65% improvement in Customer Effort Score (CES) in testing.[ces]
• Mobile-first redesign delivered across key booking flows.
• Agent workflow needs surfaced and translated into an actionable tooling concept.

"Oftentimes, I'm trying to change a reservation en route... and I've got my laptop in the car and I'm trying to open it up and it's like a mess." — Frequent traveler (research interview)

---

Industry Primer

Transportation booking isn’t e-commerce. It has:

• capacity constraints and “real inventory” behavior
• policy-driven pricing and eligibility rules
• operational dependencies (call centers, field staff, dispatch) that absorb confusion

When the system is unclear, the cost shows up off-screen.

---

Context

The organization served multiple user types with conflicting needs:

• frequent travelers who expect speed
• occasional travelers who need guidance
• agents and operations staff who carry the consequences of ambiguity

The goal wasn’t “make the UI nicer.” It was to reduce effort at the worst moment: peak season, high stress, high stakes.

---

Problem

Pricing rules and flow structure created avoidable effort

Users had to infer rules they didn’t know, in moments where the consequences felt high (travel timing, vehicles, group coordination). That increased abandonment and pushed load onto support teams.

Mobile limitations amplified pressure

Mobile isn’t optional when users are traveling. Weak mobile UX increases failure demand: calls, manual workarounds, and repeated attempts.¹

Operations needed tooling, not just a prettier website

Even perfect checkout screens can’t solve peak-season reality if agent workflows and line management remain brittle.

---

Solution

Decision 1: Build a shared model across roles

I ran discovery across riders, agents, and operations stakeholders—interviewing dozens of travelers, sitting with booking agents during peak shifts, and observing operations during high-volume periods—then translated findings into:

• role-based journey models
• a prioritized problem set grounded in “why now”
• alignment artifacts that made trade-offs explicit

Decision 2: Design mobile-first for clarity and recovery

We focused on reducing cognitive load:

• clearer step structure and progress
• better error prevention and recovery
• content hierarchy that matched user intent (not internal terminology)

Decision 3: Treat ops pain as part of the product

We documented operational workflows and defined an agent tooling concept (designed but not implemented) aimed at reducing friction during peak periods. The goal was to ensure improvements didn’t simply shift effort from users to staff.

---

Results

Validated impact

Usability testing validated the redesign with a 65% improvement in CES—representing meaningfully reduced perceived effort in the tested flows, though not yet measured in production.[ces]

Durable capability

The engagement established a more effective way to prioritize:

• decisions grounded in cross-role evidence, not “loudest stakeholder”
• a service-design view that connected rider effort to operational load

---

What I'd Do Differently

I would introduce shared operational telemetry earlier, alongside usability metrics: call drivers, abandonment reasons, and peak-season handling time. When teams can see effort moving through the whole system, debates get shorter and solutions get better.

---

Collaborators

I partnered with product and engineering leaders, field operations stakeholders, and customer service leadership to ensure changes worked for both riders and the people responsible for running the system.

Footnotes

1. “Failure demand” is demand caused by a system failing to do something right the first time (repeat calls, rework, clarifying questions). ↩