Retrospective Recap: Week & Project 1

It’s now Sunday and my UXDI classmates and I have officially wrapped up our first week of class and about to crash into the second week of the tip of the iceberg that is UX (just kidding, maybe). We also have completed our first project on rapid prototyping and thus it is time for some reflections.

Overview of methods:

  • Research phase: Concept mapping, 1:1 interviews
  • Design phase: User flows, Wire flows, Interface sketches
  • Prototyping and testing phase: Rapid prototyping with Invision app

Discovery + Conducting User Research

Why is user research important? Because I am not the user.

It’s easy to assume that everybody is like you. However, this leads to a strong bias and often ends in an inefficient design.

I chose the category on Travel because I could almost immediately think of a hundred things I would like to improve when it came to my travel experiences. So much so that I might have had an “analysis paralysis”. UX however, teaches you to slow it down and ask questions before settling on any assumption, solution or even identifying the problem itself! I decided to narrow down my focus to transport within Singapore to sift through the myriad of ideas that were forming in my mind. I could not let my own habits influence the design decisions regarding the app.

I set out to interview 3 of my classmates with high hopes. I intended to start with high level user research in the form of concept maps. I sat together with my first interviewee and I asked her broad open questions about her life and habits in regards to transport. I used a variation of the following coupled with some other general questions.

1. How many times have you looked up directions in the last month?

2. How many times have you taken public transport (bus and train) in the last month?

3. How many times have you taken taxis in the last month?

4. What do you normally use to look up this information?

5. Do you have a monthly travel budget?

6. When do you normally use an app to check directions?

7. Is it something you would prefer to be automatic? (It automatically would pop up on your phone)

8. Do you use any social media/ to coordinate travel and meeting plans with people?

9. How many times have you been late to meetings due to unplanned events?

I followed the same process with other classmates and quickly came to the realization that getting information out of these people is not going to be easy.

How was I supposed to probe past the surface when majority of my users were not able to identify their patterns with some ounce of certainty? I had to step back and question why I was getting these mixed messages from the users.

I went back and reviewed all my interview notes and audios and I noticed the following:

1. Asking users to talk about their spending habits is a bad idea. People generally have a consistency bias in regards to this and do not like to reveal the extent of their problems as they do not even feel that they are even problems in the first place.

2. Users also downplay their habits if they put them in a “negative” light. I could only see this later when I analyzed my notes and noticed my prodding had resulted in activating a self-defense mechanism in my users.

3. I should have spent more time evaluating my interviews after carrying out each one and refining my questions further to overcome the following biases that I noticed.

Additionally, when I set out to profile the users that I had just interviewed, I noticed that they were from similar demographics and so I set out to interview a different age group to see how my research varied.

This definitely helped improved my understanding of the results at hand. The people I had been interviewing had been working for a while and hence had become less price sensitive to travel costs. When I started interviewing User 4–5, majority of whom were current students (between the ages of 15–25), my initial thoughts on what could be pain points were confirmed. Using the information from the new set of users, I had synthesized my research into the following categories through an affinity diagram, which helped me determine my problem statement and user goal to help me, hone in and focus on my design decisions.


Users will benefit from having an application that helps them manage their travel expenses while also working as a navigational tool so that they do not need to use different applications to input the same data. Working together hand-in-hand, allowing them to

1. See: Unused travel budget $ in real time

2. Track & Alert: Track monthly spending and get notified when $ is running out. Alert them when they are not at their destination and reminding them that the longer they take to leave their current location, the cost of the transport to reach there at the estimated time will rise.

3. Predict: Provide a realistic budget based on historic spending and habit

4. Use: The navigational tool to estimate how much they would be spending on travel based on predetermined travel locations, predicted time of departure and GPS locations.

All these functionalities will then allow them to better manage their time and resources which in turn should help them be more punctual for meetings and pre-planned events.

User Flows and Sketching

Day 3 was all about putting the ideas in our heads onto paper. I started by drawing out a user flow my notebook to get a sense of how many screens I’d need to draw and what I wanted on each screen. I’m partial to using online tools because I tend to get ideas while I find ways to organize my screen. Low-fi tools such as Balsamiq and Lucid Charts are my preference. However, I still drew rough sketches to help the creative juices flowing.

Rough sketches of what my prototype would look like
First iteration of the user flow

Above you can see my rough user flow. It helped me organize my thoughts and feel ready to start sketching. I decided that showing the user journey of creating an event would show how I’m helping my users track their expenses using the statistics section of the application.

In addition, through conversations around the user flow, I identified areas of interest that, though related to the problem, were not priorities for the initial prototypes (such as how to automatically track the users activities and ask them for confirmation on the mode of transport used to travel) but that could perhaps be areas to explore in future versions.

Rapid Prototyping

My prototypes were kept consistent with common navigational tools such as Google Maps and Waze as I didn’t want to stray my design to be something that would require special onboarding.

During the past week, things flew by so fast and some of the tasks that we set out to do started being more and more daunting as the presentation rolled around. I was not able to finish the usability testing portion of the UX and iterate, iterate, iterate. I need to really up my time-management skills for the next project to address this.

Here are a few features and updates I’d like to make if I had the luxury of time:

  • Demonstrate how the app will learn from the user’s preferences
  • Potentially feature to add in Grab, Uber and other taxi applications to better estimate the cost of taking private transport
  • Build out the search section in further detail
  • Show the on-boarding process and how a user will link to expense tracking accounts

Due to time-constraints, I was not able to go into developing a sketch or a prototype for the ‘Alert’ feature which would let users know when they were going to be late and how their travel cost would increase as they would have to now take a different transport method to reach to their destination on time and it’s availability.


  • This project made me think a lot about different fidelity levels. I got really comfortable knocking out quick pencil sketches, but I wouldn’t want to show them to anyone other than the person next to me.
  • One of things I did not invest time in was a storyboard due to my preconceived notion that I cannot draw. This was a huge drawback as the presentations rolled around because I saw how cohesive everyone’s presentation was with their problem and solution statement if they had used a storyboard to communicate the scenarios they were trying to address.
  • Wireframes are great for helping get my ideas in order, but even at that stage I want to test them out with real text — no point in making a pretty layout if it won’t be able to fit the kind of content that needs to go in there.
  • Understanding users is hard. Being from a sales background, I tend to think more like the customer rather than the end-user. This shift in thinking from customer to user experience has been a hard one to make because they do not always align in the same ways. I will have to just keep making a conscious effort in changing my perspective.