Retrospective (Project 1: “Sho — don’t tell”)

Sho was a navigation app that I created over 4 days and was the first project I undertook as part of GA UXDI 7. 
Creating a Problem Statement:

The first thing I sought to achieve was to get a broad sense of potential problems users faced when travelling.
Executing the User Research — Round 1:
#Methodology) To progress, I decided to conduct user interviews and started by creating a script with questions that can be divided into 4 parts.
1) Questions that prompted the interviewee to recall their travel experiences to better enable them to answer future questions.
2) Questions on what were the problems they encountered on the trip (if any) as well as their relative significance to each other.
3) Questions on how they typically engaged with the problem using both existing digital products as well as offline means (if they chose to make an effort at all).
4) Questions on how they would like the problem to be solved to give me both ideas for future solutions as well as a better understanding of how users perceive the problem and existing solutions. 
I subsequently interviewed 4 interviewees using this script who were cohort colleagues.

Me conducting a long interview with a user. #Improvement, don’t let your users see your analysis!

#Improvements) I realised during the interviews that I needed to ask earlier more questions for section 1. Beyond enabling interviews to better answer questions with more context, it allowed me to better understand their frames of references when answering my questions and to draw general conclusions from their specific experiences. For example, a user initially seemed to have little problems with getting lost in her recent trip until I realised she was largely visiting only one place (because of training), she has been to the location often before and she did not bring along parents. Her problems became more similar to other users when she was made to recall another trip. Who, What, When, Why, Where and How became more mandatory questions for the first section after that.
I used an online software called ( to consolidate responses and did affinity mapping in order to build a narrative of the problems people faced on the trip and how their severity varied across user demographics and trip circumstances.

Part of my affinity map. I need this because my handwriting is messy and my notes are many.

The key insights yielded from affinity mapping was that;
1) The biggest and the most widespread problem amongst the users interviewed when travelling overseas was through unnecessary loss of time. 
2) Getting lost was the main way in which time was lost.
3) The solution most users used for navigation was Google Maps
4) Google maps was inadequate. 
Before I went to the next stage, I wanted to ensure that the problems of my users were representative of their target demographic. #Methodology) I thus created a 1 minute interview (the equivalent of an in-your-face-please-complete-now survey) to validate my problem statement. I asked only 3 questions to 7 people.

Can you recall the last time you travelled for leisure with your family / couple without a local guide where the bulk of the time was in a city.
 2) Was navigation a problem? 
 3) Did google maps help?
Surprisingly, 6 out of 7 of my interviewees told me that navigation was not a problem and that google maps was adequate. However, I did validate that the solution most users used for navigation was Google Maps.

Me conducting a short interview with a user. #Improvement, don’t observe your users too closely; it might scare them.

Executing the User Research — Round 2:

Under such circumstances more user research needed to be done. #Methodology) I decided to repeat the exploratory interviews in order to 
 1) Understand why navigation was not an issue to people.
 2) Whether navigation was the most important issue people faced while travelling.
 3) Understand how google maps could be potentially improved.
 In particular to achieve point 3, I decided to create a minimal viable demonstration of value of what I felt could be of value to users after the 4 initial interviews. The creation of visual images was useful to users because;
1) Users got lost because they were unable to determine their location or orientate their direction as easily overseas because of limited wireless and GPS access. Having a visual image of directions is a more intuitive way of communicating what to look out for.
2) Users also had problems navigating when they could not ask questions from non-English speaking locals. Having a visual image of checkpoints and where to go could communicate information despite language barriers or the presence of helpful locals.

#Methodology) To validate this, for the final questions of section 4 of my exploratory interview, I decided to ask users if they found an app that provided all the features of google maps as well as the additional visual cue that told them how to orientate their direction when their journey required them to make a change in direction at a crossroads or split in paths. I made a short wireframe to communicate to interviewees what I intended to do.

The visuals I used as part of the minimal viable value experiment.

