Design Sprint: Ways to improve user retention on MyTransport.sg 🙌

This is a story about our first Design Sprint. We’ll share with you how we set a goal to increase data accuracy and how a Design Sprint helped us achieve this goal. This results in the development of a prototyped, user-friendly app that received positive reviews.

MyTransport.sg is a mobile application that was launched by the Land Transport Authority of Singapore back in 2011. The application offers users a central database of information for all modes of transport in Singapore.

Previously, regular updates were released to improve the user experience of the application. This did not improve the ratings on the app store due to the poor accuracy of the bus tracking.

Negative reviews on bus arrival timing. (Some examples of user reviews)

Bus tracking works in one of three ways (some does both or all):

• Data provided by bus operators are entered manually by the app developers.
• Data is displayed through a tracking API from the bus operator.
• Data is crowdsourced. That means that every time a user boards a bus, the user’s phone will send the location, speed and timing of the bus to the server. The more users using the application, the more accurate it will be with its predictions.

As it’s a design sprint that does not involve bus operators, we decided to look for solutions to get more users on the app.

Wait, but what is a Design Sprint?

Everyone is probably familiar with Design Thinking, a methodology that starts first-and-foremost from the customer perspective. As a newer kid on the block, Design Sprint 2.0 is a four-day process (developed at Google Ventures) for answering critical business questions through design, prototyping, and testing ideas with target users.

Working together in a sprint, team members can shortcut the endless-debate cycle and compress months of time into a single week or more if necessary. In an actual work situation, it would normally take four to five days to complete this sprint but as we’re doing this for a school project, we’ve spread it out into six weeks to further maximize our learning outcomes. Learn more about Design Sprint here.

Our Design Sprint process

Preparation — Process, Team, Tools

The Design Sprint Process 💡

• Pre-Sprint: Researched on MyTransport.sg app, watch AJ&Smart YouTube videos to know all the tips and tricks of each exercise.
• Week 1 (Map): The first week is about making a plan and getting focused. This week’s activities help define critical questions, our long term goal, hear from experts and pick an area that we want to focus on.
• Week 2 (Sketch): Once completed, everyone gets to look for potential solutions online and flex their hand by sketching solutions individually on week 2.
• Week 3 (Decide): During the third week, our team looked at the potential solutions and started a series of voting to decide what we should put on our storyboard.
• Week 4 (Storyboard): With the voted solution, we then prepare a user test flow and carefully crafted a storyboard that will further solidify our idea and prevent further questions.
• Week 5 (Prototype): Our prototyper then creates a mid-fidelity prototype based on our storyboard so we would have something visual and tangible to test with users.
• Week 6 (Test and Post-Sprint): During the final week, we tested our prototype with five different users in one-on-one interviews to gather feedback and take a look at what we have achieved and our possible direction.

Our “Ocean 5” Sprint Team ✨

The following team members took part in the Design Sprint:

• Jeff Li Chen, Facilitator and Host
• Clare Chia, Decision Maker
• Andy Chan, Team Member
• Angela Novita, Team Member
• Lim Lee Kim, Team Member

Our Tools

• Miroboard for all virtual activity boards
• Sketch and Marvelapp for prototyping
• Zoom and Teams for group communication
• Pen and papers for sketching

Using Miroboard to organise our virtual activities.

Now that we’ve outlined the basics of a Design Sprint, let’s go a little deeper on how we actually did it.

Week 1 — Define the Challenge 🤔

We spent the first week studying the product by using the mobile app while we traveled, looking through user reviews on Apple’s AppStore and Google’s Playstore. We discovered that MyTransport.sg is constantly hit with negative reviews about the accuracy of their bus timings.

Based on our research, one of the ways to improve accuracy was crowdsourcing. During this first week, we will be focusing on identifying areas which would have a higher chance of increasing user retention rate.

Step 1: Expert interviews and How-Might-We questions

“Ask the Experts” is a learning activity where a team member gets to interview experts from their chosen subject. As our facilitator, Jeff asked each of team members to describe the product with questions like:

• What is the product?
• What is the problem that the product is trying to solve?
• Who is using it? / who do you like to use it?
• If there were no problem at all, what would the product look like in two years’ time? What would be the ideal situation?

While the experts talked, the rest of the team recorded the “How Might We…” questions using the insights and problems that they have heard.

Turning insights and problems into “How Might We…” questions

“How Might We…” questions were then categorised into common themes in an affinity diagram to make sure everyone on the team is aware of the challenges that MyTransport.sg app is facing.

