Design Case Study Research | mytransport.sg
Rethinking and proposing solutions for an app that will provide commuters with real-time information to help them plan their journeys better — mytransport.sg
Initial Research Methods (Done independently)
Contextual Inquiry | Interviews | Empathy Mapping | Affinity Diagramming | Persona Crafting | User Journey Map | Story Board
Design Sprint (Done with a team of 4)
Introduction
Mytransport.sg was first launched in 2011 to equip commuters with static and real-time transport service information, with more than 3.5 million downloads to date. This is in line with the Government’s Smart Nation vision of harnessing digital technology to improve quality of life.
Contextual Inquiry
I started the project with contextual inquiry to help understand the thoughts of users regarding how they plan their route and their impression of the app. Users were given a task to find their way from i12 Katong to ABC Brickworks Market. The process of inquiry conducted were video and screen recorded for me to review the experience so that I do not miss out any insights through their body language or verbal comments. Empathy maps and observations were written during this exercise.
“3 in 5 users will not use the app again.”
Interview
A 30min interview was conducted with user and non user to find out more about their transport expectation and how they feel about the app. The interview was conducted over a span of 35 questions from general questions of themselves, to their daily travel habits, route planning methods and in app-experience. During the interviews, users were given task on the app to understand if they are able to reach a similar goal with or without prior experience.
During this experience, I videoed and screen recorded the sessions to note down their body language and verbal comments onto observation sheets and empathy maps.
Affinity Maps
I placed all the insights by individuals onto Miro to organize the insights through affinity maps. Apart from the insights collected through users, further research were done to understand more regarding the product.
The affinity map were organized by 4 colors:
Green — Statistics and facts based on research
Yellow — Personal observations through users
Red — Users Quotes
Blue — My understanding of the clustered data
Through the research so far, I believe users may have misconception of the objectives of the app that it should function like google map instead of providing information as it was initially conceptualized.
On top of that, users are confused with the numerous offerings in the app without a proper breakdown for its targeted audiences.
Persona
Based on 7 users, a persona was created to help understand the needs and solutions of a user.
Jeremiah was created with a few factors in mind, he will need to take public transport and it must be features that can be tracked through the app. The age group was decided based on average of the users interviewed. Goals, pain points and core needs were a reflection of insights collected from the research.
Customer Journey Map
Based on the persona, I created a customer journey map to further communicate the process that user go through, to understand and address the needs and pain points.
The customer journey map created shows how Jeremiah interact with the app, capturing his emotional journey through the process.
Storyboard
“Storytelling is the greatest technology that humans have ever created.” — Jon Westenberg
Apart from the customer journey map, a storyboard was created to ease the communication of the pain points users go through.
Recommendation from initial research
01 | Enable users to select mode of transport
Allow users to select their mode of transport upon opening the app so related features will be shown for the ease of use.
02 | Better usage of colors
To provide a change in color scheme within the app instead of just greyscale. Different design of lines to indicate walking path, bus routes or driving routes.
03 | Intuitive interface
Provide users with a straight-forward interface that allow users to key in “Where they are” to “Where they are heading to” with function for them to include arrival timing.
04 | Live Tracker
Live tracker to direct users especially for those walking towards bus stop/train station
05 | Reduce the space used on map
Suggest to show more directional information after search, instead of having the map take up 80% of the screen
06 | Enable search by postal code
Common search method used by users which would be useful to include in the app as users tend to search using postal code or commonly used name of the location they are heading to or from
07 | Cycling PCN Entry & Exit Point
The app is lacking information of where to enter and exit PCN for cyclist. This would be an important information to keep everyone on the road safe.
08 | Inform users of redirecting
Inform users that they will be redirected out of the app instead of just snapping them out to another app as this would be rather disruptive for users.
09 | Cost summary
It would be a good feature to include the cost of travel as part of the search for users to better plan and manage their travel expenses while making their choice of transport.
10 | Carpark & traffic camera
It will be good to include nearby carpark and traffic cameras information on the route searched by users, as this will help to keep users within the app.
Conclusion from initial research
The marketing direction and message used to promote the app should be directed towards providing one-stop information to all types of commuter, so we can avoid the misconception and wrong expectation that users have of the app for being too similar to Google maps.
The features and functions of the current app are useful for users but there are too much features available that confuse both current users and potential new users. The features should be catered according to the type of user.
Design Sprint
With the initial research done, I did a design sprint with a team of 4 to rethink and propose solutions for mytransport.sg with the idea to help consumers plan their journey better. Our team of 4 have individually done user experiences research before we came together with insights to kickstart this design sprint.
Within the team, we appointed a facilitator who will keep track of our schedule during the process and a decider that makes the final decisions.
Map
As we all did our research individually, we started with “Ask the Experts” with the help of our facilitator. We spent 5 minutes each sharing our insights from our research while everyone else in the team wrote down their thoughts using “How-Might-We” to guide our perspective from a challenge to an opportunity from every insights shared.
After everyone was done with sharing and “How-Might-We”, we organised them accordingly. With our notes organized, everyone proceeded to vote on which of the pressing issues we should focus on with the decider having 5 votes while the rest of us having 3. We did a voting tree by picking out the most voted notes and placed them at the top.
The key problem that came out to us was how we can improve it to make it less confusing for both consumers and drivers, how the app can help plan our journey better, and how the app can cater to the needs of different users.
We started making long term goal & sprint questions with the help of our “How-Might-We” notes. Everyone contributed with a long term goal that starts with “In 2 years time…” and we voted for what best aligned with our vision for the challenge. We approached the sprint questions pessimistically so we can approach it as an opportunity after. As a team, we proceed to vote for the questions to decide which we will tackle.
With all of the above done, we proceed to work on mapping the journey from how users will begin and end using the app, breaking down into 3 steps “ Planning, Journey, Arrival”
From the journey, we placed our “How-Might-We” notes from earlier activities where it occurs so we can identify worthy targets to focus on for the project. From this exercise, we divided users into 2 different groups; commuters and drivers. The journey map provided a clear picture of our users needs and where the bulk of concern usually appears. As our priority “How-might-we” notes from the voting tree were found under the planning stage of the journey, we decided to focus on it as the target, with our decider making the final decision to this choice.
Sketch
After identifying our target, we proceed to suggest 2–3 Lightning Demos each. We drew inspiration from existing solutions that may or may not be directly related to what we are doing, and wrote down why it would be relevant to our goal. We took 3 minute each to share our ideas among the team.
We proceed to do a “4-Step Sketch” after sharing.
1) Notes
We took 20 minute on our own to relook at all our notes from the beginning, jotting down notes which shout-out to us personally. This exercise also helped to refresh our mind and remind us of our goal.
2) Ideas
With another 20 minutes on our own, we did rough sketches and solutions to our goal. This exercise quicken our mind into the churning process and helped us focus.
3) Crazy 8s
The real challenge came when we individually did 8 sketches of solutions onto an A4 paper within 8 minute. This challenge forces our brain to think, and only gives us time to draw out essential items for the solution, nothing fancy. It truly brought out the saying of “Less is more”.
4) Solution Sketch
The final step would be spending 30–45 minute drawing out a self-explanatory solution across 3 pages of A4 paper anonymously. On the solution we pen down the details, sketch out the idea, and explain how each function benefits and lead us to our initial goal.
Decide
Heat-map
From the solution sketch we did anonymously as a team, we looked through each other’s sketch and used unlimited red dots on every idea we thought were good, with the sprint questions and goal in mind. As the sketches were done anonymously, we added post-it at the bottom to raise questions/concerns regarding the sketches.
Speed Critique
Coincidentally, our sketches had a few similar features across the board which make it easy for us to identify which idea we all agree on. We discussed each idea and voiced out what we liked about each. As the sketches were done anonymously, we try to share what we understand from it so as to discuss the questions and concerns.
Straw Poll
As we discussed and pointed out that “Solution D” was the closest to what we all had in mind, checking most of the boxes of our goal, we were quick to vote for our solution with 3 blue dots each with explanation notes of why we put our dots on the solution. This helped our decider decide during “Supervotes” later.
Supervotes
During supervotes, our decider used 6 green dots to cast the vote on solution with notes explaining the choices made. The solution with the choices made were arranged together which we will use in prototype development.
Prototype
User Test Flow
Reviewing our solution, everyone took 6 sticky notes and wrote 6 steps of how users will be using our solution from the winning sketch voted previously. As our solution catered to 2 different groups of users, some of the steps were broken down differently for the 2 users’ group, drivers and commuters. After which we voted on the flow that is clearest for our users.
Storyboard
We moved on to the storyboard where we intend to work on with 15-grid frame. With different thoughts in mind, the team build our thoughts as sketches within our Miro board during discussion. This process took us some time as we were trying to understand each other while working on it remotely using existing tools available on Miro and our sketches.
We arrived on the same page with this flow which took up 6 frames instead of 15 in the end.
The changes made were mainly focusing on features that help with planning user’s journey:
1. Homepage
Allowing users to personalise how they would like to use the app to their convenience.
2. How drivers can plan their route
• Departure/arrival function
Allow drivers to plan by setting the time they would like to depart/arrive
• Amenities suggestions
Allow drivers to filter amenities they need near them e.g. carpark, ATM
• Parking counters
Allow users to see parking lots availability nearby
3. How commuters can plan their route
• Departure/arrival function
Allow drivers to plan by setting the time they would like to depart/arrive
• Suggesting different route of transport
Allowing users to see different route that they can take to their destination
• Location based bus stop tracker
Allowing users to track where they are while on the move, including bus arrival timing, and when to get down when required
With the flow in mind, we divided ourselves into 3 different roles:
• Makers — Creating the individual components of the prototype
• Asset Collector — Sourcing for icons/images
• Stitcher — Combining the whole prototype together
We worked on Figma for our prototype as we can easily work on it together and it helps keep things consistent with the number of duplicated screens. We did some adjustment together after the first draft before we move on to work on both group of users, and proceed to link them for testing.
Test
Checkout the prototype here.
As we have 2 group of users, Drivers & Commuters, we did the prototype testing with 5 drivers and 4 commuters with notes in 3 different colors. Green for positive, yellow for neutral and red for negative.
We started looking for pattern within the grid system created, and the flow based on what the users did or area which the comments were made. Within its grid, we try to group similar notes together so we can better organise them after.
We organised it better by removing the names and dividing line and putting similar patterns together. From there, decider placed notes of how to follow up on some of the patterns identified. We did a round of heatmap within the team to decide what to focus on.
Drivers
Overall, all the drivers interviewed said that the app met their needs as a driver, They were able to use the app without facing any challenges, and the interface was straightforward for understanding.
What worked
• Bookmark/favourite function
• Amenities function including parking lot, nearby ATMs
Challenges
• Customisation “Plus” sign
• Departure time display
• Amenities icon design
• Colours on map
• Home icon
User Suggestions
• Route Filters
Commuters
Overall, the commuters interviewed said that the app was easy to use with some functions similar to what they would use in Google map. The interface is straightforward and served its purpose for commuters.
What worked
• Interface
Challenges
• More detailed information/result from the search
• More breakdown information on the go
• Walking information
• Get down alert
User Suggestions
• To & fro arrow change
Long Term Goal
In 2 years’ time, our app will be the preferred app for drivers as well as public transport users.
A tentative, yes. Both drivers and commuters think the app meet their needs and is comfortable using it which is a good start for us to head towards the goal as we continue to build and modify it further.
Sprint Questions
1. Can we be Google map without actually being Google map?
A tentative yes, as we move forward with the adjustment required by the users, based on the users feedback, the changes required leaning towards the look and feel of the interface, some additional functions that we need to look into.
Function met:
- Bookmark/favourite function
This is not a new function but we discover how it can be commonly used among users, commuters and drivers, and they can get dependent on it if they use the app daily. Having included the bookmark function encouraged users to save their commonly used route more easily.
• Amenities function which includes parking lots, atms nearby
The idea of it was well received by the drivers, especially the parking lots available as it provided them with an overall view of where there are parkings, and save them the trouble of driving around searching for one. Other suggested amenities can be considered with more research done.
• Interface
The overall interface was straightforward and easy to use which was one of the team’s primary concern, as we wanted the app to be simplified enough for users to know how to use it immediately. With this initial direction checked, we can continue to work on the functions required bearing in mind not to complicate it for the users.
Design Improvement needed:
- Customisation “Plus” sign
As users have different understanding towards this function and this being one of the important components when it comes to customizing the homepage, the team will look into how we can improve on it in the next stage. - Amenities icon design
The overall feedback of this icon was very negative, with comments of how the little icon misled them and how it can be simplified. The team will take the suggestions into consideration and work on it in the next stage. - Colours on map
Users find the map too colorful which we find the comment valid after we compare it with other apps as suggested by users. The team will consider adjusting the colors used in the map, and to apply colors only on areas showing key information, in the next stage. - Home icon
The icon choice used here is misleading for the users as well. Instead of the drop pin icon, we will consider changing it to a house icon which is more universal for users to understand, in the next stage.
Additional Functions to include:
- Departure/arrival time display
While the team focuses on providing users with the ability to set their own departure/arrival time for planning, we overlooked the importance of allowing users to see when they should depart when they set arrival time, or when they can arrive when they plan ahead with departure time. This is something we can adjust to include on the interface since it is an important information for user’s planning, in the next stage.
- To & fro arrow change
This is a function that the team missed out during the prototype stage which allows users to switch easily between where they want to go and where they are, which we can easily implement in our interface, in the next stage.
To conclude, the functions needed can be adjusted and implemented. With the changes made, we are definitely a step closer to allowing users to depend on the app for their daily use.
2. Can we break down all the information real time without lagging on data?
Not conclusive yet, there is still some work to be done regarding how we can include more real time information to the users.
Challenges faced:
• More detailed information/result from the search
We realise that users require more information when they conduct their search.
For drivers, they want to see more information on road congestion, ERP, traffic lights or how to avoid the highway completely. This is an area we have not considered previously and will look into in phase 2.
For commuters, they require clearer information of how they walk to the mode of transport proposed, live location tracking, bus stop number, landmark images and whether the incoming bus would be a single or double deck bus. With the massive amount of required information, the team will look into how to include and to research further if certain information is really necessary, in the next phase
• More breakdown information on the go
For drivers, users require more traffic information which we have not included in our prototype even though it was in our discussion. The team will be working on how to include it in the next stage.
For commuters, users required more information which the team felt were valid when you are traveling to places you have never been to. Some area we can explore moving forward are:
— More descriptive information on the place e.g. “Opposite entrance of ABC Plaza by ABC Road” instead of just “Opposite ABC Plaza”
— Include Bus Stop Number
— Include images of the surrounding/landmark
— Include business information of the place searched for
• Walking information
This function had been on our mind but we overlooked it in the midst of developing the prototype. With users bringing it up again shows the importance of helping users find their way to the mode of transport which we will include in the next stage.
• Get down alert
Users require alerts to let them know when to get down instead of tracking the journey on their own, which we can implement in the next stage.
3. Can we combine all driver needs in a screen?
A tentative yes, the current prototype checks the list for the driver. A common suggestion from the drivers we interviewed was to include a route filter which should be available during the search and on the road. The route filter should include the ability to filter a route without ERP, a route with lesser traffic light, smoother traffic, which we can work on in phase 2.
Recommendation
In the next step
We can work on the following areas immediately for it to be implemented and do more research on it to gather users’ responses after implementation.
Phase 2
To focus on how we can include filters for drivers during their search, what kind of filters, how each filter function works and differs, would be a big part that require another sprint exercise to expand and test on. Therefore we would consider working on it in a later stage after implementing the first update.
For commuters, we will focus on how to provide more information for them in their search results and usage on the go.
Conclusion
By the end of this design sprint, we concluded that the suggestions made were suitable for implementation with the positive response from the users tested. While there are improvements to be made, the team decided that the remaining changes should be in the next phase.
The results we received from the research and sprint had been rewarding and insightful for the entire case study.
