London offers many public transportation options. This pure volume of choice can lead to confusion and that’s partly the reason why journey planning applications have become so popular.
Among the current applications there’s one that shows results for all means of transportation (Using realtime TFL data), this is the application we chose to focus on in this weeks DbyE. The existing app offers an effective service but we feel that the journey visualization could be improved in order to give a more efficient view of the journey details. Currently the user enters a start and finish point to their journey, the app then displays results. By tapping a journey on the screen a description of the path is displayed. However, a map visualization is not provided, only the interchange points are highlighted on Google Maps.
We identified core users as those who do not have a complete knowledge of the city and TfL transportation. Further to this we split the core group into three categories: tourists, who are completely unaware of the city and it’s transportation; new residents, whose knowledge is limited to the familiar and Greater London residents, those who visit the city centre may sometimes need info on specific routes.
These three user categories have common needs. Firstly, even if may sounds obvious, they want to reach interest points with public transports. Secondly, they want to find the most comfortable option among many. Finally, maybe most importantly, they can get lost easily so they need a solution to avoid that and get them on the right track if it is to happen.
We set a basic IA:
- Journey options (bus, tube, walk…)
- Destinations
- Maps
- Timetables
If you want to try this week’s example, do your design now (no more than 10 minutes, remember) and then go on reading.
The different solutions showed some interesting points:
- Filters for disruption updates and cost effective travelling were deemed particularly useful, these two aspects could strongly affect the travel experience.
- The importance of displaying the full path on the map, so users may have a quick overview of the journey’s main details and a reference to physical location.
- The need to highlight the number of stops to show progression through a journey.
It’s interesting to notice that our solutions can be divided into two scenarios:
- Planning in advance
- On the go
Planning in advance puts an emphasis on option selection while using the app while on the go emphasises map visualization. Planning in advance obviously occurs when the user has time and is able to research different route options. In contrast, by using the app on the go solutions are focused on finding the quickest route; in this case, it could be more intuitive to first supply the user with the quickest route, then allow them to consider the response attributes. Giving them the chance to refine the requirements of the search.
Another solution is to represent two separate sections: map and options, so both are displayed at the same time.
In this session we used an existing application as a starting point, focusing only on a specific aspect of the user journey. This restricted the outcome to a degree. However, it would be an interesting exercise to redesign a whole new application, possibly changing the entire interaction model.