Common themes of “How Might We…” Questions using Affinity Diagram

We won’t be tackling the entire app for a redesign so the “How Might We…” questions with the highest number of votes were ranked on a voting tree. This allows us to prioritise what’s important currently and worth looking into first.

Placing the top “How Might We” questions on a voting tree

After categorisation and voting, we narrowed down to three most important “How Might We…” questions. Among them were:

• How might we provide the user with a precise journey map with the estimated cost and the shortest duration needed?
• How might we activate voice navigation for drivers on the road like Google Maps/Waze in the future?
• How might we make the app wholesome by integrating Taxi services without turning it into the core functionality among others?

Step 2: Long-term Goal

Defining a long-term goal is a critical component of any Design Sprint. We reserve this time to be optimistic about the product’s future. Using the data on the affinity map, all of us were given five mins to write down our aspirations for the app in two years.

Our aspirations in 2 years

With a vote each, the highest voted two year goal went to:

Our chosen goal in 2 years

Majority of the team agreed to this goal as it pointed out the most important objective of this app, which is to help Singaporeans commute more effectively. Instead of focusing on a niche market like some of the listed goals, we want the app to serve the people. If it becomes a success in our country, we could introduce it to our neighbouring ASEAN countries who are still developing digitally.

Step 3: Sprint Questions

Unlike “How Might We…” questions, Sprint questions are more specific and designed to help identify the obstacles that might stop us from reaching our two years goal. Each of us wrote down two questions within a time-frame of ten minutes which we then voted for the top three questions:

Three Sprint Questions to guide us through the sprint

• Can we create clear and structured systems that all SEA countries can agree upon?
• Can we make the app maintain/fund itself?
• Can we localise the app based on its users?

Step 4: Create the Map

In order to visualise the user flow and see it in a bigger picture, we drew a map with several user groups and important steps: browsing, deciding, following, and reaching the destination. With only one vote, the decider among us picked the Tourist and the process of deciding as the target areas to focus on.

User flow map to visualise interactions

The decider then explained that Tourist by definition, is a person who travels to a place for pleasure. Tourists can include locals or foreigners while the rest are niche market (once again, we need to think global!).

Week 2 — Sketch ✏️

Step 1: Lightning Demos

The goal of this exercise is to generate a pool of ideas and inspiration from other apps that have solved a similar problem. We then use these ideas to influence or combine into our own solutions.

Big Ideas from Lightning Demo session

In under 25 minutes, all of us gathered a wide range of examples from the internet and noted down “The Big Idea” on our board which we then shared our findings with the team. Ideas as follows:

• Klook
  Search by activity/destination. Displays nearby information.
• Singapore Maps
  Ability to download an offline map.
• MOOVIT
  Find shared mobility services, arrival times, timetables & alerts. Cost of the trip, live reminders, live direction, bike routes, and journey planner.
• MyProguide
  A site for tourists to hire local tour guides for sightseeing.
• Citymapper
  Learn everything about your journey. Data collected can help the city and help you.
• Waze
  Search destinations using voice. See traffic updates.

Step 2: 4-Part Sketching

In these four activities, it’s time to flex our fingers with lots of sketching. The first three of them — Note taking, Doodling ideas and Crazy 8s — are warm-up activities that will lead to the Solution sketch in the end. By doing these, we were able to have concrete ideas on what we would like to have in our prototype.

Step-by-step of 4-Part Sketching

#1 — Note-taking (15 mins): Each of us began by jotting down notes and initial ideas individually within a 15 minutes time frame. By using this opportunity to organise our thoughts and look at what we have done so far, we could think about possibilities of where it could go, and reflect on questions that arose as a result.

#2 — Doodling Ideas (20 mins): Now is the time to start visualising those notes into some actual ideas. At this point, there’s still a lot of solution designing to be done, so we start giving each idea an abstract sketch to carry over to the next stage.

#3 — Crazy 8s (8 mins): After briefly sketching out our ideas, we went straight into the rapid iterative sketching process: Crazy 8s. By folding our paper into 8 rectangles and setting a minute-long timer, we only get one minute to design one solution per rectangle until all eight boxes are full. This method allows us to individually generate a lot of ideas quickly and focus on the most succinct point of our idea.

Our Note-taking, Doodling and Crazy 8s (You don’t have to be Picasso to do this!)

#4 — Solution Sketch / 3-Step Concept (45 mins): Time for the main event. The Solution Sketch is the culmination of all the work that has gone into the Sprint until this point. This exercise is also known as the 3-Step Concept, where we tape three A4 papers into a vertical panel. Each panel should have a catchy title and be self-explanatory with annotations on the sides since we won’t have the opportunity to explain our thinking to our team.

