Märsta Förenade Åkerier is a transport company whose traffic controllers route between 100 and 300 orders a day. I’m designing the purpose-built TMS they will use to do that — replacing a setup that was never meant for this kind of operational density.
The problem
The domain turned out to be significantly more complex than it first appeared. No single person in the organisation had a complete picture of how everything worked — operations, management, and the controllers themselves all held different mental models of the same processes. Edge cases surfaced constantly. The challenge was not just to design the right flows, but to establish a shared language between the people who needed to validate the work and the developers who needed to build it, while keeping scope tight enough to hit the deadline.
My role
I’m the product designer on the engagement, working since June 2025. The work is desktop-first — controllers sit at multi-monitor stations — and spans field research with the controllers, needs mapping, specification, and interaction design across the full controller workflow.
The process
The tool I reached for early was Lovable. I used it to build clickable prototypes that made the system concrete enough for both operations staff and management to actually react to. Written specifications alone weren’t landing — the domain was too fragmented across departments for abstractions to do the work. A prototype people could click through gave us the shared language we needed to move.
From those sessions I extracted formal specifications and converted them into user stories for the development team. The prototype served double duty: it validated the logic with the people who live in the domain, and it gave developers something that communicated intent without requiring them to parse a requirements document cold.
Outcome
The TMS is now in final testing across the organisation and shipping within weeks. Getting there required holding a constant tension: an operation with genuinely complex, exception-heavy logic on one side, and a deadline that demanded clear scope decisions on the other. The prototype-as-shared-language approach was what kept things moving while that tension was still live.
Working with developers
I’d demo overall flows through the prototype, the team would build from the user stories, and we’d converge on specific problems as they surfaced. Where we spotted UI or UX challenges that would recur across the product, we invested in finding a general solution rather than patching each instance. On a project this dense, that kind of reuse thinking was the difference between a coherent product and an accumulation of one-off fixes.