Adding Augmented Reality to Dublin Bus app
More than 500,000 downloads of the Dublin Bus app.
App Store rating 1.9; Google Play store rating 3.0.
Is it possible that Dublin Bus is failing not only giving their customers accurate information but also failing to give them access to it?
? Public transport in Dublin
Public transport in Dublin consists of a bus network, a heavy rail line (DART) and two light rail lines (the Luas). The leading bus operator, Dublin Bus, manages a fleet of 1,074 buses, which operate across 136 routes and approximately 5,000 stops.
In 2014, Dublin Bus released a mobile app for Android and iOS. With more than 500,000 downloads, this app rates 1.9 (out of 5) on the Apple Store and 3.0 on the Google Play Store. Based on 4,682 customer reviews (4,419 on the Google Play Store and 263 on the Apple Store), it is possible to see how Dublin Bus is failing not only to give their customers accurate information but is also failing to give them access to it.
In 2010, Dublin Bus started rolling out a real-time passenger information (RTPI) system, which displays the amount of time before the bus arrives at the next stop. Because of the high cost of implementation and maintenance, the system is not implemented at all bus stops. Some stops still only display the stop number as a referral code, meaning users have to key the code into their mobile app to get real-time information there.
THE APPROACH
? Design Process
The design process is divided into four phases – discover, define, develop and deliver – as described in the Double Diamond model. The notoriously beneficial feature of this model is the emphasis on divergent and convergent thinking. During the discover and develop stages, many ideas are created and are easily narrowed down in define and deliver stage.
The focus in the Discover phase is on learning more about the variables that might influence the main challenge and the ultimate solution. During this stage, the goal is to spot and investigate the actual problem.
In the second phase, Define, the focus is on reviewing and narrowing down the insights from the previous stage to define the main challenge to be resolved.
This is followed by the Develop stage, where the actual design process commences, creating the solution to the problem defined in the previous two phases.
The final stage, Deliver, includes testing and releasing the product to the public. Even though this might seem like the end of the work for a designer, it can often mean that the work has only just started.
THE DISCOVER PHASE
? User Problems and Product Opportunities
The objective of the Discovery stage is to recognise and contextualise the actual problem or opportunity. Activities considered in this stage include:
- User interviews
- Surveys
- User feedback and reviews
? User Interviews
For the purpose of this research, I interviewed only existing users (seven in total) because the focus was on their pain points and daily habits related to Dublin Bus. I conducted four interviews in person, and three were via an online phone call.
Before starting, all participants were asked to sign a consent form agreeing to be the part of the study. After gathering the feedback from all interviews, I bundled similar data together and organised into themes using affinity diagrams.
? Findings
After I grouped similar feedback together and created themes, some key issues were popped out. These included the difficulty checking the bus arrival time when the bus stop number is unknown and ‘hacking’ the flow by replacing the Dublin Bus app with Google Maps, often just to find out which buses go to which destination.
The majority of participants also stated that they check the bus arrival time before they leave their house/apartment, but when they do not know the bus stop number, the time to get the information increases significantly.
? Questionnaires
For the purpose of this research, the questionnaire was created using Google Forms and contained two sections. In the first section, participants were asked about their previous experiences with Dublin Bus. In the second section, they were asked about their attitude towards AR.
? Findings
The questionnaire was completed by 73 individuals.
More than half of respondents used Dublin Bus at least once a week, if not more. A total of 87% of the respondents checked the bus arrival time before taking the bus. The majority (73%) of respondents used the Dublin Bus app to check the bus arrival time, while 20% used Google Maps or the TFI RTI app. When asked, ‘Do you always know the bus stop number?’, 80% of participants answered ‘No’, which means the time to find the information on bus arrival takes even longer than normal.
Apart from the information on the bus arrival times, 47.3% of the respondents highlighted that they would like to see the bus route and the bus stops displayed on a map, while 43.6% wanted to see the exact cost of the journey. A total of 63.6% of participants wanted to know if the bus was empty or full, because when the bus is full, the bus drivers do not stop at the bus stop, so they have to wait for another bus. When asked if they had any issues with finding the bus stop, 42.3% of respondents had a positive answer and 37.5% did not know which side of the road the bus stop was on.
In relation to AR, only 30.2% of respondents said they had used an AR app; 52.4% said they had never used an AR app and 17.5% stated that they did not know what AR is. When asked how useful they think the AR app they had used was, most of participants answered between 5 and 7 (useful) on the 1–7 Likert scale. When asked whether AR could be of benefit when used in public transport, 54.5% participants answered positively, while 27.3% thought the opposite.
To summarise, the majority of respondents used Dublin Bus more than once a week, and they all had similar issues when trying to find information on bus arrival times. In the absence of knowing where the bus stop is, respondents had their own way of ‘hacking’ the system and getting the information in another way. From the data gathered from both online questionnaires and interviews, I mapped three possible scenarios of use, as shown below.
- When the bus stop number is known, the user opens the Dublin Bus app, inputs the bus stop number, and gets the arrival time. The task is complete.
- When the bus stop number is unknown, but the bus number is known (80% of users), the user opens the Dublin Bus app, searches the route using the bus number, checks the map (which is often not working properly), finds the bus stop number, and then gets the arrival time. The task is complete.
- When the bus stop number and the bus number are unknown, and only the destination is known, the user opens Google Maps, inputs the destination, checks the bus lines that can take them to that destination, opens the Dublin Bus app, searches the given bus route, opens the map in the app to find the exact bus stop, and then gets the arrival time. The task is complete.
⚔️ Competitor Analysis
In the competitor analysis, the Dublin Bus app was analysed along with four direct competitors (Transport for Ireland Real Time Information [TFI RTI], Moovit, Next Bus Dublin and Bus Times London) and two indirect competitors (Google Maps and World Around Me [WAM]).
The features are highlighted in the product screenshots and were defined as follows:
- AR functionality
- Display of trip duration
- Viewable route map
- Option to save favourite stops
- Alert to take the bus
- Search by bus stop
- Accurate real-time information on bus arrival time
- Search by location
- Option to view nearby bus stops
From this list of features, only three were found in the Dublin Bus app: the option to save a favourite stop, bus stop search and the display of nearby stops, which was buggy. The key feature that Dublin Bus customers want is accurate real-time information on bus arrival times, but two other direct competitors, TFI RTI and Next Bus Dublin, already display this information in better way.
? SWOT Analysis
In the following section, I’ve identified the strengths and weaknesses (internal) of the Dublin Bus app, followed by identification of the opportunities and threats.
There is a possible danger that competitors with more advanced apps will replace the Dublin Bus app altogether. For example, Google Maps is often used instead, even though the arrival time it displays is retrieved from the Dublin Bus schedules, which are often not accurate.
Problem statement
How can we speed up the current process of finding a bus stop and checking the bus arrival time?
THE DEFINE PHASE
? Stepping into users’ shoes
In this stage, the focus is on reviewing and narrowing down the insights from the previous stage to define the main challenge to be resolved. This was carried out using the visual representation of a customer’s journey, which helped to identify the problems with the current service.
? Creating a user persona
The primary persona, Conor, has a range of goals that align to the main focus of the AR prototype design developed for this research study.
The secondary persona has a few specific needs that are not the primary persona’s priority.
Mapping both primary and secondary personas at this stage was extremely important as it helped to place the focus on users and understand their concerns. This resulted in the creation of an app with a realistic user journey, aimed at satisfying user needs and expectations.
? Empathy Map
Empathy map was used to enhance empathy towards the user, categorise and make sense of qualitative research data and discover the possible gaps in the research itself. It also served us as a quick way to show users’ behaviours, thoughts, and attitudes to other members of the team and stakeholders.
? Customer Journey Map
Two customer journeys were created for this project. One of them describes the situation ‘as-is’, while the other shows the desired ‘to-be’ situation.
As-is journey allows the current customer experience to be understood in a better way and highlights the areas where customers’ expectations are not met. In this case, Conor has to get the information on bus arrival time using a third-party app (Google Maps) and then switch back to the Dublin Bus app, which takes more time than he expected and makes his experience cumbersome.
In the to-be journey, the process of finding a bus stop is improved using AR, which makes Conor’s experience of using the app seamless. The requirement for this project is to improve the current experience of users when they want to find the bus arrival time but only know the destination.
THE DEVELOP PHASE
? Let’s design
In this stage of the Double Diamond framework, the actual design process commences, creating the solution to the problem defined in the previous two phases. It was important to understand the context in which users would be interacting with the new prototype Dublin Bus app, which is why user scenarios were developed before prototyping.
⏳ Prototyping in Figma
The first screen contains a map, with all the nearest bus stops marked using icons. If the user wants to know which buses could take them to a certain area, they can use the input field at the top of the screen to key in their destination. This results in a filtered search, showing only bus stops with buses driving to the desired destination.
⏳ Prototyping in Torch
The second part of the new prototype required software that supports AR.
I chose Torch, because of the ability to change between ‘scenes’ using different interactions. All digital objects used in the app were primarily designed in Figma and then uploaded to the Torch library.
As can be seen in diagram below, the entire user flow created using Torch consists of seven scenes. When landing on the results scene, the user sees three main dialogues showing the bus stops and buses that can take them to their destination (in this case, Central Park). By tapping on any of these dialogues, the user sees a new dialogue that gives them more detail on the bus stop and the bus. After tapping the start button on any dialogue, the first instructions on how to get to that bus stop are shown. By tapping on it, the user is brought back on the main scene, where they can explore other bus stops.
Torch uses a markerless augmentation approach, so each digital object has its own coordinates. The user has to set the anchor point first in order to view all elements.
Google’s AR Design team (2020) has provided foundation research in a set of basic guidelines for designing AR experiences.
The first recommendation is to define the size of the physical space that users need for the AR app, as the experience should fit into their physical surroundings. In this case, the ‘world’ size was chosen as the dialogues would be displayed outdoors, mostly by users scanning the world around them while looking for a bus stop.
Because users would be looking through their phone camera and probably ignoring the outside world, they could bump into other people or objects and miss noticing other dangers around them. To prevent this, all digital objects were created with 70% transparency, which helps users to see through them and avoid hazards.
None of the tasks involve the user moving backwards, which is considered one of the most dangerous actions when using AR apps. In the second iteration, additional safety warnings for users to look around and check their surroundings were added to prevent any further risk.
As suggested by the Google AR Design Guidelines (2020), all AR objects should engage with their environment and face the same direction, towards the user. Using the Torch app, this was achieved by using the ‘face camera’ functionality, which automatically turns objects towards the user.
Even if the user turns away, the object becomes visible from all sides, enabling the user to engage with the object in the best possible way. The reset process also makes it quick and easy to create a loop after three scenes have been viewed. In this way, users can easily go back into the experience. No pop-ups were used for any interaction, as users need to focus on the scene itself instead of being interrupted.
Each element has its own x, y and z position values, which are relative to an anchor coordinate that was previously set up. This was a sensitive part of prototyping, as elements in the sequence had to be in the same position after a user had interacted with them.
THE DELIVER PHASE
? Final Product
The final stage, Deliver, includes testing and releasing the product to the public. Even though this might seem like the end of the work for a designer, it can often mean that the work has only just started. Once the final product is live, users provide feedback that is typically acted on and reflected in the next iterations of the design.
?️♀️ Testing with users
For this research, forty users, both male and female, were recruited in order to gather accurate results. Once each participant had read and signed the consent, they were asked to carry out a task that involved finding a bus stop and checking the bus arrival time using the app of their choice and the prototype Dublin Bus AR app.
? Findings
The findings from the pilot usability testing were as follows.
- 60% of users were not aware that they could not get the RTPI on Google Maps.
- All users first checked Google Maps to find out which buses could take them to their destination and then checked the Dublin Bus app to get the RTPI.
- Users did not understand whether the icons were buses or bus stops.
- Users needed additional confirmation that the buses displayed were the buses that could take them to Central Park.
- Users wanted to see the arrival time at the destination displayed in the final AR dialogue.
? Iterating towards the final product
After gathering feedback from the first version, the prototype was modified and prepared for the evaluation phase. The changes were as follows.
- Replacing the Google Maps screenshot with a Mapsicle map showing Dublin city centre
- Introducing tabs for stops and buses to counteract the confusion experienced previously when users did not understand whether the icons were buses or bus stops
- The icons were replaced with a skeuomorphic bus stop sign.
- Additional information on the bus’s destination was added to the flow as previous user feedback showed they needed reinforcement on this topic.
- The brand title was removed when the keyboard is active, which resulted in more real estate for displaying the map.
- The second version also contained changes to display the arrival time with the destination and add additional bus and bus stop icons in the AR view.
? Results and analysis
The final evaluation phase consists of a comparison of the time needed to find the real-time bus arrival information using any app of choice (in most cases participants used Google Maps in combination with the Dublin Bus app) and using the new AR Dublin Bus prototype app. The method used was within-group testing, a quantitative comparison of time on task in each scenario. The participants were asked to rate their experience by filling in the HARUS questionnaire.
⏱ Time on Task
Time on task is the one of the best ways to measure efficiency and productivity. It refers to the time a user spends completing a certain task. Even though there are different ways to analyse the task duration, this study measured task completion time, which is the time the user took to complete the task.
The findings show that the time it took to finish the task was significantly higher when the app of choice was used, compared to the time taken when the prototype Dublin Bus AR app was used. Users needed from 80 to 200 seconds to finish the task using their app of choice. However, to finish the same task using the Dublin Bus AR app, they needed from 40 to 90 seconds, with most taking 60 to 80 seconds to complete the task.
Therefore, when finding real-time bus arrival information from Dublin city centre to Central Park, the time to complete the task was significantly higher when participants used an app of their choice compared to the time it took to finish the same task using the prototype Dublin Bus AR app.
? Usability
All HAR applications have to be carefully designed and also improved based on feedback from users. For this project, the HARUS was used and the feedback was captured using Google Forms.
The mean HARUS score for the prototype Dublin Bus AR app is 91.25. Bearing in mind that the HARUS is evaluated in the same way as the SUS, a score of 70 or above is required for an AR app to be considered usable, which means that the Dublin Bus AR app is usable.
From the results gathered, it appears that the time on task does not affect the HARUS score, meaning that the users who managed to finish the task in less time did not necessarily give a higher HARUS score.
? Qualitative results
Qualitative data was generated from the questionnaire given at the end of the session, where users were asked, ‘How do you feel about this technology and would you use it?’
The feedback received was mostly positive. Users noted that, if the app were available in real life, it would definitely save them time when looking for information on bus stops and bus arrival times. Some users were pleasantly surprised with seeing the information displayed using AR as they were not expecting it.
They thought displaying the information in this way would shorten the time it usually took them to get it. They liked the fact that they could view the bus stops around them and compare the distance as well as the bus arrival time all in one go, which made it easier when deciding which bus to get.
? Key Contributions
This research project has proven, through both qualitative and quantitative analysis, that using the correct set of data and principles and involving users in the design process can considerably improve the user experience.
By introducing AR into the Dublin Bus app, the time users need to find information on bus arrival times and bus stop location was significantly reduced. Other key items that were found in competitor apps were also added into the newly designed AR prototype, such as trip duration, arrival time and the ability to search by location on a map.
This resulted in reducing the time users would normally need to get the same information using the Dublin Bus app. It also addressed some of the key issues for Dublin Bus app users, one of them being, ‘if you don’t already know how to get where you want to go this won’t help’.
Following the AR prototyping process, the author suggests the following set of tips, which can be adopted by any company looking to introduce this emerging technology in their app.
- Have a sense of the context and the world around users of the app.
- Make your user interface accessible during sunny, rainy and cloudy days, as well as at night.
- Make things easy to find. In the case of working on a public transport app, have in mind that users might be rushing somewhere and they need to find the information as quickly as possible.
- Categorise the information in your app. Some information is more important than others. Organise it into a hierarchy that shows you understand it.
- Listen to your users. Something that may seem very obvious to designers will not be obvious for everyone.
- Iterate your design after testing.
The quantitative data gathered in this study shows that AR functionality definitely reduces the time users would normally need for finding information on bus arrival times. It also proves that users are not afraid of this emerging technology; they are ready for it.
⚖️ Conclusion
The aim of this study was to compare how users search for real-time bus arrival information using apps of their choice and the prototype Dublin Bus app with AR functionality. The user experience design goal of the research was to find a way to improve the overall experience for all users.
The pilot and evaluation phase had 40 participants in total, and both qualitative and quantitative methods were used in the design process. The final evaluation used a between-group design, quantitative comparison of time on task, the HARUS measurement tool, and captured qualitative data about whether the users were ready for this emerging technology or not.
The research showed that the time to execute the task was reduced by 51.56% when AR functionality was incorporated into a new prototype Dublin Bus app. The results collected from the HARUS survey, on a scale from 0 to 100, resulted in an average score of 91.25. This signifies an ‘A’ grade, which means that people loved the app and would recommend it to their friends.