Our Solution Sketches (Remember to explain your idea!)

Here are some tips for the 3-Step Concept:

• Keep it anonymous (Don’t worry, you don’t have to vote for your CEO’s sketch)
• Make it self-explanatory (You will not be there to explain it, ok?)
• Ugly is okay (But not too abstract please…)
• Word matters
• Give it a catchy title (Make it memorable)

Week 3 — Vote, Vote, Vote! 🗳️

Heat Map (20mins)

This week is all about the decisions on what to prototype. The first step of choosing the right thing to prototype is the Heat Map exercise, during which we vote on the most interesting sketches prepared the day before.

Each of us spent a few minutes reviewing the individual solutions, taking notes on things we liked about them or questions we had about the solution. By doing these anonymously, it reduces biases as each solution gets an equal voice.

Voting on our Solution Sketches

Using as many red dot stickers as we like, each of us except the Decider, got to vote on features we thought would best help us answer our sprint questions.

Out of all the concepts, one that stood out with the majority of votes was ‘Don’t Say Bojio’, which allows users to discover events nearby. Many of us found it interesting to integrate this aspect into a transport app.

Another interesting concept was ‘Choose A Trail’. This feature allows users to access statistics on their profile page and share the achievements to friends and family.

Note: Bojio means ‘not invited’ in Hokkien, a Chinese dialect in Singapore

Speed Critique (30mins)

With the best ideas emerging from the number of votes, the facilitator starts presenting each idea and addressing all questions under the sketches. This gave us the opportunity to ask questions and get clarification on aspects that may not have been immediately clear.

A good approach for the facilitator at the end of each concept was to ask “Did anyone voted for this concept with an idea or feature that I did not mention?”. During the concept presentation, not all ideas would be covered by the Facilitator and such approach brings all team members on the same page.

Discussion for each concept was then scribed by a team member:

• Find Available Carparks (Voice Controlling)
  Drivers who can’t use their phones while driving can make use of voice control.
• Journey & Cost Ticked (Emphasise on the cost users can save)
  How do users decide which is more important to them, cost or time?
• Choose A Trail (Travel to attractions to earn points)
  Are we able to partner with the Health Promotion Board or EZ-link to convert the distance into incentives?
• Don’t Say Bojio (Explore events nearby)
  Are we able to help small businesses around the area?
• Get Your Guide (Finding local guides for hire)
  Filtering idea can be incorporated into our final concept

Winning Solutions

Straw Poll (20mins)

Everyone (except the Decider) is given three blue dots to vote for their three favourite ideas and do a brief explanation on a sticky note.

Here are our favourite ideas:

• Ability to navigate via voice control for drivers
• Get the cheapest or fastest route to the destination
• Interesting journey facts
• Upcoming nearby events, activities, attractions, and restaurants

Supervotes (20mins)

It’s time for the Decider to decide our fate. The Decider picks the best concept or ideas with six yellow dots and explains why to the team. Here are the chosen ideas and reasons:

• Interesting journey facts
  User retention is key to improving the accuracy of bus timings. By motivating users to look at interesting facts about their journeys, we get to build a relationship between the users and the app.
• Upcoming nearby events, activities, attractions, and restaurants
  Users get to see events that are happening around the area. This can support local businesses as they roll out tours and workshops to tourists.
• Display journey cost
  Users will get an accurate cost of the journey because it’s credible.

Week 4 — Will it flow? 📖

User Test Flow (10mins)

We can almost smell a prototype brewing in the background. But first, we need to work out the flow in which the user begins and ends. During this exercise, each team member creates a 6-Step journey on how the user discovers the feature and ends with an ideal ending.

User Test Flow in six steps

Each team member (except the Decider) then places 1 red dot to vote on the row with the clearest story while the Decider decides on the best journey or actions among them. Here are the selected ideas to prototype:

• Get nearby events with the ability to filter to support local businesses.
• Motivate users to use the app by showing interesting facts about his/her journey.
• Display the accurate cost of travelling.

Here are the six chosen steps in a journey:

1. Discover: Open the app while commuting
2. Filter: Click on Nearby > Find available events
3. Zoom out: The map is zoomed out > See more events
4. Selection: Register for an event > Journey details
5. Follow: Follow the shortest/cheapest route
6. Reach: Arrive at destination

Two additional notifications to motivate users to use the app:

