Gethere
Client: Gethere (Designlab project)
Sector: Maps, wayfinding, public transportation
My Role: UX Research, UX Strategy, End-to-End mobile design (IOS), Branding
Project Time: 4 Weeks
This project started with a basic user problem and the assignment to turn that into an MVP mobile app.
The problem:
“I don’t feel safe when I’m on public transportation by myself. Between systemic racism, sexism, germs, and the overall untimeliness of our public transport system, there are too many things I need to think about.”
A huge premise to tackle, so in setting goals, I wanted to keep my options open to see where my research leads me.
High Level Goals
Research to narrow the goal of this MVP- what are potential users most concerned about
Define solutions for this app- what makes people feel safer and how can those be applied as features
Design a simple app that can be used in stressful situations
Define the brand and name for the app
Discovering the right problems
My initial secondary research was all about discovery.
What kinds of research and solutions existed?
Were any apps specifically focused on this?
How does technology play a role in solving this problem currently?
The subject is fortunately well-trod territory. I was able to read sociological papers on the experiences of women, minorities, and LGBTQ+ individuals on public transport. I was able to note many similar conclusions and recommendations across the spectrum. These solutions span environmental design, public awareness, technology, and social interaction.
As much as I wanted to explore public transportation more universally, I concluded that the impact of COVID-19 was too far-reaching to not include. I read perspectives of both how various public transit institutions were responding as well as third-party reports on the pandemic's impact on general use.
Secondary Research Assumptions
Based on my initial exploratory research I created some assumptions about the direction of the app:
The condition of stations and trains plays a large role in users' feelings of safety- perhaps community reporting features like Waze would be helpful.
COVID-19 has made crowdedness an important factor. Apps like Google Maps and Commute are already doing some reporting of crowdedness- There may be more room to move in this direction
Being able to report safety concerns to people who can help is an important contributor to feelings of safety- how could an app interface with local transit or police?
Taking the assumptions back to the users
I took my initial research conclusions and assumptions and used it to create a survey and user interview questions.
While my intentioned had been to use the survey as a screener and set-up for user interviews, I gained a number of valuable insights:
Though the pandemic significantly affected use, most users planned to return when they felt safe
Most users used more than one transport app
Crowd size was their biggest concern
Research Conclusions
Taking these insights I interviewed users from 6 different public transport systems at varying ages and walks of life. While my questions and topic focus had begun oriented towards safety, in talking with users I found that they thought about public transportation very differently.
For all of them, their ability to use public transportation effectively was the top issue.
Their pain points were things like timing, route decisions, their farecard balance, delays, interruptions, or the weather.
Many had baked some safety concerns into their overall approach.
They lived very close to a stop so they weren’t spending lots of time standing alone, they stopped taking public transportation after a certain hour, or they avoided certain stops altogether.
Covid-19 and general train crowdedness was a top concern.
Many had bought a car or a bike over the past year instead.
Re-evaluating the concept
At this point, I felt a little unsure where to proceed. My secondary research, while fruitful, was not matching up with the needs of my users.
After creating a customer journey map to hone in on expressed pain points, I had an ideation session to craft HMW statements. I categorized those statements and let myself brainstorm ideas and solutions.
From here I honed in on a central idea of automation. All of my users talked about either checking their route every morning for delays or after encountering unexpected delays on their usual route. I decided the focus of the app would be how it could work to tell users about issues or give them directions, without them needing to go seek that information out. I wanted to leverage both the users schedules, habits, and general data available to integrate the app into their day.
Benchmarking and planning
I took some time to look at how other public transit map apps handle various aspects from both a design and strategy perspective.
Then I created a feature list that accounted for both what I consider the map app ‘must haves’ as well as the specific new feature I wanted to focus on for the MVP.
I decided both creating a ‘commute’ in the app as well as having users sync their calendar, would provide an easy way for the app to help users get places.
Fare Cards were also a big pain point, so I wanted to integrate their current balance into the app. That way the app could alert them when they ran low. Even after including this feature in some initial designs and mapping out the user flow, I concluded there was no efficient way to make it part of the app.
Public transit fare cards are different in every city. Most are run by private companies with their own apps. I couldn’t rely on total integration and anything that involved the users having to input their balance and record their rides, seemed to be adding steps, not helping.
Testing the concept
I experimented with a few different looks for the main screen. My first big decision was not having the app open on a map page because I wanted to prioritize the calendar and commute.
I, then wireframes out the calendar sync flow, the commute flow, and some other maps pages.
I did an initial round of user testing, simply examining the home screen which led me to re-evaluate the concept. I realized I wasn't doing enough to explain the central features to new users.
I re-designed the home screen to focus on a central set-up process that onboarded the users.
I also choose to eliminate any navigation layers of the app and focus on any task being only one step away from the home screen. Users are consulting their map apps on the go, so nothing should be buried.
Finally, I decided the look of the home screen once the user is all set up would have a calendar focus.
Based on usability testing of the various flows I put together an empathy map and some action items to go into the final UI.
I was able to see significant improvement in usability for the second round of remote user testing. 100% of users completed the tasks with a fairly low mis-click rate. Users were able to identify the function of the app, how they might use it while having questions outside of the scope of the prototype.
Initial usability testing revealed users liked the idea of being notified about when to leave or what delays there were, but most wanted more control. So I created an advanced settings screen to give users more control (1,2)
The updated home screen allows for users to change the calendar view based on their preference (1).
Users were also having trouble locating the map for exploring, so rather than a page control I added a prompt. The functional app would also bounce open a little upon opening to reveal the map affordance. (2)
Some users had non-traditional commute use cases, so I decided to add the ability to allow users to add more than one commute or update their events calendar from the app (3)
Conclusions
Listening to my users and giving myself the mental permission to pivot and ideate allowed this app to be a success.
Some of the details I was able to add came straight from interesting use case suggestions (what if I have more than one commute? Or I want to be able to set the timing for when it reminds me).
Other things that initially seemed important, like the crowdedness of public transportation or how well lit a particular station was, really feel away from users' inhabit because they simply needed to get to their destination on time. Those core motivators lead to a much more robust app.
While I attempted to get a variety, in retrospect my user interviews did comprise mostly of tech-savvy, well-educated, and well-employed users. One of public transportation's successes is that it serves all populations. My users generally had regular hours and regular destinations. There are many potential users who that is not true for. Other factors might weigh more heavily on shift workers consistently traveling at more irregular hours.
Next steps
Dig into the language of the map and directions aspect
Workshop the copy and content of the onboarding
Add an event flow