MyRLR: Road Service At Hand

WIP

At a glance

Product

MyRLR is a responsive B2B web application, launched as an MVP, that makes RapidLink Repairs’ road service business operable end to end: from the moment a truck stops moving to invoicing and service history.

Problem

RapidLink Repairs was launching a road service business with nothing digital behind it. Requests would arrive by phone and email, carrying incomplete or inconsistent information, which meant slower dispatch, manual follow-up, and no reliable record of what had been done for whom.

Goal

Launch an MVP that lets a stranded driver or a fleet manager request service in minutes, and gives RapidLink Repairs the structure to turn every request into a trackable transaction.

Team

Three designers, two in India and me in Colombia, working with Product, BSA, QA, and Engineering. RapidLink Repairs and DCLI stakeholders from Marketing and Operations were in the U.S., and part of the development team was in LATAM.

My responsibilities

Defined UX strategy and the experience principles behind the core flow
Led a three-person distributed design team
Designed and iterated the Service Request through prototyping and usability testing
Adapted the UX process to a sprint-based delivery cadence
Negotiated scope, boundaries, and tradeoffs with Product and Engineering

My role

Lead UX Designer. Owned UX strategy and experience design from concept to MVP launch, and coordinated the design team’s work across time zones.

Overview

A new road service business, and no product to run it on

A chassis fails on a highway. The truck stops, the cargo waits, and someone has to get help moving. RapidLink Repairs was created to answer that call: a DCLI subsidiary built around road service, backed by the largest chassis fleet in the U.S. intermodal industry. The operation was ready. The product that would let customers reach it was not.

MyRLR was that product, and the mandate was a functional MVP: fast enough to launch with the service, solid enough to learn from. Early delivery was a deliberate strategy. Real requests moving through the system were the fastest way to understand what the service needed next.

The Service Request was the core interaction, but the product was never scoped as a request form. Company and user management, invoicing and payments, and service history were designed alongside it, so that a request could become an account, an invoice, and a record worth keeping.

Context

An operation that already worked, and a team spread across four countries

Road service was not a new idea inside DCLI. The operation had a defined process, people who knew it well, and customers already relying on it. That changed what the product had to do. MyRLR was not there to invent a service model. It was there to give an existing one a digital surface that would not slow it down.

The team was distributed by default. Two designers in India and me in Colombia. Product, BSA, and the RapidLink Repairs and DCLI stakeholders from Marketing and Operations in the U.S. Part of Engineering in LATAM. Overlapping hours were short, which pushed us toward written decisions, clear ownership per flow, and prototypes that could be reviewed without a meeting attached.

Delivery ran on sprints, and the UX process had to run on them too. Rather than a linear research phase followed by design, we worked in short cycles: enough understanding to make the next decision, a prototype, an evaluation, and back into the sprint. It meant giving up the comfort of a complete picture up front, and it kept design in the same rhythm as the rest of the team.

Problem

The cost of a request that starts with a phone call

Without a digital channel, every request would start as a phone call or an email. That works while volume is low and the people involved already know each other. It stops working the moment the business is meant to grow.

Information arriving incomplete

Location described in landmarks instead of coordinates. Equipment identified by appearance rather than by ID. A problem explained in whatever words come to mind next to a stopped truck. Every gap turns into a call back, and every call back is time the driver spends waiting.

Dispatch working from guesswork

Response time depends on knowing where to go and what to send. When either is uncertain, the operation absorbs the difference through clarification calls, delayed commitments, and technicians arriving without the right part.

Nothing structured after the repair

A completed service with no account it belongs to, no invoice attached, and no history to look back on. Each request stands alone, and the customer relationship restarts from zero every time.

A launch, not a legacy system

RapidLink Repairs was starting out. The absence of structure was not a debt to pay down later. It was the shape the business would take unless the product gave it a different one.

What the alternative asks for

The email route is still published on the RapidLink Repairs site, and it is the clearest picture of the problem. Submitting a road service request by email means filling in thirteen fields by hand:

Trucking or motor carrier company name
SCAC
Driver’s name
Driver’s phone number
Equipment number
Associated equipment number
Empty or loaded, and weight if loaded
Hazmat
Location: physical address, cross street, city, state
Problem type, mechanical or tire
Tire type, size, and position
Description of the mechanical failure
Whether an accident was involved

Thirteen answers, from a person standing next to stopped equipment, typed into an email on a phone. That list became the benchmark. Everything the product could answer on the user’s behalf was one less thing between a stopped truck and a technician on the way.

Challenge

Ship early enough to learn, solid enough to trust

