GoRight
Merlin Platform
ROLE
Lead Product Designer
TOOLS
Figma, Whimsical, Notion, Airtable
GoRight's on-road technicians were calling their supervisors just to confirm where to go next — the mobile app had no real-time updates, and its patterns didn't match the desktop tool managers used to track them. I rebuilt Merlin as one consistent system, live on both ends.

Exhibit A — staging.protaskit.com, before GoRight had a brand or a consistent pattern. Desktop and mobile spoke different visual languages.
The Problem
Three gaps that kept the field on the phone
Two products, two languages
Desktop and mobile ran inconsistent web patterns. The mismatch showed up as a daily surge in support calls.
Blind without a phone call
The mobile app had no real-time updates, so technicians called their supervisors just to confirm a location or next step.
A view, scattered across apps
Getting a simple overview of on-road status meant juggling multiple tools and manually stitching reports together.
GoRight’s business is dispatching people to broken-down vehicles, fast. Every one of those gaps meant more time on the phone and less time on the road — for the exact team the platform exists to support.
So I rebuilt Merlin around a single, live signal — everyone sees the same status, at the same time.
So I rebuilt Merlin around a single, live signal — everyone sees the same status, at the same time.
The Decisions
Three calls that shaped how it actually got used
The brief was parity, progression, accessibility, immediate value. Getting there took a few specific calls — including one where the right move was reversing course.
Decision
Caught a KPI-heavy homepage before it shipped
An early home screen led with performance metrics — clean, but it buried the one thing technicians actually opened the app for. Workshop notes flagged it directly: a KPI-first homepage risked confusing users trying to find their tasks. I rebalanced the layout so tasks led and KPIs supported, not the other way around.

From product ideation — the KPI-first homepage under review
Decision
Walked back an over-engineered navigation
A more elaborate navigation structure made it into a workshop round — and made things worse. The note is blunt: navigation is getting crowded, group related sections, go back to the previous version. I did. Not every iteration is progress, and this one wasn't.

From product ideation — the reversal, documented in the moment
Decision
Branched the journey for how technicians actually respond
Dispatch software tends to assume instant acceptance. Ours didn't: the on-road breakdown journey explicitly branches for a technician going now versus going later, with a notification either way — because that's the real choice a technician makes, not an edge case to design around.

User journey — assigning a supplier and technician through arrival
Constraint
Made accessibility a testable criterion, not a checklist
Contrast levels got monitored and tested, not eyeballed. Language got a legibility pass. Sounds that could disrupt a technician mid-task got cut. None of this shows up in a screenshot — it shows up in who can actually use the app in the field.

Audit findings — tracked by section, question, and type
How I Got There
Audit, workshops, a journey map — then screens
I audited the existing platform, then ran product ideation workshops with technicians, stakeholders, and on-road managers. Those sessions mapped the navigation, the capability set, and the breakdown journey before a single screen was wireframed for desktop or mobile.





The Platform
What managers and technicians see now
One dashboard, branded and live — task counts, submitted vs. received, reports, and activity, all in the same system technicians report into.








Results
What changed after beta
4 of 5
Beta transportation companies that agreed to continue as testers
New revenue path
Geo-localization and real-time tracking opened doors to new features and stronger monetization
One system, both platforms
A single component library replaced divergent mobile and desktop patterns
Technicians stopped calling it in.
Status lives in one place now — a technician’s next task, a manager’s overview, and a report at the end of the week all pull from the same live signal. Beta testers stuck around instead of walking away, and real-time tracking opened doors the original brief never asked for. That’s what the rebrand was actually building toward — not new colors, a system people stop having to route around.
ROLE — Lead Product Designer, from requirements gathering through this iteration of the Merlin platform.
Ideation workshops and journey mapping conducted with technicians, stakeholders, and on-road managers.