myRLR: Road Service At Hand

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 designed to operationalize the relationship between customers and RapidLink Repairs—ensuring that service requests translated into trackable transactions, structured accounts, and long-term engagement.

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 was already established and successful. The challenge was designing a digital product that could support it without adding friction or uncertainty, while 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. From a business standpoint, ambiguity at submission creates operational overhead and delays; reducing uncertainty was not only a usability concern, but a way to support service efficiency and response accuracy.

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.

Step 1

Purpose: Identify responsibility and communication channel

• Who is submitting?
• Who can be contacted?
• Role context (driver vs fleet manager)

Step 2

Purpose: Enable dispatch accuracy

• Exact location
• Possibly GPS‑assisted

Step 3

Purpose: Identify affected asset

• Equipment ID (chassis, container, etc.)
• Structured lookup (if applicable)

Step 4

Purpose: Capture problem context

• Structured issue categories
• Optional descriptions
• Possibly multiple issues

Step 5

Purpose: Confirmation & commitment

1. Clear summary
2. Explicit confirmation
3. Next steps visibility

Step 6

Purpose: Transparency & continuity

• Status updates
• Service history linkage
• Billing connection

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 drives better outcomes under pressure. This also reduced back-and-forth clarification between customers and operators, helping contain service handling costs.

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)

Re – Flow

The flow was refined by merging some information components to reduce the number of steps in the process. This helped keep the stepper concise while maintaining the essential information required to submit a request.

Driver information

Driver details and location are captured together in this step.

Specific fields allow additional context and help make on-field location easier to provide.

Equipment information

Users identify the affected equipment by entering or selecting its ID, linking the request to a specific asset.

Add Issues

Users report the problems affecting the equipment, with optional descriptions for additional context.

Submission

Users review the request details and confirm submission.

Status tracking

Users can track request progress and chat with the RapidLink Repairs contact managing the asset.

Supporting features

In addition to the Service Request flow, MyRLR includes supporting features that enable ongoing business operations between customers and RapidLink Repairs. These features were designed using the same navigation pattern—a list of items leading to individual item views—to keep the experience simple and consistent across the product.

Company Management

Users can create, view, update, and manage company records within the platform.

User Management

Users can create, update, and manage user accounts associated with each company.

Invoices

Users can view and manage invoices. From here, they can also initiate the Pay Invoice and Dispute Invoice flows.

Together, these features connect service requests with account structure, billing, and historical records—supporting the ongoing business relationship between customers and RapidLink Repairs.

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.

One clear example of this is the Sign-Up feature. The team initially explored custom sign-up and login flows. As discussions evolved, we decided to integrate Microsoft Entra ID to manage authentication and identity. This decision avoided unnecessary complexity and allowed the team to focus on the core service experience.

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 depends on making the right decisions at the right moment, especially under delivery constraints.

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 establishes a digital foundation that allows RapidLink Repairs to scale operations, measure performance, and evolve the service model through real usage data. Dependable when it matters—which, in road service, is exactly the point.