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 Honduras.
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.
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
Overview
The operation was ready. The product that would let customers reach it was not
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.
MyRLR was that product, and the mandate was a functional MVP: fast enough to launch with the service, solid enough to learn from. 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. 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, across India, Colombia, the U.S., and Honduras. 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
Thirteen fields between a stopped truck and a technician
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, equipment identified by appearance, the 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: clarification calls, delayed commitments, technicians arriving without the right part.
Nothing structured after the repair
A completed service with no account, no invoice, and no history. 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 relied on it during a breakdown.
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, and 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, a loop short enough to fit inside a sprint. Later, 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. 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 the supporting features in the MVP instead of a later release.
Experience principles
The criteria that settled every decision in the core flow
1
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 to solve, 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.
2
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.
3
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.
4
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 the one waiting for help to start moving. Most of the design work on MyRLR was spent on this single flow.
Service Request location within the MyRLR feature map.
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.
Company Admins / Fleet Managers
Office-based users who manage companies, users, and service requests, often as intermediaries between the business and the drivers on the road.
Basic Users / Truck Drivers
End users who request road service from the field, often in an emergency, and need it to go through quickly and without friction.
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.
The first structure
The initial flow was organized around what each step needed to establish, six steps, each with a single job:
Two questions stayed open at this stage: how much of the location could come from the device rather than from the user, and whether equipment would be identified by typing an ID or by selecting from what the account already knows.
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.
1
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.
2
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.
3
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.
4
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.
5
Status tracking
After submission the request stays live. Progress is visible, and there is a direct chat line to the RapidLink Repairs contact managing the asset. Phone and email remain open. What changes is that the conversation now starts with both sides looking at the same request.
On a phone, on the shoulder of a highway
MyRLR did not start here. Like most enterprise B2B products, it was designed desktop-first, and the early screens assumed the fleet manager’s office. The deeper we got into the situation the Service Request is called into, the more that order reversed: the desktop version matters for fleet managers, and 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 structural rather than convenient: typing on a phone in those conditions is the 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 points to the next action.
- No blame. When a submission fails, the system failed. The copy never suggests otherwise.
Ambiguity was treated the same way as failure. A request without clear confirmation is, from the user’s side, a request that may not have happened, and that uncertainty sends them to the phone. Explicit confirmation was cheaper than the alternative for everyone involved.
What we traded away
The flow is fast because it is narrow: one way through, few options, and little room to work around the path we designed. A user with an unusual situation has less room to describe it.
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, a lower cost per 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.
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.
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 for everything outside the request flow, and the team could extend these areas without relitigating structure each time.
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. 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. That kept a whole category of complexity, and its compliance burden, outside an MVP that had a launch date to meet. Our side kept the experience around the handoff: 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.
Tradeoffs
Where UX held the line, and where it gave ground
A fixed launch date turns every design decision into a negotiation, and scope moved in both directions as the date approached. 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. This is one negotiation that did not go our way, 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 in research.
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, with issue categories precise enough for dispatch to act on and location fields flexible enough to compensate. 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 gave four product teams a reference they could argue with.
The benefit went both ways: 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: the thirteen-field email template described in Problem, filled in by hand. 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. 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; they set the standard MyRLR 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, clarification calls per request, and usage across requests, billing, and history. Those numbers stay inside the company; the public record shows the business 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.