The findings in response to the above questions were as follows.
1) When navigation was not an issue for users when they had extenuating circumstances (e.g. a user did not have a local guide showing her around, but she had a non-local boyfriend that was locally based who could speak the language / have data and thus had the same effect. #Improvement I resolved to be more careful in the contextualisation and to ask the “why”. even for the short-interviews, in subsequent user interviews.
2) No one had more significant problems besides navigation.
3) All users found google maps with visual cues valuable. 
#Methodology) Moving forward, I created another set of 1 minute interview questions to ensure that the value which I propositioned was relevant to users and that I had a good understanding of the circumstances and the user demographics that will benefit the most for it when navigating. I thus asked the following questions to 5 people:
1) Imagine that you are travelling overseas for leisure to a country where you can’t speak the language, don’t have wireless access or have anyone familiar with the area showing you around on a regular basis. You travel mainly by walking or public transport and might even have family tagging along. Have you been in such a situation? How?
2) Do you have difficulty finding your way around? Why?
3) Do you typically use google maps?
4) Would you find the following app helpful?
This largely validated what I had discovered earlier. Additionally, after adding the results to the affinity map, I realised I could additionally deliver value by introducing a social component to the app. Users often used more detailed guides, with those visual cues that we wished to introduced, that were created by locally based friends, bloggers and Airbnb hosts. #Glow Overall, I felt that I effectively managed to dig beneath the different user statements and the frames of references in which they made them to isolate their problems and what they perceive as value to execute the app. 
 Problem Statement
I could thus conclude my problem statement for the app to be as follows: 
“The biggest problems users travelling overseas face is getting lost when navigating on foot. The most currently used solution google maps in inadequate because it’s purely textual directions are not always intuitive to understand.”
Sketching, User Flow and Prototyping.

My user flow. A stand-in before I used Axure.

I first scoped out what the app needed to do in order to work backwards to create both the user flow and the sketches. I identified that an app needed to 
1) Provide visual information to the guide from A to B
2) Allows the creation, edition and saving of multiple routes in a single file.
3) Allow the routes to be shared via email and social media platforms.
Firstly, I created a user flow to identify what were the key areas that an app needed to have on a macro level to execute those functions.
Secondly, with this broad picture in mind, I decided to recreate the user flow on paper but adding additional details to each page on what were the features required as well as potentially where they can be located. This was done by executing the above tasks and sketching out the screens that were required to perform them. 
Thirdly, having executed the tasks, I looked through popular apps such as google maps and drop-box to learn about their navigation options as well as features to ensure I haven’t missed out anything in my app. 
Finally, having done multiple basic sketches on a single page, I updated my user flow and proceeded to create the graphics of the app via powerpoint for prototyping. 
The prototyping software I subsequently used was InVision which was easy to master. Subsequently, I concluded the project with a presentation of the app which you can find here.

Final evaluations

Tom-Tom Visual example:

Overall, informal feedback of the completed mobile app after the presentation was positive. I was additionally introduced by the audience to other apps less famous than google maps that have taken the same approach as me, such as the travel app TomTom. As a first attempt at a mobile app, I am happy. However, there is much to learn from a first attempt.

Key Learnings

1. I needed to be careful on how I validated “minimal viable value” without creating a prototype. It was an effective way of quickly focusing research efforts but it ran the risk of creating biasness from the researcher, who was cognitively and possibly emotionally invested at an early stage to enact a certain solution, and the user, who are being asked potentially leading questions. 
A. These should only be used after at least the first round of exploratory interviews are used.
B. I shouldn’t have asked users directly what were their thoughts on this app. I should have instead showed them a sketch on an improved screen and ask what they felt about it. 
C. If possible, multiple value propositions should be simultaneous shown to ensure that one solution is not prioritised over the others and thus shutting them out.

2. The process in which I sketched and did the user flow of the app was relatively haphazard. The result was that certain features were missing, most prominently a way in which a user could sign in so that the app knew from whose social media account they were sending and receiving data from. 
A. Before jumping straight into drawing the user flow, I will try and visualise it and write down in purely text form. 
B. Beyond app features, I should do a checklist of basic features that are usually found in apps no matter what the task. (Such as settings, member login, search bars) to ensure that I do not missed them out and that they are given a certain place in every page. 
3. I wish I conducted a usability test. When executing the presentation and needing to transition quickly between some slides, I realised a home page button on all slides would have been very handy.
Same as 2B, ensure accessible navigation. 
4. The use of I-statements can be used to better organise information in the affinity map. 
 Do it next time.