3 days to create a way finder mobile app

Tl;dr Travelling overseas on free and easy trips can be daunting, especially if you miss a train that runs 2–3 hourly. BringMeThere brings tourists from anywhere they are within the station to the correct platform for train boarding in the shortest possible time. 22 out of 26 audience during the pitch session looked forward to using this app in future.
Assumption: Google beacons or iBeacon technology is cheap and widely used and allows for this app to work

Project before and after: http://goo.gl/UIR7jX

Project demo video:

Project brief: Define a problem that could be solved with the design of a simple mobile app.

Project focus: User Research, Affinity Mapping, Problems identification, Storyboarding, Creating user flow, Sketching, Prototyping, User Testing, Iteration, Product Pitch

Topic selected: Travel

Design Process

Source: http://www.effectiveui.com/blog/wp-content/uploads/2014/10/Blog-Graphic.003.jpg

I will be explaining how I derived at my solution using the ux design process diagram above from this point onwards.

Empathise (with the users)


Purpose: Because travel is a broad topic, it was important to formulate hypotheses based on our own past experiences, which are proven or disproven through user research. I always had problems planning an itinerary for trips and decided to explore this pain point to see if other people also face the same problem.

My hypothesis: “I find planning a trip difficult”

Define (a problem)

Creating effective user interview questions

Purpose: I devised a list of non-exhaustive "open-ended" questions in order to understand user behaviours and thought processes.

Process: In order to identify my intended target users before I interviewed them proper, I employed the use of two screening questions:

1. Have you travelled out of Singapore before?
2. Have you personally planned your own itinerary for a trip before?

These two questions would ensure a good user fit before I proceed to delve deeper into my interview.

Following that, I formulated a list of questions based on three broad categories, all of which were based on understanding users' past experiences. These serve as the actual user interview questions.

1. How did users go about planning their itineraries for their previous trips?
2. How closely did they follow their itineraries throughout their trip?
3. What do they think could have helped them plan their itineraries better based on past experiences?

Findings / Learning points:

  1. Questions should be formulated based on past events, in order to understand ingrained behaviours and habits of the users. We want to solve an existing problem that users face, not one that the users imagine they may face in future.

Conducting user interviews

Purpose: A total of 5 users were interviewed for this project in order to gain insights into the common pain points faced by them.

User Interviews: (From left) William, Zhenzhi, Shuk
User Interviews: (From left) Megan, Sneha


Voice recordings and transcripts were used to document the interview process after permission has been granted by the users.

The interview questions which I have formulated earlier were only used to guide the interview process. I listened carefully to what the users are sharing, in a non-judgemental way, and formulated following up questions accordingly in order to understand their actual pain points better.

Findings / Learning points:

  1. Because of the broad nature of the topic, it is important to focus on gathering as much information as possible from the first user, bearing in mind that the patterns in the pain points would only surface after two to three user interviews.
  2. Allow yourself the chance to re-interview your users again by informing them that the interview is not final and that you may contact them again for help should the need arise.
  3. The set of interview questions devised earlier serves only as a guide. A UX researcher should not limit himself to asking only those questions but rather play by ear and ask appropriate questions to delve deeper into the problems or clarify any doubts.
  4. User interviews often do not follow a nice flow. Users may share stories that highlight other problems which may be interesting for us to delve deeper into.
  5. The “Why?” questions are always asked to clarify the researcher’s doubts and to guide users into revealing the actual problems behind the stories that they share, which the researcher can formulate solutions for later on.
  6. One question is asked at any one time to the users, in order not to overwhelm them. This is to minimise any discomfort during the interview process, which may lead to untruthful answers being shared so that users can quickly finish the interview session with you.
  7. If no patterns surface after the first three interviews, the researcher will need to relook at his questions to see if he needs to reformulate from a different point of view or from a different area of focus altogether.
  8. Voice recordings and transcripts were used to document the interview process after permission has been granted by the users. It is important to document every stage of the UX design process. These documentations serve as great proof to clients that effort was put into the research process. Quotes from what users say are also impactful when they are used to convince clients.

Affinity Mapping

Purpose: Affinity mapping was used to organise issues faced by each individual user into categories from which problem statements can be formulated.


  1. Each user was assigned to one post-it colour.
  2. One issue that one user faced was written on one post-it.
  3. After which, the post-its are pasted, one at a time, in random places on the wall.
  4. Post-its that highlight the same issue are placed in close proximity while those that are unique are placed at a different location.
  5. This process is repeated until all the post-its are organised.
  6. Check that each category has more than 3 and less than 10 post-its.
  7. A unique problem statement is written from the users’ point of view and serves as the name for each group of post-its.
  8. Each category reveals a common problem encountered by unique individuals that are similar in nature, which the UX researcher can solve.
