Brief: AJ is a 26 year old travelling salesman working for Bloom industries. His life revolves around his meeting schedule. He lives in NYC and commutes to multiple sales opportunities on a daily basis primarily using public transport. Given the nature of public transport, he frequently misses trains and buses due to a number of factors. These including overcrowding, weather conditions, road/rail congestion and other general delays.
TL;DR What follows is an in-depth explanation of my process. At the very end are the mock ups, prototype and a photo recap of the process.
The Brief: Understanding the problem space
I started by analyzing the provided brief and pulling out key information, including; the (*initial) problem statement, deliverables, constraints and assumptions. *I will revisit the problem statement later on in the process.
Problem Statement (Initial)
Public Transportation is unpredictable, making it difficult for users to confidently plan and meet commitments.
Design an app to help users efficiently coordinate their use of public transport
Assumed access to
- Repo of public transport & systems data
- Public transport APIs
- Embedded Mapping Software
- Machine learning technology
- Device: Mobile
- Type: App
- iOS or Android?
Deconstruction & Discovery
The goal here was to deconstruct the stated problem/goal and add context to the users behaviors to better understand the problem space.
Facts: AJ Smith, 26 year old traveling salesman living in NYC. who uses public transportation to travel to meetings.
Context & Behaviors
- Users have multiple meetings per day, meaning they use public transport multiple times daily.
- Based on the information provided about AJ and the nature of sales/pitching, I am making an assumption that the meeting locations and times are generally inconsistent.
- The eventual solution may also solve similar problems for users that have set travel times and locations, but I will focus on the former use case.
- Multiple modes of transportation exist. With the information provided, I am making an assumption about the frequency of use, weighted more heavily on price
- $ Trains (Subway) / $ Buses: Frequent
- $$$ Taxi, Uber, Lyft: Infrequent
- $$ Carpool, Lyft Line, Uber Pool: Infrequent
Pain Points & Themes
- Public transport is unreliable and unpredictable, which causes users to frequently miss trains/busses due to a range of factors including; General Delays, Road/Rail Congestion, Overcrowding, Weather Conditions.
- Showing up late or missing meetings due to the unpredictable nature of public transportation causes users to lose sales (or clients).
- The high cost of living in a major city makes the user's quality of life dependent on accurately coordinating public transport and staying informed of delays to plan ahead
- Needs: Control, visibility, confidence, peace of mind *Will expand on needs and motivations in the following sections
User Flow (Current)
I began whiteboarding the basic user flow and fleshed out some details as I went.
Assumptions: The user flow outlined assumes the user decides to take public transportation
What this doesn't cover: User checks schedule and there are no available public transport options that will get him to a meeting on time, forcing user to find alternate mode of transport.
Out of scope: Bus/train overcrowded. To focus on the main use case, we'll look at solving the problem for overcrowded busses/trains as a nice to have or a future feature.
Applying the Jobs-to-be-Done (JTBD) Framework
I chose to use the Jobs-to-be-Done framework to work through this challenge to ensure that the process followed UCD/HCD principles and that the solution(s) and features respond to actual user needs and motivations.
To begin, I used the above information (persona, problem statement, etc) to translate the user's needs and goals into a job story. Using job stories to redefine the problem helps refocus the problem on user's motivations and needs, while remaining solution agnostic.
Creating the Job Story
- When Aj is unsure if his bus/train will arrive on time and is worried that he may be late to a meeting, risking the loss of a sale or client (Situation)
- He wants to reduce the anxiety and increase confidence in predicting public transport (Motivation)
- So he can efficiently coordinate his use of public transport around his meeting schedule (Outcome)
- When _______ (Situation)
- S/he wants to _______ (Motivation)
- So s/he can _______ (Outcome)
We can abstract the motivation portion of the Jobs Story and add context by identifying forces. By identifying forces, we can focus on increasing the forces that may help pull a user to our product. I'll revisit these forces during ideation.
Motivation: Reduce the anxiety and increase confidence in predicting public transport
- Force: I'm anxious that the bus/train may be late > Opportunity: Quickly alert users when the bus/train is, or may be, delayed
- Force: I'm unsure if another bus/train is coming > Opportunity: Reassure users when another bus/train is coming, or allow them to easily figure out an alternate method of transportation
A user's job has different types of components (main, functional, emotional) and requirements which help add context to create meaningful solutions.
- Main Job: Arrive on time to multiple meetings, daily
- Functional Job: Accurately & efficiently coordinate public transport
- Emotional Jobs: Emotional jobs are broken down further into;
- Personal: Coordinate public transport in a way that leaves users in control and informed
- Social: Allowing users to meet commitments and maintain rapport with clients and collegues
Simplified Job Statement: Arrive on time to client meetings via public transportation
Define Consideration Set (Competitors)
- Taxi, Uber, Lyft (Rideshare Apps)
- Carpool, Lyft Line, Uber Pool (Rideshare)
- Video conferencing or phone calls
- Leaving for the station very early
- Google Search: Location Info
- MTA.info, MTA TripPlanner, MTA Bus Time, Transit Time NYC (Web)
- Google Maps, MapsTripGo, CityMapper & Similar (Travel Apps)
- Paper Schedules, Maps (Physical)
Opportunities for Innovation
There are plenty of solutions that do the job of helping users plan general travel routes. However, after exploring other services in the consideration set, it became clear that the majority of trip planning and travel apps optimize, first, for the user to input put the destination, and in some cases, requiring the user to know what the name of the destination station will be (this can add an extra step of locating the nearest station to a destination).
Since we will be focussing on designing a solution for users to arrive on time to meetings via public transportation and we have access to the users meeting schedule, there's an opportunity for innovation in terms of automating the destination input and reducing the cognitive overhead of figuring out the nearest stations to the destination. The majority of public transport and travel apps that I analyzed placed a heavy emphasis on trip planning - which is something that we can alleviate.
Another opportunity that I realized while going through the user flow was the return trip (or next trip). We can assume a smart default to automate a return trip could be (1) the users home address, if stored or (2) the origin location. If a user has another meeting scheduled, we can assume a smart default to direct the user to the next known destination. Based on the heuristics of error prevention and user control & freedom, the user should confirm the default or enter new information.
- Users may decide to use a solution from the consideration set based on a number of factors
- Access to native apps that work when they need to get somewhere
- Users frequently travel via public transport on similar routes daily (standard commute)
- Users realize a need to travel somewhere relatively close by and choose Lyft, Uber or similar. Less price sensitive.
- Users realize a need to travel somewhere, unscheduled, and begin by performing a search (google, etc)
- Users may decide to use a new solution based on the following criteria
- Cost effective, efficient, easy to use, transparent, decrease errors (unforeseen delays), minimize wait time, automation and decrease of user input
- Automating the coordination of travel to multiple destinations
Keeping the outcome statements solution-neutral, these are based on user's motivations and needs. I will use these as a guide when working through the initial solution sketches and ideation.
- Decrease amount of user input by automating destination info via syncing calendar events
- Increase transparency to stay ahead of delays by keeping users informed of transportation status via notifications and alerts
- Increase ability to recover from errors (delays), by providing flexible route options
- Increase confidence of navigation to my final destination after arriving at intended bus/train stop, in order to complete the journey
- Increase efficiency of coordinating transportation, so users spend less time scheduling and more time working
- Increase relevance of transportation routes based on travel time, price and available transport methods using machine learning
I used the outcome statements and task list to pull out more granular tasks and functionalities. Using the outcome statements and job statement (arrive on time to meetings via public transport) as a guide, I created a (rough) affinity map and grouped similar or related tasks.
Ideas that did not directly support the primary use case or job statement were pulled to the side to possibly revisit in the future.
By the end of the JTBD and UX discovery, I had a hand full of How Might We's (HMW) and outstanding questions.
- HMW handle the lack of cell service when underground or in stations with poor service?
- HMW support the addition of last minute meetings?
- HMW enable users to easily return home or travel to the next meeting after an event is complete?
- HMW use the data to smart default for the return trip?
- HMW enable manual creation of events?
- (+added: HMW treat empty states, or zero data, when users have not connected their calendar?)
- Unknown: iOS or Android?
Exploring these themes and questions will help me stay laser-focussed on the primary use case and job statement, but also know where provide enough flexibility to users.
From outlining the task list, or key interactions, I noted steps such as; install, setting notification preferences, location services, etc, so while whiteboarding the initial user flow, I focussed on the main areas of the app (default view, schedule, trip flow). I also started to explore different ways to handle the return trip or navigating to the next scheduled event location.
After whiteboarding, I switched to pencil and paper to work through the flow a bit more and note any holes or missing info.
I focussed on a schedule view, how a user enters into the 'trip flow,' and the initial setup/onboarding screens. Since one of the assumptions is that we already have access to the users calendar, I didn't spend too much time on the details there.
Below is the rough flow for new users, existing logged out users and existing logged in users.
As I thought more about the calendar view, I realized that is does not directly support the job statement (arrive on time to meetings via public transport) so I noted this as a nice to have. The view made sense as far as adding events to the schedule, but this could also be accomplished without that view (possibly with an icon on the default view or the app header, etc..)
I refocussed on the primary schedule view > trip flow and explored different ways of entering choosing or starting a trip.
Following the pencil sketches, I moved into sketch to start wireframing and working through the rough UI, as much gets worked out in the UI.
Let's Get Digital
I started getting the basic components down in sketch and putting it all together. I based the ui on iOS guidelines that would be able to translate to android fairly easily.
Once I started increasing the fidelity of the mocks, I put together a prototype to test the interactions and user flow. For the most part, the flow seemed to work to accomplish the goal of enabling users to arrive on time for client meetings via public transportation. However, I noticed the "Trips" view was only useful while in an active trip ( schedule > choose route > trip started ). There were a few questions I had to work through;
- Is the "Trips" view necessary in the tab bar if it's only relevant while already in a trip (flow begins from another location)?
- What might the static view of "Trips" look like?
- Could I incorporate manually entering a destination here?
I went back to sketching out possible solutions and was able to add the create trip interaction within the "Trips" view. This ended up solving two problems - what inactive trips look like and the ability to manually add a destination address without a scheduled calendar event.
Zero Data: When working through the initial wireframes in sketch, I rethought the need of having a registration screen. I included this is my initial sketches as a way to sync with the users google or icloud accounts and pull the event data. With the assumption that we will already have access to event data, the need to import/sync events became an edge case. To account for that, I designed an empty state for the default (schedule) tab with a prompt for the user to connect accounts of add events.
Route Selection and Trip Progress: When a users selects a trip, I explored an intermediary screen to review the route, but since the goal here was to get the user to a meeting on time, I placed less emphasis on analyzing and choosing a route. Instead, the user selects the route from the list view and the trip begins. When making decisions or using smart defaults on behalf of the user, it's important to provide flexibility for the user to choose an alternate path. Thus, a user can always navigate back and select a different option.
Return Trip: With the main goal of getting the user to a meeting on time, I thought a lot about what happens after a trip had ended.
- If a user has another meeting/event on his schedule for that day, the app with automatically preload a route to the next meeting.
- If a user does not have another meeting scheduled, I wanted to design a very simple interaction to get the user home or to another location. When the trip is ended, the user is prompted with two CTAs (1) return home, and (2) create new trip.
- "Return home" could be replaced with "Return to Previous Location," or similar. This is something that I would suggest testing with users to understand the correct choice to default.
- Create new trip brings the user to the "New Trip" screen, where they manually enter a destination and begin a new trip flow.
When I ran through the "trip selection" > "trip progress" flow again, the interaction and transition between the two states was not entirely clear. I wanted provide more feedback to the user and ultimately chose to add a "Tip in progress" indicator above the destination block. You can view the mocks before (above) and after (below) and see how this translates into the prototype.
Risks to solution adoption
I designed the flow and streamlined the features of this app to specifically support the primary job of enabling users to arrive on time to meetings via public transportation. The main flow relies heavily (not fully) on users to have scheduled calendar events pulled into the app, so if users choose not to import events, the benefit of automation will be lost, as the app pulls data from event details (date/time/location) to preload the destination/route and alert the user to leave on time. With the ability to create events within the app and manually enter a destination to start a trip, there is some added flexibility.
Again, we're assuming access to user's calendar events. A risk to adoption could be based on limited integrations with third part calendar apps.
If I had more time..
- For users who do not enable notifications and location services, the app will provide little value. So if a user has not allowed access, I would explore incorporating a walkthrough/onboarding flow to bring the user through the necessary steps, illustrating value for the trade of information. For this exercise, I stuck to the primary use case, assuming the user will allow the notifications/location services.
- Automation and decreasing user input was one of the goals. The prototype shows a sample iOS notification of an upcoming meeting, but if I had more time I would expand the different ways to use notifications to help and remind the user of when to leave for meetings.
Out of Scope
- Saving or favoriting locations
- Integrating with alternate transport methods, such as; Lyft, Uber, Scoot, Bike Shares, etc
- For users who work as a part of in-house or remote teams, an interesting feature to explore would be a slack bot or integration with their team's communication and scheduling apps.
- With the flow as is, I would coordinate prototype tests and rework/iterate as needed.