Redesigned the way from A to B

Moovit is a popular public transit navigation app, with hundreds of millions of users across the world, Israel included. The itinerary is one of Moovit's core screens. Its goal is to describe the public transit riders the route they are about to take or are currently taking. As we always felt it wasn't "optimal" but couldn't get proofs from analytics and interviews, we set out on a mission to back our intuition with data, and by our learnings to envision a better design.

Foreword

The itinerary screen is a core screen in a trip planning flow. In this screen, users see the entire planned trip from A to B - all the stops, lines, and transfers they must take along their route. Therefore it was critical for us to understand how it performs.

We always "felt" that the screen is not optimal, but looking at data and interviewing users didn't help us finding objective answers to our questions: Is the screen clear? Does the information structure make sense? Do users notice the details they must know while using it?

Also, at that time we knew that we are planning to add more abilities and new transit types to the Itinerary, and the current structure was not scalable enough.

We set out for a challenge - to back our intuition with data, and with our findings envision a better and more scalable design.

Finding the users' pain points

We started by asking our colleagues at work to plan a trip with the app to a specific address, and describe the route to us. This method enabled us to notice what they've missed, where they "stutter" and get confused. We then expanded the tests to guerrilla testing with Moovit users at the bus stops next to the office (Moovit users are everywhere in Israel 😄).

Current version: reading order did not reflect the physical experience, which caused confusion and missing key details of the route.

This method helped us to highlight problematic details and areas in the UI. We then analyzed the results, compared them with a prior competitor analysis, and defined the key issues:

The order of the route steps is not fully reflecting the physical experience - causing users to become confused about the steps they need to take next.
Some details constantly got missed by the testers or were hard to find.

Redesign process

The first step was to understand the current structure of the screen, with all of its edge cases and types of components it supports. We also included in this step all the new components we wanted it to support and were sure to define it as generic as possible, so it will be scaleable for any future need that will come.

We came up with a generic structure, with legs built from repeatable elements representing different data types of the route - locations, actions, and information.

We then arranged the elements to represent the physical and mental experience of the user on the ground.

We came up with a generic structure, with legs built from repeatable elements representing different data types of the route - locations, actions, and information.

New version: Main UI changes included reordering of elements, adding visual path on the left, clearing borders and dividers, and adding white space.

Validating the concept

We tested the concept remotely with users in London. Since London have a complex public transit network with buses, tube, and rail, we had a chance to check small details not common in Israel such as subway pathways.

We used "Maze" tool to present mockups showing the same route with the current version (control group) and the new version. The test was sent as a link via mail to a large group of UK users and was taken with no live moderation. Each group had a few dozens of replies.

We presented them identical questions about the route, asking them to locate as quickly as possible (to simulate the "rush" of the real world) details from the route, and tap on them.

We then compared bounce rate, reaction time, misclicks, etc. between the groups. "Maze" even calculated all of these to provide each test something they call a "usability score".

Example of task results. Report data and heatmap by Maze.

To see that the "easiness" of the route is not just from cold data, but something they can sense, we asked them to rate each test for "how easy it was".

The new version got a higher usability score and was perceived as "easier to read".

In the opinion scale question, the new design got a higher average score. Report data and emojis by Maze.

Conclusion

The process was a great teaching experience for us on how to deal with usability issues that we apparently can't "measure" with analytics and/or interviews, and find ways to create assumptions on them and validate them with a large number of testers to make our point.

Showing the results later to dev got us an easy "buy-in" from them, and this vision set the ground to re-work our existing Itinerary.