REDGO is the leading roadside assistance and towing operator across the Nordics. I’m designing the new driver-facing app — the work tool tow truck drivers use on every job — to replace a legacy system that struggled with real-time data capture across three national markets.
The problem
Driver work data was inconsistent and arriving late. A lot of drivers were not registering jobs in real time, which pushed manual reconciliation work onto back-office teams and degraded the data the rest of the business relied on. The root causes were practical: the existing tooling was awkward to use under field conditions — bad weather, time pressure, gloves on, the cab of a truck.
Layered on top of that, the three national markets — Sweden, Norway, and Finland — had drifted into different processes and different tools. Each country had its own habits and exceptions. And REDGO is a large, distributed organisation, so decisions that touched multiple stakeholders tended to take a long time to land. Anything we built had to keep moving while those slower decisions were still in flight.
My role
I’m the UX designer on the REDGO Driver App, working since January 2025. The remit is the field-side experience end to end: needs mapping, on-site research with drivers, interaction design across the full job flow, and ongoing iteration as the rollout expands.
The constraint that shaped the work most: drivers cannot afford to fight the tool. The interface has to be scannable at a glance and physically usable in conditions that are nothing like a desk — outdoors, in the rain, on a phone screen, while a customer is waiting. Errors here are not abstract — a missed status update or a mistapped form field has real downstream cost.
The process
Three months after development started, we had a first pilot app live with selected drivers. That timeline was deliberate. The team agreed early on to ship in MVP-sized chunks — features small enough that most stakeholders could agree on the scope without long debate — so engineering could keep a high tempo instead of stalling on every edge case.
The piloting-strategy was the unlock. Pilot drivers used the new app for ordinary, non-complex real cases, and fell back to the old app whenever the new one didn’t yet cover their situation. That fallback was not a compromise — it was the strategy. It let us learn from real field use immediately, while the PM and I went deep on the harder, more political feature spaces in parallel without blocking developers.
As the slower decision processes finished, we went back and fleshed out the corresponding flows. Each pass was informed by what we’d already seen drivers do — and not do — in the live pilot. The shape of the app today is the cumulative result of that loop: ship small, learn from the field, fold the learning back in, repeat.
Outcome
The driver app is now in production across Sweden, Norway, and Finland with over 1000 registered users. The shift to a single Nordic tool, with consistent flows for the parts of the job that are genuinely the same across markets, has cut down a lot of the manual reconciliation work that used to fall on operations.
The piece of feedback I’m most proud of came from drivers themselves: the new app is markedly easier to read at a glance and easier to operate in imperfect physical conditions. That is the part that’s hardest to design for from a desk, and the part that matters most when the tool is being used on the side of a road in February.
Working with developers
Working on REDGO required being comfortable with imperfect information. I had to deliver good-enough sketches across a wide range of feature spaces, often before the business-side decisions behind them were fully resolved. The job was to give engineering something concrete to move on, while leaving the design open enough to absorb the answers when they arrived.
That meant building just enough domain knowledge — about towing work, about the commercial constraints around it — to anticipate which changes were likely. Components and interaction patterns got designed with that headroom built in, so the natural extensions felt like extensions instead of retrofits.
My engineering and startup background helped here. It gave me credibility in conversations with developers and with business-side stakeholders, and let me move quickly between goals, constraints, and concrete designs. The work itself spanned Figma frames, Miro boards, and code — wherever the decision needed to land that day. I think of the role on REDGO less as “the designer” and more as a bridge-builder: someone who can pick up goals and constraints from either side and turn them into something the team can act on.