The launch date belonged to the business. MyRLR had to be usable when RapidLink Repairs opened for service, which set the timeline before the first screen existed. Scope was the only variable we could move.

That framed the design problem as a question of what to protect. An MVP under a fixed date invites two failure modes: shipping something so thin that customers stop trusting it after one attempt, or defending so much scope that nothing ships at all. The work was finding the version that could go out on time and still hold up the first time a driver used it on the shoulder of a highway.

Three requirements were treated as non-negotiable:

A request completed in minutes, under stress, on a phone. Whatever else changed, this could not become a form that assumes a desk and a free afternoon.
Enough information for dispatch to act without calling back. Speed for the user means nothing if the operation has to reconstruct the request afterward.
Structure beyond the request. Accounts, invoices, and history had to exist at launch, so that the first service turned into a customer instead of a one-time transaction.

Everything else was open for negotiation, and most of it eventually was.

Understanding the operation

What actually happens when a truck stops moving

The service already worked. What we needed to understand was the situation it gets called into, and what it costs the operation when that call arrives unclear.

We worked from the people who run the service. Operations and RapidLink Repairs stakeholders knew the request patterns, the questions dispatch always ends up asking, and where the process stalled. FigJam held everything as it accumulated, which mattered with the team split across four countries. The board stayed open through the whole project rather than closing at the end of a phase.

That knowledge was never the last word. The Product Owner and the operation’s manager took our ideas back to real users and returned with the correction, which kept the loop short enough to fit inside a sprint. Later in development, once there was enough product to exercise, users tested MyRLR directly across different scenarios. Those sessions are where the core flow changed shape, and I come back to that in the Service Request.

Requests come from two places. A driver stopped somewhere on a route, or a fleet manager acting on a call they just received. Neither is browsing a product. They have a problem in front of them and a schedule already slipping.

Three conditions showed up consistently:

Time pressure. The clock started before anyone opened the app.
Unfamiliar locations. Rest stops, shoulders, yards the driver has never been to.
Incomplete information. Equipment IDs that require walking around the chassis to read, damage that is easier to point at than to name.

Under those conditions, precision is not what people are trying to deliver. They want to be understood and to know that help is on the way. Anything the interface demands beyond that competes with the situation they are actually in.

The operation reads the same moment from the other side. Every ambiguity at submission becomes work later: a call back to confirm the location, a second call about the equipment, a technician dispatched with the wrong part. Reducing uncertainty at intake was a usability decision and an operational one at the same time.

The last thing this stage settled was the shape of the product. Solving the request in isolation would have produced a very good form and very little else. For RapidLink Repairs to build a business on it, the request had to land somewhere: an account it belongs to, an invoice it generates, a history that survives it. That is what put company and user management, invoicing and payments, and service history in the MVP instead of a later release.

Experience principles

The criteria that settled every decision in the core flow

Clarity over flexibility

Flexible products let people work the way they prefer. Someone standing next to a stopped truck has no preference. They have a problem and a schedule already slipping, and every option offered is a decision they have to make before help starts moving.

In the product: one path through the request, few branches, no configuration. What we gave up in flexibility we recovered in speed and in requests that arrive complete.

No prior knowledge required

The person submitting may have used MyRLR once, or never. Training was not going to happen on the shoulder of a highway, and a product that assumes familiarity fails exactly the first time it matters.

In the product: a stepped flow that carries the user forward one decision at a time, with the purpose of each step visible on arrival and nothing that has to be learned before starting.

Say what is happening

Operational users trust tools that account for themselves. Silence after submitting a request reads as failure, and the fallback is a phone call to ask whether anything happened at all.

In the product: explicit confirmation at submission, visible next steps, and status tracking with a direct line to the RapidLink Repairs contact handling the asset. Errors explain the situation in plain language and point to the fix, without putting the fault on the user.

Ask only for what only the user can answer

This one came out of testing. Every field on the screen is time the user spends and an opportunity for the request to arrive wrong. The system already knows who is logged in, which company they belong to, and what equipment is associated with that account.

In the product: fields reduced to what the situation genuinely requires, and everything else prefilled from the logged-in context. The user confirms rather than types.

Service Request

Designing for pressure

The Service Request is the center of MyRLR. Everything else in the product exists because this interaction happens: the truck is stopped, the schedule is slipping, and the business needs enough information to send the right technician to the right place with the right part.

It is also the flow where the four principles collide. Speed pulls one way, completeness pulls the other, and the person deciding between them is standing on the shoulder of a highway. Most of the design work on MyRLR was spent on this single flow.

One flow, two roles