One problem statement was written on one Post-it
Affinity mapping: Post-its were pasted in random. Post-its with similar issues were grouped together.
Initial mapping: More than 10 Post-its in each category
Final mapping: 8 specific problem statements after re-categorising and removing repeated issues from same user

Findings / Learning points:

The problem statement I chose to solve was “I get lost in train stations”.

I selected this problem statement because it surfaced from three different interviewees and was a common problem regardless of the different countries they have visited.

“I got lost in the train station in Japan!” — Shuk

“Confusing rail system in UK, made worse without direction to get to the actual train” — William

“In US, there are no proper directions to the platforms” — Sneha

It is not difficult to understand why. A simple Google search reveals the number of entry points and exits a station in large cities have. This situation is made worse at interchanges. Let’s draw a simple comparison between the Outram Park interchange in Singapore and Shinjuku interchange in Tokyo, Japan.

Comparison between Outram Park (Singapore) and Shinjuku (Japan) train stations

There are apps like Google maps, which allow travellers to find their way from one point to another outside of the station but there are no apps currently that help travellers navigate within the train stations themselves. I wanted to design an app that can solve this problem.

I envisioned the number of travellers I would be able to help with this app and the feasibility of pushing this out into the App Store, driving profit.

Ideate (for a solution)


Purpose: A storyboard allows the researcher to understand the activities that the users go through at a higher level, allowing them to empathise with the user. This allows them to come out with solutions based on the users' experience.

Process: I began with the sketch of a simple storyboard. There are no restrictions on the number of boxes required in the storyboard comic, as long as the users viewing it can empathise with it.

Initial Storyboard
Improved Storyboard

User flow

Purpose: A user flow shows the steps users take to complete a task.

Process: I envisioned the steps required to call out a certain function before sketching out the workflow using wire floats. Once this was done, I ran through the user flow with three users to see if they understood it.

Feedback given by my users were extremely valuable. For example, Derrick pointed out that I was trying to solve three problems with one app (which I did not realise).

Saleh pointed out a flaw in my user flow which tried to bring users to their desired exit at the train station. This was not feasible because as a user, they would want the app to tell them which exit to go to depending on their destination because they would not know which exit they are required to head towards in the first place.

Because of the valuable input by the users, I focused on the primary flow of bringing users to their desired platform and removed all the other flows.

This allowed me to focus on solving one problem at hand, eliminating unnecessary steps in the user flow, and reducing the number of steps required for users to complete their task.

User Flow Version 1
User Flow Version 2
Final User Flow

Findings / Learning points:

As I was drawing my user flow, I realised that I tended to miss important steps along the way. A better way to do this next time is to list the steps first so that I can look at them and modify them before translating these steps into a workflow for visual representation.

Prototyping, User Testing and Iteration

Purpose: Build a minimal viable product.

Process: I translated the user flow into a sketched prototype. I started off with the design of the homepage.

The focus of my app is to lessen the distress that users face when finding directions in the train stations. Because of this, I removed the painful login process, jumping straight into its function. I came out with a total of five designs, drawing inspirations from current transport apps.

5 different homepage. (From top left: 1, 2. From bottom left: 3, 4, 5). Design 1 was preferred by users.

Before conducting user testing, I explained what exactly I wanted my app to solve and clarified any doubt the users had. I interviewed a total of three person. If time permitted, I would love to conduct more user testing for a larger sample size that is more representative of the population. During the user testing phase, I asked them which login screen they preferred and why, before narrowing down to a single design.

Findings / Learning points:

Users generally loved the first login screen because it has the least buttons to click in order to solve the single problem they faced. The other interfaces had multiple buttons to solve multiple problems. They wanted to see the steps to get to the correct platform immediately after the first page rather than pressing more buttons.

I then went on to perform further user testing with three other individuals to validate the product.

The red markings show the feedback I got from user testing. For example, Annusia pointed out that the swipe direction was opposite to what is used commonly. Also, there was no need for a dropdown bar to let users select the direction in which the train goes towards. Just have two buttons for them to tap on, reducing the number of steps from two to one. These were included in subsequent sketches as I iterated the design further.

Drop-down selection bars replaced by buttons

I repeated the iteration process until users found it intuitive to use.

App Layout sketches

Once every page of the app interface is confirmed, I translated the drawn prototype into a working prototype using the InVision software. The access link can be found here: https://invis.io/KM7IF8H9U

The product was successful in solving two problems.

  1. Less time spent navigating through train stations
  2. Removed language barrier

