Case Study - The real design challenge wasn’t the interface: it was making complex algorithm output legible, trustworthy, and actionable for the humans working alongside it.
Greenfield
Algorithm UX
TIMELINE
1 year (2022 - 2023)
TEAM
2 designers + 1 PO + Engineers + 1 Operations Researcher
COMPANY
Network Planning domain at Flixbus
USERS
70+
Project Overview
I owned
UX strategy • Discovery & research • End-to-end product design • Operations researcher collaboration • Design process education
With the team
Operations researchers: algorithm design • Engineering: feasibility & build • PO: scope & roadmap • UI designer: custom components
Goal
Give network planners a way to optimise bus schedules: drivers, vehicles and timetables - in a single run, without needing to understand what’s happening under the hood. The algorithm does the heavy lifting. The planner makes the call.
Problem
Optimising a bus network takes weeks of manual work and depends entirely on who’s doing it. The business had the algorithm. What it didn’t have was a way for non-technical planners to use it, trust it, or act on what it produced.
TL;DR
Stat #1
Stat #2
Stat #3
The algorithm could reduce buses, shorten driver shifts and tighten turnaround times but a schedule too efficient for a bus partner to operate is worthless. We designed constraints into the output so the result was always something a human could actually hand over.
Network planners aren’t software users. They’re geography and logistics experts who think in routes, partners and operational risk. Every screen, label and result view had to speak their language not the algorithm’s.
We learned that planners return to the tool at the start of every planning season to explore new possibilities, not because they have to, but because it consistently surfaces options they wouldn’t have found on their own.
The Situation
A new algorithm, a brand-new team, and users who weren’t asking for either
Network planners had been building schedules by hand for years: adjusting driver shifts, vehicle blocks and departure times line by line, drawing on experience that took a career to build. It was slow and impossible to scale, but it was theirs. Handing decisions to an algorithm wasn’t something they were waiting for.
The team assembled to build it was just as new to this as the users. Engineers, an operations researcher and a PO who had never worked with a UX designer before. Before a single screen could be designed.
Teaching a team to slow down
Engineers and operations researchers who’d never worked with UX had to trust that defining the problem first would get them to a better solution faster, even when it felt like standing still.
Users protecting their expertise
Network planners feared the tool would make them redundant. Gaining adoption meant designing something that amplified their judgment, not something that tried to replace it.
Two tools that had to act like one
The optimisation tool couldn’t live inside the existing planning tool, but planners couldn’t be forced to jump between them. The seam between the two had to be invisible enough that the workflow still felt whole.
Design research
Before any wireframe, we ran use case workshops with operations researchers and planners together: mapping what the algorithm could do against what planners actually needed to decide. Those two things weren’t the same list. The gap between them became the design brief.
We ran two rounds of usability testing: first with UI prototypes alone, then with real algorithm output loaded into the designs. The difference in feedback quality was significant. Planners could only give reliable responses when they were looking at something they could actually imagine running.
Distrust by default
Planners didn’t trust KPI numbers they hadn’t calculated themselves. Every metric in the tool had to earn its place, they’d cross-check costs against existing Power BI reports until the tool proved itself.
Two ways of working
“Pre-deciders” built a rough schedule first, then optimised. “Explorers” started with the algorithm and worked backwards. The tool had to support both without forcing either into the other’s flow.
One number that mattered most
The single clearest signal of a good optimisation: fewer buses than their own version. If the bus count was lower, they’d consider adopting it. Everything else was secondary.
Real data changed everything
Loading actual algorithm output into prototypes took days of manual work to prepare for each test session. But dummy content produced unreliable feedback: planners couldn’t evaluate a schedule they couldn’t imagine running on a real route.
We made it a non-negotiable part of every test. The operations researcher would run the algorithm, we’d manually piece the results into the designs, and only then did we sit with users. Painful, but the quality of insight made it worth it every time.
The hard conversation
Planners would look at an optimised schedule, see fewer buses than their own version, and say they’d use it. Then analytics showed they weren’t. When we went back to find out why, the answer was simple: the schedule was too tight. The algorithm had found the mathematical minimum but the bus partner couldn’t actually operate it. We had to design intentional constraints into the output so results were good enough to be real, not just impressive on screen.
The job threat was real and nobody pretended otherwise. One planner with this tool could now cover what previously took a small team. We didn’t design around that reality, we designed into it honestly. The algorithm handles route combinations no human can hold in their head. The planner handles what the algorithm can’t know: which bus partner will push back, which schedule is too tight to negotiate, and whether the numbers on screen are actually worth presenting.
Getting the team to work this way took time. Early on, engineers and the operations researcher would bring near-finished solutions to the design process expecting a UI wrapper. Establishing that research had to come before design, and design before build, not alongside it, was a conversation we had more than once. By the end, the operations researcher was initiating discovery sessions. That shift was one of the most meaningful outcomes of the project.
Outcome
Impact
A new way of working: for planners and the team building the tool
01
A flow planners actually used
The cross-tool journey was redesigned so planners start in the planning tool, jump to optimisation, then return to finish - replacing the original reverse flow that 5 out of 6 users found disorienting.
02
Used when it matters
Usage settled at once or twice a year, exactly when major planning decisions are made. Not a daily tool, but an indispensable one at the start of every planning season.
03
More versions, better decisions
Version management became a critical feature: optimisation generated more schedule variants than planners had ever created before, making filtering and comparison central to the workflow.
The tool doesn’t replace the expertise planners have built over years. It gives that expertise somewhere to live - so it doesn’t walk out the door when they do.
UI showcase
Three key interaction moments: the optimisation input, the schedule comparison view, and version management.
What I'd take forward
01
Constraints are a design input, not an afterthought
The algorithm could produce a perfect schedule that no bus partner could actually run. Designing the constraint system, what the planner sets before the algorithm runs, was as important as designing the output. What you put in determines whether what comes out is usable.
02
Trust is built through legibility, not reassurance
Planners didn’t need us to tell them the tool was good. They needed to be able to see why a result was what it was and change it if they disagreed. Every screen that made the algorithm’s logic visible reduced friction more than any onboarding ever could.
03
Research with a brand-new team is its own design challenge
Working with engineers and an operations researcher who had never collaborated with a designer meant the process itself had to be designed. Establishing when to involve UX, how to run workshops, and why real data matters in testing, that work shaped the product as much as any wireframe did.