Requests come from drivers and from fleet managers, and the early instinct was to build for each. Two entry points, two flows, two sets of copy.

We built one instead. A fleet manager submitting on behalf of a driver and a driver submitting for themselves are answering the same questions in the same order; what changes is who holds the answers. Splitting the flow would have doubled the surface to maintain and fragmented the experience for the many people who are both, depending on the day.

The difference is handled inside the flow rather than before it:

Contextual labels. The same field asks for your phone number or the driver’s, depending on who is submitting.
Prefilled and restricted fields. A driver’s own details arrive already filled. A fleet manager gets the company’s drivers and equipment to choose from.
Confirmation that matches the sender. What happens next is different when you are the person waiting next to the truck and when you are the person who has to tell them help is coming.

Regardless of who submits, the request that reaches dispatch has the same structure. That was the point: one shape of data on the operational side, two ways of arriving at it.

Company Admins
Fleet Managers

Office-based users responsible for managing companies, users, and service requests, and often acting as intermediaries between the business and truck drivers.

Basic Users
Truck Drivers

End users who, frequently in emergency situations and remote locations, need to request road service quickly, clearly, and with minimal friction.

The first structure

The initial flow was organized around what each step needed to establish, six steps, each with a single job:

Step 1. Identify responsibility and communication channel
Who is submitting, who can be reached, and in what role.

Step 2. Enable dispatch accuracy
Where the equipment is. Open question at this stage: how much of that could come from the device rather than from the user.

Step 3. Identify the affected asset
Which chassis or container. Open question: whether the ID would be typed from the equipment itself or selected from what the account already knows.

Step 4. Capture problem context
What is wrong, in categories dispatch can act on, with room to describe the rest.

Step 5. Confirmation and commitment
A summary worth reading, an explicit confirmation, and visible next steps.

Step 6. Transparency and continuity
Status after submission, connected to service history and to billing.

The structure was sound. Each step had a defensible reason to exist, and dispatch would have received everything it needed. What it did not account for was how the sequence would feel to someone completing it under the conditions we had documented.

What testing changed

Once there was enough product to exercise, real users ran the flow across different scenarios. The structure held. The length did not.

The finding was consistent and blunt: every step is a threshold, and every field is a small negotiation with a person who has no patience to spare. The flow was not confusing. It was longer than the situation could absorb, and it kept asking for information the system was already holding.

Two responses came out of that, and they define the flow as it shipped.

Fewer steps, by merging what belonged together. Some steps were separate for conceptual tidiness rather than for the user’s benefit. Driver details and location, for example, are one moment in practice: you are saying who you are and where you are. Merging components brought the stepper down to a length that reads as short before you start, which matters as much as how long it actually takes. What survived is what genuinely required a separate decision.

Prefilling everything the system already knew. This was the larger shift. The person is logged in, which means MyRLR knows who they are, what company they belong to, how to reach them, and which equipment is associated with that account. Asking them to type any of it was asking them to re-enter data the system could supply. We rebuilt the flow around confirming rather than typing: context fills the form, the user corrects what does not match, and the fields left open are the ones only they can answer, namely where they are and what is wrong.

Together those two moves reduced the flow to its essential inputs. The stepper got shorter, the typing nearly disappeared, and the information reaching dispatch stayed complete.

The flow as it shipped

Four steps to submit, and one that keeps working after submission.

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.

Driver information and location

Who is on site and where. For a driver submitting their own request, the identity fields arrive filled from the account and the work is confirming them. Location is the field that carries the most weight in the whole flow, so it accepts more than an address: specific fields let people describe where they actually are, which is often a mile marker, an exit, or a lot with no street number.

Equipment information

The affected chassis or container, entered or selected by ID, which links the request to a specific asset. For fleet managers, the account’s equipment is there to choose from. For drivers, the ID is on the equipment they are standing next to.

Add issues

What is wrong, reported as structured issues so dispatch can act on them, with optional descriptions for anything the categories do not cover. More than one issue can go on a single request, because equipment rarely fails politely.

Submission

The full request in one view, with an explicit confirmation. This is the last moment where a mistake is cheap to fix, so the summary is written to be read quickly rather than to be complete for its own sake.

Status tracking

After submission the request stays live. Progress is visible, and there is a direct line to the RapidLink Repairs contact managing the asset. The phone call the product was built to replace is still available, except now it starts with both sides looking at the same request.

On a phone, on the shoulder of a highway

The desktop version matters for fleet managers working from an office. The mobile version is the one that decides whether the product works.