It is important to note that InVision has its own limitations.

  1. It does not accept other file formats other than jpeg.
  2. It does not accept high quality pictures. I used an iPhone 6S and I could not upload my photos. One way to work around this might be to resize or compress it (which I have not learn how to at the point of the project)
  3. InVision does not arrange your photos in order unless you name them in order. I uploaded the photos one by one as I worked through the flow to avoid confusion.

Product pitch

In order to simulate real life work, we were tasked to present our ideas and prototypes in no more than 5 minutes to an audience. I imagined my audience to be representatives from my clients and kept this in mind while designing my slide contents.

I spent two days of in class, and after class hours, to come out with my slides using Keynote. I wanted the audience to focus on my content then my slide design and hence went with a simple white background and black wordings. I ignored the number of slides but focused instead on bringing my point across with each slide. I included pictures and less words per slides because I did not want my audience to be reading my slides when I am elaborating on my ideas.

For the content, I did some background research into the different train systems in large cities like UK, Taiwan, China and Japan. I looked for statistics to show my slides because proven data helps to convince people. However, I took care in only presenting only a maximum of three important numbers in one slide for comparison because I did not want to overwhelm my audience. I included relevant quotes from my users, pictures of my work and any other details which I can use to convince my audience.

I did not care about the organisation of my contents first. I focused on the relevance of the content instead. I only organised my slides when I was satisfied with the contents. As much as possible, I tried to have one idea on one slide. I then went on to rehearse for my presentation, ignoring the time limit for the moment. Rehearsing helped me to re-organise my ideas. the transition from one idea to another became smoother with each rehearsal until eventually, the presentation just flowed smoothly with the pictures or words serving as prompts for further explanation.

Only when I got the flow right did I try to rehearse according to the stipulated time. It was better to have more content to work with than lesser. It was easier to summarise and remove details than to come out with contents from nothing. I scrutinised every slide and removed those that were less significant in making an impact. I timed myself as I went through all the slides and tried to take note of the volume and speed as I recited my ideas. I also found it extremely important to have the InVision app ready and set to the first page before each rehearsal so that it becomes a habit on the actual day. Knowing when to click, and where to click is important in a presentation because it helps to keep the tempo up and avoids breaking the flow that the audience and you have. These processes were repeated until I was able to complete the presentation in less than five minutes, allowing me some buffer time should there be technical difficulties on presentation day.

I realised that although I felt confident with the flow the night before the presentation, rehearsing it again in the morning of the presentation helped. I remembered that I passed the five minutes mark the first time I rehearsed that morning because I have forgotten how the slides were organised, the flow from the slides to the InVision app and the speed I spoke at. The rehearsal that morning helped me to familiarise with the presentation again. I am glad that the presentation went smoothly and I ended before the five minutes mark.

However, I have to constantly remind myself of my speed next time because I have received feedback that I spoke too fast. This was because of my nervousness which I tried really hard to suppress and should not be an excuse in future.

You can access my presentation slides here: https://drive.google.com/open?id=0B3OKjkHIl_XTc1U1VFpOc0dhaE0

Lessons learnt

I have learnt the importance of user research in any product development through this project. User research should always come before prototyping and product development. The importance of this step cannot be compromised because problems that are not solved in this stage tends to snowball into a bigger problem down the design process, resulting in wasted time, resources and costs.

I need to work on organising my thoughts into sketches, be it user flows or app interfaces and this can only get better as I practise.

While we had about four days to prepare for the presentation, a lot of backend work goes into a five minute presentation. Every single minute to work on the project was important in order to gather enough data to show on the presentation slides. The best way forward is to be consistent in working on the project on the days leading towards the presentation and not wait to rush through it at the last minute. This is important because we would be working on not one but all the pain points which bother users next time in our job, which means there are going to be many sketches and iterations that need to be done to perfect the app even before development takes place.

It is easy to feel complacent after a successful pitch. Writing a retrospective document helps to highlight the lessons that can be learnt for improvement the next time round for you and other user experience designers. It helps in consolidate learning points and promotes thinking.

Because UX is such a new thing in Singapore, reading widely on books related to UX helps. It is important to constantly remind ourselves to have a growth mindset, to read and to be hungry for improvements. The only driving force for success is ourselves.

I want to push this product out in future when technology catches up. I'm not sure how feasible it is but patenting the idea now might seem like a good step to do next.

Lastly, I realised the importance of having an experienced mentor (like Zhenzhi) and this is definitely something which I will look out for in my future employment. A mentor who is willing to teach the ropes and critic on your work at each stage, can tremendously improve your confidence in applying what you have learnt and also learn fast from your mistakes.

Like what you read? Give Eugene Low a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.