myRLR: Road Service At Hand [wip]

Introduction

This case study documents the design of MyRLR, a digital product created to support the launch of RapidLink Repairs, a new DCLI subsidiary focused on road services.

The goal was to launch a functional MVP—fast enough to get into the market, but solid enough to learn from. Early delivery was a deliberate strategy to unlock insights, validation, and feedback as soon as possible, even if that meant adapting the UX process to fit the team’s sprint-based workflow.

While the Service Request was the core interaction, MyRLR was designed as an end-to-end product to enable business between customers and RapidLink Repairs. Supporting features such as company and user management, invoicing and payments, and road service history were intentionally included to make the service operationally viable, trustworthy, and scalable.

I led UX direction for the project as part of a cross-functional team including a Product Owner, Business System Analysts, QA, and Development. The UX team was distributed across Colombia (my location), the United States, and India, which meant async collaboration, clear ownership, and fewer meetings than feelings. Surprisingly effective.

Beyond design execution, my role involved negotiating priorities, boundaries, and design tradeoffs with Product and Development. This case focuses on how UX leadership helped shape a deliberately constrained MVP—designed not just to ship, but to learn.

Discovery

Understanding urgency

Discovery focused less on uncovering new user types and more on understanding context, pressure, and expectations around road service requests.

The service operation itself was already established and successful. The challenge was not *whether* road service worked, but how a digital product could support it without adding friction—or worse, uncertainty—while still enabling a complete business relationship.

Requests are often submitted:

• Under time pressure
• In unfamiliar or remote locations
• With incomplete or uncertain information

In that context, users are less concerned with providing perfect data and more concerned with being understood and getting confirmation that help is on the way.

Discovery helped narrow the product’s responsibility. The experience needed to:

• Guide users step by step without requiring prior knowledge
• Make system feedback explicit and reassuring
• Reduce ambiguity at every stage of the request

At the same time, discovery reinforced the need for supporting capabilities—company and user management, billing and payments, and road service history—to exist around the core flow. These features ensured that once a request was completed, customers could continue doing business with RapidLink Repairs in a structured and transparent way.

Research and design activities were intentionally lightweight and iterative, aligned with sprint cycles so insights could be applied immediately rather than documented too late.

Service Request

Designing for pressure

The Service Request is the core of MyRLR. It’s the moment where everything matters: the user is under pressure, the vehicle is not moving, and the business needs clear, actionable information—fast.

Early discovery showed that requests could be initiated by drivers or fleet managers, often in stressful situations and sometimes from remote locations. In these moments, users are not exploring a product—they are trying to solve a problem and move on.

That insight shaped a key UX principle for this flow: prioritize clarity and confidence over flexibility.

One flow, multiple roles

Rather than creating separate experiences for drivers and fleet managers, we designed a shared core flow that adapts to each role when needed. This reduced complexity, improved maintainability, and avoided fragmenting the experience across personas.

Role-specific differences were handled through:

• Contextual labels and copy
• Pre-filled or restricted fields depending on the role
• Clear confirmation states that reinforced what would happen next

The goal was simple: regardless of who submitted the request, the experience should feel fast, predictable, and reassuring.

Reducing cognitive load under stress

Because requests often happen under time pressure, we intentionally limited:

• The number of required inputs
• Optional paths and secondary actions
• Opportunities for ambiguity or interpretation

We optimized the flow to be completed quickly, accepting reduced flexibility as a tradeoff. The assumption was that a request submitted with confidence is better than a perfect request submitted too late.

Error handling and recovery were treated as first-class citizens. When something went wrong, the interface focused on:

• Plain-language explanations
• Clear guidance on how to fix the issue
• Avoiding blame (the system failed, not the user)

How the Service Request connects to the rest of MyRLR

While the Service Request was designed for speed, it did not live in isolation. Each completed request fed into a broader set of product capabilities that made ongoing business possible:

• Company and user management ensured requests were tied to the right organizations and roles
• Invoicing and payments provided clarity and trust around financial transactions
• Road service history allowed users to review past incidents, track patterns, and support operational decisions

These features were intentionally scoped to support the core flow without competing with it. Together, they transformed a single emergency interaction into a sustainable service relationship.

Shaping decisions under delivery pressure

Designing the Service Request required constant alignment across disciplines, especially as delivery pressures evolved.

On the product side, priorities were revisited more than once as the launch approached. Rather than treating scope as fixed, UX helped recalibrate conversations around outcomes—keeping the focus on what users needed to submit a request quickly and without second-guessing.

On the engineering side, some interaction needs were not fully supported by the existing design system. Relying exclusively on default components would have led to forced or unclear patterns. In those cases, UX worked with Development to extend the system thoughtfully, balancing usability, implementation effort, and future reuse.

These moments of alignment helped prevent hidden complexity from creeping into the core flow and ensured the MVP remained both buildable and credible as a real-world service.

Final Takeaways

Shipping to learn

This project reinforced that good UX leadership is less about perfect solutions and more about making the right decisions at the right moment.

Designing MyRLR meant working within fixed timelines, pre-defined organizational constraints, and a distributed team setup. To support early delivery, the UX process was intentionally adapted to the team’s sprint cadence, prioritizing just-enough discovery, fast iteration, and continuous feedback over linear phases.

With the MVP launched, the focus shifts from delivery to learning. Post-launch evaluation (planned for the end of Q1 2026) will center on adoption, reduction in phone and email interactions, and usage patterns across service requests, billing, and service history.

More than a finished product, MyRLR represents a foundation: a deliberately scoped service designed to evolve through real use, informed decisions, and continuous collaboration. Not flashy—but dependable when it matters, which, in road service, is kind of the point.

[wip]