Target Audience &
The project commenced with user research, and the goals were to discover trends and behaviours of commuters so as to find probabilities of improving their commute experience.
The target audience group is the millennials, age 23-32, as they are the largest percentage of the population and also, they have the most spending power, which is an important aspect in a business perspective.
Five user interviews were then conducted with participants in the targeted age range.
Public Transport is the Only Choice
The first, and very important, question to find out is how are they commuting? From all the Five user interviews, they responded that public transport is their only choice because of price consideration. However, when asked about their commute experience using the public transport, comments were negative. This hinted opportunities to ameliorate experience of commuting.
To further understand the users and their commute options and experiences, data from the user interviews were synthesised with the method of affinity mapping and on the right shows some of the findings.
It is understood that they have other preferable options, but because of price and time considerations, they have to use public transport instead, for their daily transits. Grab, one of the options with more mentions than the others, was commented to be a more expensive and would only be used in situations when running late, or to have a shorter travelling time.
Motivation to commute is low
Alternative Options are too Expensive
I Want to Sit Down
Another insight suggested the need of the users. Out of the five user interview participants, four mentioned that it is more preferable if they can have a seat. Two participants also mentioned that when they have time, they would not mind taking a longer bus journey home just because they can enjoy sitting down while taking the bus ride. This implied that they are willing to exchange time for comfort and it is also one of their commute consideration.
Always Short of Time
The synthesised data also pointed that the users’ are not good with time management and are often short of time, during or before commute hours. As time is also one of the important factors that would affect the users’ choice of transport option, this insight could be a substantial reference.
To better understand the user’s commute experience and flow, two storyboards are illustrated, as above, with real descriptions of commute journeys from two participants of the user interviews. From the storyboards, the inconveniences of taking public are also discovered.
As mentioned earlier, it is more preferable for the users to be able to sit. However, due to typical commute time, the train is always crowded and therefore, seats are always full. Another discovered encounter is that, very often, if by car or taxi, the travelling time will be much shorter, but with public transport, not only that the travelling time will be longer, there will also be a need to transfer to another bus, or line. The journeys also require few walks in transition to another bus, line or transportation. According to a transportation mobile app platform, Moovit, 69% of commute journeys includes at least one transfer to another line.
To have a shorter and more convenient journey, the only other options are Grab and Taxi, which are almost 10 times more expensive than public transport.
It is more delineated that price, time and comfort are the most important considerations for the users.
Two personas are then created to clearly define the user types, and their needs and goals. One of the more important references from the created personas is that they value comfort, and also prefer a shorter travelling time, but because of price consideration, the only affordable daily commute option is public transport. One of the personas is created to prefer more of a shorter travelling time, and uses Grab as an often commute transport, which the expensive cost has affected the experience, to remind of the need to reduce the price when designing the solution.
To analyse and evaluate current commute options, a product value matrix is developed. It shows how far apart are the current options and the opportunity to create a solution is seen, which has only subtle cost difference, increase of comfort and lesser transport time, which are the defined objectives.
One of the commute options, Grab Hitch, placed on the matrix, reminded how the organisation achieved a lower private hire car cost, by having users to share a ride. This inspired me to apply the same concept on bus, which sparks the idea of a bus pooling platform.
How it would work is that the designed app or platform will gather commuters that commute to and from the same places or similar areas to share a bus ride with a direct route. The cost will be much lower than common private hire cars or taxis because more people are sharing a ride.
The user flow is then planned to outline how the app is going to work. First, the user will have to search and book or create a ride, more users will have to join, therefore, there will be some waiting time. Once the ride has gathered enough users, a notification of the confirmation of the ride will be sent.
Another possible scenario is that the ride will not gather enough users and will be cancelled. This was feedbacked as frustrating by many users, when the prototype was put to test. It would however, less likely to happen if there is a bigger user base. With nearly 4 million of commuters daily, according to gov.sg, the market size is significantly huge and it plays apart in obtaining potential for the app to reach a critical mass, thus decreasing the chances of the described scenario to happen.
Having the flow planned, a feature prioritization matrix is created to make sure the app has the features to at least function, and also to identify which other features to prioritize given with the limited time.
The must have features are search rides, create or book rides, payment, ride suggestion and notification.
As the concept of the app is to gather users to share a ride, so as to lower the cost, there will be some limits if the app does not have an essential numbers of users, so as to more conveniently engage users together. For example, the app will only allow users to create or book rides minimally a week or in increment of weeks. In short, it will be easier to gather the norms; commuters who work on every weekdays and have a typical working hours from 9am-6pm.
Ideally, if the app reached a critical mass, the limits will be removed
General planning of the app is done with wireframes sketched, to plan and make sure the flow is right before moving on to mid-fidelity prototyping.
Two very essential pages, the home page and the search result page were built and put to test first with three users, as it is important that the users understand or get a clue of what the app is about and what they can do with it. Iterations and usability tests were done till it is understandable that one can search and book a bus ride using the app.
The mid-fidelity prototype was then built further and again, put to usability testings, with a tasked scenario.
Enquire user about their commute choice/behaviour and how they feel about it
Show user the home page and ask user if he/she understand what the app can do
Task the use: “You reside at Waterway Point and commutes to work everyday at 9am to MBFC (Marina Bay Financial Center). You want to book a ride for your daily commute for 1 month from 25th February. Can you do that?”
Every usability test started with showing the user the homepage, and he or she was asked to look through the home page and think out loud, what they see and what they think it is. The user was then given a scenario and a task to accomplish.
The prototype was tested with two to three users before each iteration, and the final prototype was tested with five usability testings which highlighted the confusion of payment and having the need to wait for more users to join, which the next iteration will need to improve.
On Next Phase
What Went Well
What Could be Improved
App should clearly illustrate more that the user’s card will only be charge when ride is confirm
Clearer highlight that user has to wait for more users to join before ride is confirm
I thought it would be challenging to identify a problem with the topic transport, in fact it is, and I thought even if I did, coming out with a solution will be extremely difficult as transport, in every aspect, is already very established. However, following through the design process, it went well.
I as well managed by time better than the previous project, which was the reason of my poorly delivered presentation. It was handled better for this project and I had enough time to practice my presentation which I thought I did well, also with most of the questions answered.
As mention, the concept of the app is relatively new, I was not sure if I needed the user to understand what the app is about with just looking at the homepage, and spent time iterating it. Also when tasked with the scenario, few users could not thoroughly understand how it works. I was dubious of if it is right to brief the users first of how the concept works. I however, did not, and tasked the users without telling them how it works and what the whole concept is about. I thought it would be better in terms on working on improvements.