Introduction
The MyTransport.SG mobile application integrates accurate land transport information, to empower Singaporean commuters with quality information — so they can make the best route planning decisions.
However, there were users who experienced challenges when route planning on MyTransport.SG. Often, they felt compelled to open other applications for supplementary information. This is counterintuitive to the “all-in-one” promise you would expect from a governmental application.
Design Sprint
In this project, we decided to confront our MyTransport.SG challenge with a design sprint. To create dynamism and synergy, we handpicked a group of subject-matter-experts and key stakeholders, to optimise idea generation, and to make objective decisions.
- Teo Wai Kit as a Facilitator and customer expert
- Gwendalynne Loh as a moderator and logistic expert
- Chew Li Juan as a design and tech expert
- Javier Lim Luo An as a Decider and design expert
As a group, we defined our target, and generated a smorgasbord of ideas. Later, we consolidated our solutions into a usable prototype, and tested it with real users. Due to Covid’19 restrictions, we discussed, planned and executed the sprint remotely via Telegram, Zoom, Marvel and Miro.
Ask the Experts
Putting all our user research insights on the table, we shared our opinions of what MyTransport.SG was, and was trying to accomplish. More importantly, we shared our visions of what we believed the product should accomplish in two years.
We listened and noted down each member’s inputs and drafted our list of How Might We (HMW) notes.
We voted for our most important and urgent “HMW” that we wanted to focus on for this Design Sprint, and placed them in a Voting Tree. This helps to narrow down our scope and look for possible design opportunities amongst the selected HMW notes.
Decider: 6 blue votes // Team: 3 blue votes each
The top lists for this votes were as follows:
How might we reduce the number of functions in the app and specialise it?
How might we streamline the app’s objective & function?
How might we make the search result more comprehensive?
How might we do something that google maps cannot do?
At this stage, it was clear the team had bought into a coherent idea. We all agreed that we saw immense value in MyTransport.SG’s unique data and information. Unfortunately, we also agreed that MyTransport.SG not only failed to leverage on their own strengths, they also jeopardised any competitive advantage by overloading the application with features that do not address users’ immediate needs.
Lastly, but most importantly, users consistently compared unfavourably, to the almighty Google Maps. It seems, the habits and transfer of training developed on Google Maps has created expectations that if not met, equates to frustration.
“Why can’t I find this? Google Maps would not have this problem.”
“Why can’t I click on this? It looks like I can click on it.”
“You mean I can’t navigate in live mode? Isn’t this basic? Google Maps and Waze has it.”
Challenge
After the vote, the voted contributor elaborated further on the UX research and the potential opportunities the team can consider when addressing the problem:
“First launched in 2011, MyTransport.SG app had great intentions. LTA wanted to empower commuters with real-time information, to make informed decisions (LTA, Mar 2013). However, LTA soon learnt that despite making the information available, a lack of user-friendliness meant the service was undersubscribed. So in 2018, they relaunched the current MyTransport.SG App. While the relaunch solved certain problems, there were aspects that were still to be desired.”
Based on this discussion, the group agreed that:
- Both MyTransport.SG and Google Maps have individual strengths
- MyTransport.SG is an information provider, not a navigation application. How can we leverage its strengths, and side-step its weaknesses?
- Users exhibit a lot of “stickiness” when they find a service provider that serves their needs
- Breaking their navigation mental models learnt from Google Maps is a pain. How can we remove this pain?
Long Term Goal
With the challenge in mind, we wanted to define a long term goal that encapsulates the team’s principles and aspirations. First, we each came up with an ultra optimistic two year target for this product. Subsequently, we voted again, before the Decider cast the deciding vote that determined the ideal goal our team will be marching towards in two years.
Decider: 1 green vote // Team: 1 red vote each
Our Goal: In 2 years time, I hope that Singaporeans will use MyTransport.SG as their preferred app to receive accurate and timely information to help make better route planning decisions on any navigational app out there.
Team Insights: While we were excited at the prospects of this goal, we were also extremely worried about the technical feasibility of achieving our goal. Also, none of us knew what our potential solutions would look like. Nervous but hopeful, we pressed on, trusting the sprint process.
Sprint Questions
Taking our doubts seriously, we put forth super pessimistic questions that could elicit constructive criticism, on what could stop us from achieving our long term goal. We brainstormed and identified potential challenges we might face with some “Can We” questions. Then, we voted again for our top 3 questions, that leads to answers to our long term goal.
Team: 3 red votes each
Decider: 1 green vote on the 3 highest voted questions
The top lists for this votes were as follows:
Can we synergise and integrate LTA’s and Google Maps strengths into 1 app, to leverage on their respective strengths?
Can we use information unique to LTA to stand out from current apps
Can we offer users information that other apps do not offer in a streamlined manner?
Team Insights: We were happy to resonate on the same idea. We felt it was important to achieve 100% buy-in at this stage, to avoid unnecessary changes in the project later on.
Map & Target
This is a critical section in the sprint. This defines the start point, and all the necessary steps a user has to make in order to reach the goal. With this, we have a clear overview of the whole process. Thereafter, we can zoom in on a specific area to focus our sprint on.
We placed our “HMW” notes with votes from the activity we did from the start into the map above. Through team voting and final decisions made by the Decider, it was clear that we needed to focus on Singaporean Drivers.
Why? It’s simple. Targeting the drivers gives MyTransport.SG the largest information leverage and competitive advantage. If there was a low hanging fruit for us to implement our ideas, this was it.
After we analyzed the problem and selected a target for the sprint session, we selected two techniques to aid us in the ideation process — Lightning Demos and 4-Step Sketch.
Lightning Demos
Before we dive straight into creating novel designs, we should point out that inspirations can be found everywhere. We were interested in this technique because we learnt that users develop habits. If a lot of users exhibit an inclination to adopt such habits, it gives us more reason to take a leaf out of these books, and see how we can implement them.
The team shared and reviewed the design insights of the various demos, before voting on ideas that can be remixed and improved on.
Ideas from Lightning Demo session:
From Waze
Highlight important information with obvious 3D icons that represent road accidents, hazards, speed cameras, etc. Provide fast and real-time information contributed by other drivers.
From Google Map
Allow users to hide and show information. This allows the application to include additional information without cluttering the interface.
From Uber
Allow users to switch between applications easily and seamlessly by the floating call-to-action button by the corner.
From Whatsapp / Messaging app
Users could preview information that appears on the mobile status bar without switching between applications.
Team Insights: We learn from the best. Even when picking inspiration, we choose applications that are widely pervasive in Singaporean’s daily lives. This gives us added confidence that these inspirations may work well in our favour, as opposed to more obscure applications.
4-step Sketch
In 90 minutes, this process challenges each team member to translate written ideas into creative visual solutions. This activity helps us focus on brainstorming and developing multiple solutions to a single problem. Due to the current COVID-19 pandemic, this activity was done remotely over Zoom.
Part 1: Note Taking (20mins)
The objective of this exercise was to consolidate our thoughts onto paper, to kickstart the creative process. Writing allows thoughts to form and to get our creative juices flowing. At this point, we don’t need to create anything yet.
Checklist:
1. Long Term Goal
2. Sprint Questions
3. Target area on the map
4. Lightning demos that inspired us
Part 2: Doodling (20minutes)
After reviewing through our notes, we selected an idea we would like to explore. Flexing our visual communication muscles, we illustrated our written thoughts into visual ideas.
Part 3: Crazy 8 (8minutes)
As crazy as advertised, Crazy 8s pushed us to build upon our initial thoughts, to develop new ideas, one after the other within a crazy time frame. We created 8 boxes by folding our A4 paper. Next, we each chose our favourite idea, and illustrate in 8 different ways, in under 8 minutes.
Part 4: Solution Sketch (30 — 40minutes)
In this finale of our 4-step sketch, we gathered our thoughts and ideas that are aligned to our long term goal.
To create an unbiased vote, we keep our sketches anonymous. Hence, each of us gave our own solution sketch with a catchy title, and added simple annotations to guide and explain our ideas. Otherwise, our sketches have to be self-explanatory.
Team Insight: This was the first activity that saw the team work separately and anonymously. Team members had the autonomy to ideate in any direction, as long as we all worked towards the same goal and target areas. Interestingly, two members presented very similar ideas. It was especially satisfying when we learnt that we could easily borrow elements from all solutions and create something better than we did individually.
Having completed the ideation/divergent phase, we now move on to the convergent and decision phase. Here, each team member is required to vote on the ideas from each solution sketch. The product of the vote is the finalised concept to be prototyped. There are 4 deciding methods being utilised to achieve consensus on the idea. Thereafter, the Decider will decide on the final direction that addresses our goal.
Heat-Map
This activity was about creating a “heat-map” of opinions to guide us on making our vote. Before voting, the team was reminded of our goals, sprint questions and our target. We reviewed and commented on each solution sketch. Lastly, the whole team was given unlimited red dots to vote on every idea that best addressed our sprint questions.
Team: Unlimited red votes each
Speed Critique
This session is all about calling out the big ideas with the most red dots, without describing the concept in detail. While the Facilitator briefly presented each solution sketch, the rest of the team chimed in to clarify and discuss the ideas.
Straw poll
Everyone on the team, less the Decider, will look at the solution sketch with the most voted red dots, and decide on which concepts we should prototype and test. Each team member was given 3 blue dots to vote on their favourite ideas, and subsequently explain their votes with post-its. The post-its are mainly used to persuade the Decider to buy into that concept.
Whole team except the Decider: 3 blue votes each
Supervotes
Our Decider has a critical decision to make. Armed with 6 green votes, he casts supervotes for the ideas that would lay the foundation to our prototype. We then planned our prototype with the ideas below:
The Storyboard
By mapping out the steps users take to reach their goal, the storyboard aligns the team and defines the prototype task flow. Each member contributes their preferred user task flow, then the Decider votes for the most succinct task flow and actions.
User Task Flow
Each team member brainstorms six key steps; starting from a realistic entry point, users navigate through our selected ideas until they achieve their goal.
Everyone (except the Decider) voted for what they believed was the most succinct user task flow. Next, the Decider will cast 2 green votes.
- First green vote decides the preferred task flow
- Second green vote decides an interesting action step from another row that would be value-add to our solution
Decider: 2 green votes // Team: 1 blue vote each
The selected user task flow (assuming that user has input their locations):
- Pin two features in the shortcut bar
- Activate the “Car Park” and “Road Conditions” features by tapping on shortcut bar
- Check for car park information by clicking on call-to-action bubble
- Select the nearest car park to the destination
- Check for other road conditions
- Select route and click “Navigate”
- Switch from MyTransport.SG app to preferred navigation app
(Google Map)
Final Storyboard
After deciding the user task flow, we can map out each step of our storyboard in detail. The main purpose of storyboarding is to leave no open question for the prototypers. We sketch out an entire journey, with adequate details, so everybody is aligned on what goes into the prototype.
It is important to note that the idea of including a shortcut bar, that could be personalised for different users, would entail including a wide variety of different features on a larger scale. Since our user task flow indicates “Other Road Conditions” as the second feature in the shortcut bar, we decided to narrow that down to the identification of speed traps along the selected route. Taking that into account, we are aware that the test prototype will be in no way fully representative of the variety of features that could be available with the personalised shortcut bar.
To avoid unnecessary effort, we reviewed our solution sketches, and used what we had in some of our storyboard frames. Lastly, we verified whether the sequence made sense, and ensured that we do not add any brand new ideas or anything unnecessary. Our finalised storyboard kept us on track during the prototype process.
Having mapped out our storyboard, we proceeded onto making our initial ideas come alive!
Our prototype would ideally allow us to:
- Make the app more personalised for users
- Improve the overall journey planning process
- Integrate MyTransport.SG with Google Maps
Each team member was allocated a role as follows:
Li Juan & Javier as Makers
— Responsible for the skeleton and wireframing of the app
Waikit as Asset Collector
— In charge of the visuals of the prototype
Gwen as Stitcher
— Final touches and making sure every page runs seamlessly
As the makers, Li Juan and Javier created individual components of our prototype. This came in the form of icons, map layouts and the general design of the prototype pages. Wai Kit, on the other hand, helped to obtain screenshots as well as reference images needed for makers to include in the prototype. As our prototype was intended to combine both MyTransport.SG and Google Maps, we were able to simply use screenshots obtained from the latter to be used as part of the prototype. Gwen, the stitcher, was then responsible for collecting the screen layouts and components from the Makers and combining them on Marvel seamlessly. She also had to make sure details as well as positioning of components were consistent throughout the prototype.
Team Insights: While simple in theory, this proved to be more time-consuming than expected as it was difficult to establish consistency throughout the screens with several members working on it within a short period of time
While stitching, we realised that there were missing steps, and screens that had to be created in order for another step to take place, which made the entire process less efficient
Our idea of allowing users to toggle features on and off in any combination, proved to be quite complex to prototype, as there wasn’t a fixed user flow. It allowed many ways for the user to access the different features which meant that by using Marvel, we had to create several possible flows in order to allow testers to explore freely.
Now that we have our Marvel-lous prototype, let’s put it to the test.
Create an interview plan
Hold your horses, doing a “Sprint” does not mean we rush head on. Although only 1 interviewer is elected, it is important for all members to plan, and agree on a congruent interview approach. We adopted the “5-Act Interview” approach and documented our interview plan as a team.
Act 1:
Friendly Welcome
Our affable interviewer put the interviewees at ease with a warm smile, and a light conversation:
“Thank you for taking the time to join us today. Have you done a session like this before?”
“Have you heard of the MyTransport.SG application? What do you think about it”
“We have been working on some features within the MyTransport.SG application and we would like your help to understand if it meets the user’s needs. Don’t worry, we are not testing you, rather, we are asking for your help, to test the design, and understand how to improve it.”
Act 2:
Open Ended, Context Questions
The last thing you want is to restrict or prime your interviewee. We ask open-ended questions to understand their goals and how they normally achieve them.
“How often do you drive in Singapore? Are they mostly repeat destinations or novel destinations?”
“Suppose you are driving to a new restaurant your friend introduced you to. How would you plan your route?”
“How would you rate your route planning and navigational experience?”
“What is your favourite feature of the app?”
“If you could improve any aspect of the app, what would it be?”
Act 3:
Introduction to the prototype
The interviewee is using the prototype for the first time. It is important to define the scope, set the context right and manage expectations.
“As I have mentioned before, we are currently working on a portion of the MyTransport.SG application and we have prepared a prototype for you to interact with.
“More importantly, we are not testing you, rather, we want you to test the design of our prototype, so we can improve it.”
“Try your best to vocalise as much as you deem reasonable, so we can understand your thought process. You may pause at any stage to clarify with me.”
Act 4:
Tasks and sub-tasks
The testing is stressful enough. Reduce the stress by preparing a simple list for easy reference.
“I have a short list of tasks for you to attempt and complete. I have prepared a copy, so you can refer to it easily.”
“Don’t worry if you missed out on any of them. I’ll remind you at an appropriate time.”
Act 5:
Debrief
To elicit honest feedback, we abstain from explaining much at the beginning. But now that we have completed the session and the interviewee has had the opportunity to explore the system, we dug a little further to extract more insights.
“Congratulations, you have successfully tested all the tasks we have prepared. How would you describe your overall experience with the prototype? Between 0 to 10, 10 being the best, 0 being the worse and 5 being neutral, how would you rate your experience?”
“What was the best feature of our prototype? What would you improve on?”
“What did you think we were trying to achieve with this prototype? Do you think we are successful?”
“Do you think we are headed in the right or wrong direction? And why?”
After the sessions, the team met to discuss their general notes of the interviews. Later, we returned to take a deep dive, and make sense of the data.
Looking for Patterns
To analyse the responses we obtained from the user testing and interviews, we started off by looking for patterns within our collected data. By creating a grid and then drawing 1 column for each user, and 1 row for each section of the prototype, we began breaking down our recorded interviews into sticky notes. The sticky notes were then placed in the grid according to the user and section of the prototype.
Following which we classified them into either positive (green), neutral (yellow) or negative (orange) feedback according to the post-it colors. Our group also included an extra colour (pink) to identify post-its that provided suggestions instead. Having tagged each post-it, we grouped the responses according to distinct patterns, each recurring from at least 3 different users and proceeded to place each group along a positive-negative spectrum.
So what worked?
- Overall, the prototype was successful, and on the right path
- Testers enjoyed the ‘Carpark’ and ‘Speedtrap’ toggleable features
- Prototype was easy to use
- Testers easily picked up on the integration between MyTransport.SG and Google Maps, and were able to move seamlessly between the two apps
What were the challenges?
- Icons and terminology used in the prototype were confusing
- Testers took awhile to figure out how to use the features and shortcut bar
- Shortcut bar placement not ideal as it is not easily visible
- Re-routing pop-up in Google Maps app is a distraction
- Some users did not find the ‘Speedtrap’ feature useful
Suggestions offered by testers:
- To include other features in the shortcut bar
- To include other features in other parts of the app
- To include a tutorial to help users onboard
Overall, there is a mixture of positive and negative feedback for the prototype. The main features that we added received mostly positive feedback, while negative responses were focused on the details and created opportunities for us to further improve on our chosen idea.
Next steps & Recommendations
After sorting through the test responses, we revisited our long term goals and sprint questions to find out if our prototype had accomplished its aim afterall. We also used these as a guide to identify areas for improvement.
Our long term goal:
Having received quite an overwhelming amount of positive reviews regarding our prototype, especially in the areas of general usage and reaction towards our overall idea, it’s safe to say that YES, we are on track to accomplish our long term goal. However, there are certainly improvements to be made to fully achieve this goal.
According to feedback, some users found the new features confusing at first glance and had trouble figuring out how to interact with the app. We could adopt one of the suggestions to include a tutorial within the app to help users onboard. This is a common procedure in apps when new features are added and we believe that by having some sort of visual rundown in MyTransport.SG will definitely aid in improving the usability and decreasing confusion.
Our sprint questions:
While we left the real-time navigation portion to Google Maps, our intention for MyTransport.SG was to complement that with LTA’s unique pool of information. Having established that, the synergy and interaction between the two apps had to be seamless in order for the integration to be truly successful.
Our test responses showed that YES, our prototype was indeed able to showcase how MyTransport.SG and Google Maps can be integrated as users had little trouble understanding how the two apps work together and figuring out how to toggle between them back and forth. More importantly, it did not force them to switch from their desired navigation systems. All their habits, past searches and frequent places that they are so used to having were left the same, as they were.
An opportunity for improvement is how LTA’s information is received in Google Maps. Users found that requiring drivers to acknowledge notifications from MyTransport.SG while in navigation mode and having too large of a message blurb could be distracting. Perhaps re-routes like the one carried out during the prototype testing could be automatic instead. Or the notification could be very concise, while still placing the decision powers with the users. Only further testing will reap results. If the notifications pose as a visual distraction to some users, they could also opt for them to be read aloud from within the app instead.
We decided to group these two sprint questions together as we felt that our solution answered them as a whole. According to feedback, we were able to offer users information unique to LTA as well as information that other apps did not offer. This came especially in the form of the Carpark feature which all users felt improved their navigation experience and was something that helped set us apart from existing apps.
However, users felt that more could be done in order to stand out from competition as some of them did not find the ‘Speedtrap’ function as useful as ‘Carpark’. However, as previously mentioned, our idea on a larger scale was meant to include a variety of features and our prototype was limited in its scope (with only two features) to ensure a more concise testing process. As such, we acknowledge that some functions, such as ‘Speedtrap’ would not cater to all users. In fact, most of our users suggested other features that could be included in the shortcut bar that they would find useful, not limited to:
- ERP/toll rates and timings
- Road works schedule
- Location of amenities such as petrol kiosks
- Carpark rates
- Lane recommendations
This also validated the decision for personalised shortcuts. Everyone has different preferences and we felt that the feedback validated the desire to allow each individual to create their own perfect journey.
We also concluded that while we were able to offer unique information to users, the overall experience was not streamlined enough and still had much room to improve on. Opportunities for improvement include:
Icons and terminology are confusing and inconsistent:
- Improving the icons making them more identifiable when shrunk in the shortcut bar
- Be consistent in using ‘shortcut bar’ to refer to personalised shortcut bar in all instructions and onboarding tutorial
Shortcut bar placement not easily identifiable:
- Improve visual hierarchy by repositioning the shortcut bar right below the navigation section to improve identification. Our testing, and secondary scanning research, showed how users tend to read the page from top down.
Other miscellaneous improvements to refine user experience
(not priority):
- Adding additional stops in navigation
- Adding ETA to main screen
- Using more detailed map layout to include road names
Revisiting the long-term goal and sprint question allows us to prioritise certain improvements above others and directs us towards specific actions that should be done as soon as possible. From the above analysis, we believe that answering the sprint questions are of highest priority, followed by achieving the long-term goal.
Conclusion
Moving forward, additional sprints would definitely benefit the project. Our prototype includes a variety of features that users can choose to personalise their shortcut bar. Future sprints can be carried out to test out ideas that were borned from the suggestions that our first sprint testers gave us. Also, since we are on the right track, we can also find out which LTA unique information sets users desire, and implement a cohesive way of presenting the information. Our goal will always be to serve our users better.
In our prototype testing, despite plenty of positive reviews about the ‘Carpark’ feature, some users requested adding parking rates. As a team, we resonated with that feedback. Looking back to when we had significant concerns about our goals, and then comparing that to the present where our ideas echoed with our users, we are as happy as much as we are relieved. Also, we are glad that this is far from being the end of the road. Based on the feedback, we are encouraged by our users to probe deeper into our solution.
In conclusion, our group is glad we took a bold approach in positioning MyTransport.SG as a transport app that complements the current giant navigation apps, such as Google Maps and Waze, instead of trying to replace them. We feel that by focusing on our strengths as an information provider, we can leverage on users who are and have been ‘sticky’ towards more dominant navigation service providers such as Google Maps. So instead of migrating users from Google Maps to MyTransport.SG, we encourage them to use both apps, seamlessly.
