Where is my bus?
Skills: Native iOS & Android, Product design, User research & testing, Design systems, Accessibility
About
Travis is a native iOS and Android travel app for public transport in primarily Stockholm and Gothenburg. It’s built by Nobina, Scandinavia’s largest public transport operator.
Context
I joined as Senior Product & UX Designer to help Travis through an expansive phase. At that point the app was essentially a mirror of SL’s own travel app, built on the same open API, but snappier and more intuitive to use. At that moment it lacked various important functions like ticket purchases, live updates and several of the things that made SL genuinely useful.
Working closely with the Product owner, the ambition was to make Travis a national travel app covering local transport in every region, and eventually not just buses and trains but ticketing, e-scooters, taxis and rental cars. One app for getting from A to B, wherever in Sweden you were.
My mission was to identify the needs of the users and how we could implement a solution to that and in what order.
What we didn’t know
As it turned out, almost nothing. There were plenty of assumptions, and a vision from Nobina about being the biggest and the best, but everything was being built on anecdotes. Designers and developers designing for what they wanted, a mish-mash of ideas, and meetings that ran on “You’d want it to work like this…” and “I think it should work like that…”.
The first change I made was small and structural: we started writing requirements from the user’s side. “As a traveller I need X so that I can Y”. It didn’t answer any questions on its own, but it made us focus on the users needs and not ours.
Then we went to find answers. I planned both quantitative and qualitative research: we went out into the city and interviewed travellers on the streets, asking what they’d want from a travel app, what mattered to them, and how they actually travelled. Alongside that I facilitated moderated sessions with a recruited focus group, working through prototypes and flows, solving tasks and reacting to what they saw. I set those up properly, with eye-tracking and recording, to keep the findings as clean as I could.
One of the most useful insights was that travellers were taking screenshots of their trip planner to share with their friends and families solving a problem we hadn’t noticed before. That was something we could solve by building and implementing a sharing feature. We also found that people had strong opinions about something the team had never questioned, the app was dark-mode only, and almost everyone preferred the lighter design we tested it against.
Deciding what to build first
The research gave us a clarity and a list of actions we needed to address. Management wanted new features shipped, the developers had technical debt to deal with and the testing had turned up bugs and broken flows. On top of that I’d gone through the app and found that the design system they had been working of was too vague which had led to a lot of conflicting usage of components. There was no thought behind what colors and shapes meant, only what “felt good” for the designer.
Too keep us from building new features on top of unpaid debt and broken flows I worked to stay ahead of development: a design backlog, prioritised against the bugs and the new features, so there was always something ready to build. It let us move on debt, bugfixes and new features at the same time without much friction.
While developers worked on features or debt I started building a unified design system. It gave designers and developers something to build from and less uncertainty in doing so.
Choosing the right pattern
From the start the app was cluttered with information, a lot of scrolling in every view trying to show off everything. Changing payment method during a ticket purchase unfolded inline in the flow. Entering where you were going meant a fixed search box with travel modes stacked in it, eating the space where the map should have been.
I moved that into a Bottom Sheet on Android and a Sheet on iOS, same behaviour expressed the way each platform already does it. It’s an existing pattern built for exactly this, content that supports the main view without taking over and that the user can push out of the way when it’s in the way.
That met some scepticism internally, would users understand it? Would they know it was there? I argued for it and later backed it up with insights from testing. Users didn’t just understand the sheet, they expected it and dragged it away when it was in the way and interacted with it naturally.
Where is my bus?
The feature already existed when I joined. It was also one of the most requested things in the app, and it barely got used. Partly because it was broken, sometimes it showed one bus, sometimes none and sometimes several. But it was also buried in the trip planner, and the people who did find it couldn’t tell what they were looking at.
I rebuilt it around a clear distincion, the map up front in the main view, showing where the bus actually is, and the bottom sheet holds everything textual like minutes remaining, which stop and when. I added an arrow showing which direction the bus was travelling as well as making the bus icon more visible.
Accessibility was a requirement throughout this project, and a travel app is used by everyone, often in motion and on the run. Here it once again proved a question the research touched on, the dark theme made the bus hard to pick out against the map. The new default lighter theme made the feature work. I reworked the iconography and colours along the same lines.
The design system
I built Travis library from scratch in Figma, on the same principles I’ve used since; primitives first and semantics second, so a colour tells you what it does rather than what it is. Apple HIG and Material Design sat underneath as the baseline, so the app stayed native on both platforms without becoming two different products.
The point was to get everyone speaking the same language. Designers had something to support them when designing and developers could easily find out what colors and components should go where. Gone were the arguments whether a button was the right button or not.
I also worked on pushing variables and components from the library straight into the codebase, so there was one source of truth rather than two that drifted apart.
My process
Since this was during covid, almost all our work was remote, and the team rarely sat in the same room. I ran workshops to shift the team’s starting point from what we wanted to what travellers needed, and presented design solutions based on the research so we could argue about approach rather than personal taste. For a team that never met in person, we listened to each other well and pulled in the same direction.