Research Results

The results below will be a summarised version of what I’ve sent to RushOwl. They include some of the key points I’ve found out before doing the UI design.

Demographic of users interviewed:

1. Driver
2. Bus & MRT (2 users)
3. MRT only

Transportation & Perception

Users mentioned that a ​private bus service would be the most realistic and ideal solution to go to one-north​. In addition, they understood the limitations of private bus services, pointing out that the bus schedule might not fit their own schedules. However, the users pointed out that ​they were comfortable with arriving early by at most 30 minutes​.

In conclusion, users feel that their current mode of transport to one-north can be further improved. They feel that a private bus service that charters them to one-north may be an ideal and realistic solution which may elevate their satisfaction levels.

User Expectations of Dynamic Routing Bus Service

When told about the idea of a bus service that will bring them from their doorstep directly to their workplace, the users gave an average of 6 point out of 7, with 7 being the most likely they will use this service as their main mode of transportation to one-north. All of the users have different priorities when choosing their main mode of transport; price, convenience and bus schedule are some of their main priorities and concerns. They also considered other factors such as the location of the bus stop and the duration of their journey.

User Expectations of the Mobile Application

All of the users were asked to imagine how the mobile application would function in conjunction with the dynamic route booking feature. Below is a list of features they would expect.

1. Specify home and work locations
2. Specify arrival time at destination
3. Trial ride for first time booking
4. Bus route, stops and its schedule
5. Monitor bus location and ETA to user’s stop
6. Subscribe and cancel subscription
7. Detail of bus stop to wait at
8. Communication channel with driver
9. Price of fare

Most of these features are present in the RushOwl wireframes, except those that are bolded. ​

User Expectations of Crowdsourced Routes

When users were told that they would have to deposit a refundable $50 to indicate their interest in a non-existent route, most of the users were skeptical of this proposal. ​Most of the users gave a score of 1 out of 7, which means they will most likely not use this feature at all​. They cited price as the main issue. Although they know that the amount is refundable, they do not see the point of buying into ‘hope’. ​They attributed this problem to previous attempts by bike-sharing companies like OFO, which deceived people into depositing money into their account and touting that it’s refundable.​ One user also mentioned that he may need to use the app more often to gain trust before depositing any money. However, when told that this feature will be free to suggest routes, they will most definitely do it.

User Experience during Bus Journey

Users expect the bus to not be late for more than 10 minutes​. They would let the bad experience slide as long as they can board the bus and reach their destination. Generally, users felt that the ​bus should not wait for its passengers if they are late​. They are used to the public bus system - passengers wait for the buses to arrive instead of the other way around.

Expected Use of Ad-hoc Bus Service within One-North

All of the users only travel within the one-north area for lunch. Since their workplaces are only 5 minutes from the MRT, it is convenient for them to walk without needing any sort of transportation. Thus, there is no need for the users to use any sort of transportation to get to their lunch locations​.

Observations

While waiting for the bus, I faced a few problems.

1. Since it was my first time taking the bus route, I forgot what timing I had to be there and where the bus location was. ​The location of the bus stop and the ETA were not reflected in the bus ticket at all​. I had to search for the route, and check the schedule from there.
2. The exact location of the bus stop was not communicated well. Since the app only shows the bus stop number together with the name tied to the bus stop, searching for the location on Google Maps is almost impossible. Even the SMRT/SBS website that shows the bus stop and its location were not accurate for me. I searched “456 Yishun Ring Road” and managed to find it on Google Maps. However, it was not the correct location.
3. Bus vehicle number is hidden in a popup​. I assume that users are used to Grab/Uber/Gojek interface where the vehicle number will be communicated clearly.
4. When opening the app before the bus journey starts, the app does not show the ETA modal after the bus journey has started.
5. In the event that the driver checks for bus tickets and the number of pax boarding the bus, it would be important to notify the driver if the passenger can only make it to the later bus stops (if one is late).
6. A user of RushTrail opened the app just to see the ticket which required a few clicks (Home → Open sidebar → Click my bookings)
7. RushTrail/RushOwl sign on the bus was not prominent

On the bus

1. Bus driver did not check the bus tickets of passengers​. The bus driver is on time.
2. Some passengers that came later sat with passengers from the previous stops. I would assume ​referrals are a good idea to get more people onboard to optimise each route​.

After alighting

1. After the trip, my phone burned through almost 30% while constantly checking the ETA and location of the bus. To avoid this problem, perhaps a ​persistent notification that shows the ETA to my stop or ETA to my destination can be shown​.

With these findings, I proceeded to design the UI for their application.