1. Achievement Unlocked: Wow! Your first journey was amazing! Travelled 20% more than users in your age category.
2. Reminder: Set a reminder for an upcoming event.

Storyboard

We are now a step closer to the finish line. The most important task of the week was to create a Storyboard. The idea of a Storyboard is to sketch out a detailed journey so that everyone is aligned on what goes into the prototype.

Storyboard is recommended to be within ten to fifteen frames

Available resources were re-used and placed into the frames while some concepts that did not fit the flow were sketched again. Questions were raised during this process and amendments were made to rectify them. An hour was spent on this exercise to avoid questions being raised during prototyping.

After the discussion, we decided to tweak the current Mytransport.sg interface with five first-level navigation:

• My Stats: Interesting information about your journeys
• BUS/MRT: Check out nearby bus stops and MRT information
• Drive: For the drivers to get notified of traffic news and ERP gantries
• Nearby: Explore events within a short distance around you
• Saved: All bookmarked events/locations will be saved in this folder

The proposed user flow as follows:

• Discover
  User opens the app > Browse what’s nearby > Choose an event
  + With the ability to also search by location or use voice to activate the navigation
• Zoom Out
  To see more events, users can use zoom out gestures
• Select
  User registers for the nearest event
• Follow
  Event details > Purchase Ticket > Get Directions > Choose Cheapest and Shortest Route > ‘GO’
  From here, the user will need to select a route to follow, either by bus or car
• Reach
  User will be notified when he/she arrives
  + Journey stats will be calculated and reflected on My Stats page.

Motivation flow as follows:

• Achievements
  As the user uses the app more often, more fitness-related goals will be achieved and reflected on the app.
• Lock screen notifications
  After a week of traveling, users receive their weekly report on their total distance travelled, total estimated calorie loss, how much carbon emission they reduced and many more.

With these in mind, we decided to end the day and we look forward to begin prototyping!

Week 5 — Prototype 📐

Paper prototype (Low-fidelity)

It is here! The goal of this day is to create a prototype that can validate our solution.

Before creating a digital prototype, one of our team members sketched on papers and it is definitely the easiest and simplest approach to test almost any interaction. While testing the paper prototype, we recorded a list of UI improvements and places where users were most likely to be confused. They were then placed on the Storyboard to the respective frames.

We were aware of the biases when it comes to the placement of UI elements so we try to adapt from a couple of map apps available instead of just Google Maps.

Our paper prototype

Digital prototype (High-fidelity prototype)

At this point, we still had a few decisions to make about roles and responsibilities for the day. The goal here is to make a digital prototype as real as possible so that the user testers would feel like they’re using a real product (or as close to one as possible). With multiple designers on board, we decided to go ahead with assigning roles based on how familiar they are to the tasks needed. Different roles as follows:

• Makers (2 or more)
  Responsible for organising and prioritising the contents of the storyboard.
• Asset Collectors (1 or more)
  Responsible for collection of transport icons and event photos.
• Stitcher (1)
  Put together all assets for the prototype and collaborate them seamlessly.

Digital prototype using Sketch and Marvel App

User recruitment and tasks

Once we are done with our prototype, we set a criteria list for our user participants that fits into our Tourist user flow in week 1:

• 3 Foreigners and 2 Locals (Different perspective)
• Booked for tours/trips from an app in the past year or two.

As our first design sprint, we were only able to provide nothing more than a “Thank you” to our participants. Despite that being the only incentive, we managed to recruit our participants who were familiar with using Google Maps and tour-booking apps like Klook and Expedia.

Why five you may ask? Well, It’s proven that after three tests with a product, you’ll start seeing very similar answers.

In order to ensure a smooth user testing, we created a guide for the interviewers to familiarise with.

Questions to ask participants:

• What kind of work do you do?
• What apps do you find useful when it comes to travelling?
• What mode of transport do you use the most frequently?
• What transportation app are you using currently?
• What do you like/dislike about the app?

Things to ensure them before they start:

• I am testing the prototype, not you. Just relax and do what you think you will do in real life.
• There are no right or wrong answers. You won’t hurt my feelings or flatter me. In fact, frank, candid feedback is the most helpful.
• As we go, please think aloud. Tell me what you’re trying to do and how you think you can do it. If you get confused or don’t understand something, please tell me. If you see things you like, tell me that, too.
• Some buttons won’t work because I am testing only a few features, not the entire product.

Task scenario for them to be in the situation:

As a tourist, you have been touring in Singapore for the past few days. With time to spare for the rest of the day, you sat down at a bus stop thinking about what you should do next. You switched on your phone and started browsing through MyTransport.sg app for nearby events that you could attend to.