A driver opens MyRLR outside, standing next to stopped equipment, often in weather, sometimes at night, holding a phone in one hand. That situation set constraints the rest of the design had to respect: touch targets that survive gloves and hurry, one primary decision per screen, no horizontal scrolling on any input, and a stepper that shows how much is left so the flow never feels open-ended.

It also made the prefilling decision structural rather than convenient. Typing on a phone in those conditions is the single most expensive thing the interface can ask for, and every field removed was measured against that.

When something goes wrong

Errors in this flow arrive at the worst possible moment, and the interface has one job when they do: keep the person moving.

Plain language. What happened, in the words someone would use to explain it out loud.
A way forward. Every error message says what to do next, not just what failed.
No blame. When a submission fails, the system failed. The copy never suggests otherwise, and never asks the user to figure out which of their inputs caused it.

Ambiguity was treated the same way as failure. A request that submits without clear confirmation is, from the user’s side, a request that may not have happened. That uncertainty sends them to the phone, and the operation absorbs the call. Explicit confirmation was cheaper than the alternative for everyone involved.

What we traded away

The flow is fast because it is narrow. There is one way through it, few options, and little room to work around the path we designed. A user with an unusual situation has less room to describe it than a more flexible product would give them.

That was a deliberate bet: a request submitted with confidence produces a better outcome under pressure than a request that could have been more precise but took longer and left the user unsure it went through. The operation reads it the same way. Fewer clarification calls, faster dispatch, and a lower cost to handle each service.

Supporting features

What turns a request into an ongoing business relationship

The Service Request is what people remember. These are the features that make it worth building.

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.

A completed repair with nothing behind it is a favor. For RapidLink Repairs to run a business, every request had to belong to a company, generate an invoice, and leave a record that outlives it. That is why account structure, billing, and history shipped with the MVP rather than after it.

One pattern, applied everywhere

All supporting features use the same structure: a list of items leading to an individual item view.

That was a deliberate constraint rather than a default. These are the parts of the product people use when nothing is urgent, and consistency here pays for itself twice. Users learn one navigation model and apply it to everything outside the request flow, and the team could build and extend these areas without relitigating structure each time. It also meant the design attention could stay where the difficulty actually was.

Company management

Create, view, and maintain company records. This is the layer that makes every other object in the product belong to someone.

User management

Create and manage the user accounts associated with each company, which is also what makes the prefilling in the Service Request possible. The context that fills the form for a stranded driver is maintained here, weeks earlier, by someone at a desk.

Invoices, where the complexity actually lived

Billing was the least glamorous part of the product and the one that took the most careful thinking. A road service invoice arrives after an event the customer experienced as a problem, which means it is read with more scrutiny than most documents in a B2B product.

From the invoice list, users reach an individual invoice and from there two flows: Pay Invoice and Dispute Invoice.

Paying was scoped down on purpose. Rather than building transaction handling ourselves, payment processing was delegated to a contracted service. Our responsibility ended at sending the right information through an API, and everything transactional happened on the other side. That kept a whole category of complexity, and its compliance burden, outside an MVP that had a launch date to meet. What stayed on our side was the experience around the handoff: making clear what was being paid, what would happen next, and where the user would land when they came back.

Disputing could not be scoped down the same way. A dispute is a customer telling you that something in the record is wrong, and the product has to receive that well or the relationship pays for it. The flow had to capture what was being disputed and why, in a form specific enough for someone at RapidLink Repairs to act on, without turning the customer’s objection into an interrogation.

Together, these features close the loop the Service Request opens. A request becomes a job, a job becomes an invoice, and an invoice becomes history that both sides can point to the next time equipment fails. That continuity is what separates a service business from a series of unrelated rescues.

Tradeoffs

Where UX held the line, and where it gave ground

A fixed launch date turns every design decision into a negotiation. Priorities were revisited more than once as the date approached, and scope moved in both directions. My job in those conversations was to keep the discussion on outcomes rather than on feature lists: what does a person need to submit a request quickly and without second-guessing, and what is everything else.

Some of those negotiations went our way. This is one that did not, and one that did.

The feature we lost

We proposed image upload. A driver could photograph the equipment ID instead of transcribing it, and photograph the damage instead of finding words for it. Both problems had surfaced early: IDs that require walking around a chassis to read, and failures that are far easier to point at than to describe from a list of categories.

The case was straightforward. Photos would have cut input effort at exactly the two steps where it was highest, improved the accuracy of what reached dispatch, and given technicians a look at the problem before leaving. It answered the same question the prefilling answered, from the other direction.

It was cut as too ambitious for the MVP scope. Image capture on mobile carries storage, handling, and performance decisions that reach well past the interface, and the launch date could not absorb them.