User tasks:

1. Select an event that is the closest to you.
2. Purchase a ticket and get directions to the event.
3. Use the cheapest and shortest route to travel to the event.
4. Start your journey tracking to arrive at the destination.
5. You have completed your journey. Check out your stats to see what you had achieved during this trip.

After testing the app:

• What did you like about this product?
• What did you dislike?
• How does this product compare to the one you are using now?
• If you had three magic wishes to improve this product, what would they be?

At the end of the day, we had a fully working prototype and interview guide ready to be tested in the next few days.

Week 6 — User Testing and Results 💻

The goal of the sixth week is to conduct the user testing of the prototype, collect the responses and make decisions on what future lies for this product.

Unlike real user testing where interviewers and note-takers were present, with remote testing, we recorded everything on screen and playback for reference individually.

The team met online again to categorise the responses into the overall concept, user task fulfillment, suggestions and general feedback. We then spent fifteen minutes individually looking out for patterns that showed up with three or more participants.

Most common response (3 responses):

• Interesting concept, Intuitive, Better than before

Next common response (2 responses):

• Would like to see more events/attractions/restaurants
• encourages them to stay on the app a little longer to explore the surroundings and not just for bus tracking.
• navigation is more intuitive as compared to before where more clicks were needed to complete a journey.

Responses from user testing sessions

By indicating if the response is Good, Bad, or Neutral, we were able to know what is the general response of our idea and prototype. (It’s GOOD!)

Ultimately, most of the users interviewed were in favour of our idea. Users said that the new experience…

• is convenient as it allows them to stay in one app for travelling and purchasing of tickets.
• encourages them to stay on the app a little longer to explore the surroundings and not just for bus tracking.
• navigation is more intuitive as compared to before where more clicks were needed to complete a journey.

The team also received several suggestions like:

• Including tourist attractions and restaurants to be on par with Google Maps
• Add exact MRT exits on direction page (which was lacking on Google Maps)
• Work with EZ-link to show card expenses

Now, all that’s left to be done is for the Decider to initiate an action plan for MyTransport.sg based on what we prototyped and the user feedback we collected.

Decider’s Action Plan for MyTransport.sg

• Address the core user experience of the app. Draw inspiration from current experiences like Google Maps and align the flow accordingly.
• The majority of our user testing revealed that they would like to see tourist attractions, user reviews available on the app too. With the available resources on hand, these are features that should be implemented.
• Let’s do more sprints! Have separate sprints, starting with the designers, and then move on to the coding sprint where application architects, data scientists, engineers and product managers will probably need to clarify exactly how the product will be constructed.

Let’s take a step back and ask ourselves…

Did we answer our sprint questions?

Can we create clear and structured systems that all SEA countries can agree upon?

Not conclusive yet. This is the real challenge of this project. In our 2 years goal, we wanted the app to be introduced to the rest of southeast asia, partnering with the local transport authority. This would greatly depend on the success of this app in Singapore and if it’s earning enough to maintain the whole project.

Can the app fund itself?

A tentative, yes. We could look at investments and in-app advertisements, but we will need to closely monitor the maintenance cost of this project and consult the finance department. The majority of our user testings were positive about our product and it is worthwhile to start looking into.

Can we localise the app based on its users?

Yes. Our goal was to introduce this app to foreign markets. We still need to investigate user base in other countries and localise the language and flow of the app.

Were our objectives met?

We started off this sprint wanting to find out what improves user retention and our two years goal gave us a direction into expanding the app internationally. While that is the case, we would say we have accomplished our objectives as we managed to gain valuable insight on how users see would want to see our product in the near future.

What worked/didn’t work about the sprint process?

What worked:

• The prototype was generally received well. The interviewees appreciated the ease of the experience.
• We have a clear opportunity to improve the flow of the user testing by integrating a real map onto the prototype. These changes are straightforward and will have a huge impact on the success of the experience.

Challenges:

• Five days sounds like a lot of time, but it enabled us to focus on solving the issues wholeheartedly and making sure everyone was on the same page.
• A remote design sprint is challenging in its ways. Instead of using pen and papers to work on our brainstorming, many of us had to learn new tools and work around technical issues.
• We find that a thorough research beforehand could save us a lot of time during expert reviews and generating HMW questions. This would be really useful in the next design sprint.

On this note, the Design Sprint is successfully finished! Thank you for reading this loooooong case study!

Sprint Members: Andy, Angela, Clare, Jeff, and Kim