I still think it was the right call for the MVP and the wrong feature to be without. What we did instead was make its absence survivable: structured issue categories precise enough for dispatch to act on, optional descriptions for what the categories miss, and location fields flexible enough to compensate when the equipment is hard to identify. The flow works without photos. It would work better with them, and it is the first thing I would argue for in the next release.

The complexity we avoided

Sign-up went the other way. The team started by exploring custom sign-up and login flows, which meant designing account creation, credential recovery, and identity management from scratch.

As the conversation developed, we moved to Microsoft Entra ID for authentication and identity. The exploration work was set aside, and with it a category of screens, edge cases, and security decisions that would have consumed sprint capacity without differentiating the product. A stranded driver does not care who handles authentication. They care that the request goes through.

That decision protected the Service Request. Every hour not spent on password recovery was an hour available for the flow that determines whether the product is worth using at all.

Both decisions came from the same place: MVP scope is a question of what deserves the team’s attention, and the answer changes depending on how close the launch is. Keeping that visible, rather than treating scope as fixed, is most of what UX leadership meant on this project.

From MyRLR to a shared system

How this product became the reference for DCLI’s design system

MyRLR was built first. That turned out to matter beyond this project.

At the time, DCLI’s enterprise products were each evolving on their own terms: different teams, different timelines, different answers to the same interface problems. As friction between them became expensive, the company started building a shared design system. The audit that opened that work looked for the most developed set of patterns already in production, and found them in MyRLR.

Its tables, forms, navigation structure, and feedback states became the base the system extended from. Not because they were perfect, but because they had been designed as a coherent set, tested with real users, and shipped under conditions that had already stress-tested them. Starting from something proven was faster than starting from a blank page, and it gave four product teams a reference they could argue with.

The benefit went both ways. MyRLR contributed the foundation, and once the system existed, MyRLR inherited a shared vocabulary with engineering, components maintained by more than one team, and accessibility decisions made at the token level rather than screen by screen.

That work is a case of its own: Many Hands, One System.

Outcomes

What shipped, and what the market says about the service it runs on

MyRLR launched with the business. RapidLink Repairs opened to the broader supply chain market in March 2025, and the product was there on day one: service requests, status tracking, company and user management, invoicing, and service history.

What it replaced. Before MyRLR, a customer without phone access to dispatch had one written option: an email with thirteen fields to fill in by hand. Company name, SCAC, driver name and phone, equipment number, associated equipment number, load status and weight, hazmat, physical address and cross street, problem type, tire specifications, failure description, and whether an accident was involved. That template is still published on the RapidLink Repairs site, which makes it the clearest measure of what the product changed: the same request, with most of those answers already known by the system and the rest reduced to what only the person on site can tell you.

What it did not replace. Requests still arrive by phone, by email, and through the REACH app. MyRLR was never meant to close those doors, and a road service business would be reckless to try. It was meant to be the fastest path for anyone able to take it, and the only one that leaves structured data behind without someone transcribing it.

The operation it supports. RapidLink Repairs grew out of a road service unit with a serious track record: over 300,000 chassis serviced and more than 130,000 service events a year, with most repairs resolved in under three hours. Those numbers belong to the operation, not to the product. What matters for MyRLR is that this was the standard it had to meet. A digital channel that slowed any of it down would have been worse than no channel at all.

The signal that maps to the design. Across published customer testimonials, one theme repeats more than any other: being kept informed while the repair happens. Customers name the updates as often as they name the speed. That is the capability status tracking was built to deliver, and the principle behind it was one of the four we set at the start.

What we set out to measure. Post-launch evaluation focused on adoption against the other intake channels, the volume of clarification calls per request, and usage across requests, billing, and history. Those numbers stay inside the company. The public record shows the business it was built for completing its first year in the market.

Takeaway

Shipping to learn

MyRLR shipped because we decided early what the product had to protect, and let almost everything else be negotiable.

The constraints were fixed from the start: a launch date set by the business, a team across four countries, a service that already worked and could not be slowed down. Within those, the work was choosing. Four steps instead of six. Confirmation instead of typing. Authentication bought instead of built. Photo upload argued for and lost. Each of those was a decision about where the team’s remaining hours would do the most good.

What I would defend most is the prefilling. It came from watching people use the flow, it changed the product more than any other single decision, and it holds up as a principle beyond this project: the fastest field to complete is the one the system already answered.

MyRLR is a foundation more than a finished product. It gave RapidLink Repairs a digital channel from day one, it gave DCLI’s design system its first proven set of patterns, and it left the business able to measure something it previously could only estimate. Dependable when it matters, which, in road service, is exactly the point.