Follow the Crowd Without Getting Stuck in the Crowd
A Native iOS app to help users avoid the unexpected delays when they go about their daily business
Product, Team, Workflow
General Assembly UXDI Galápagos, Project 4
My Role: UX Researcher along with Sheetal Suchde and Preston Tang
Duration: 2 Weeks | Project Status: Ongoing
Project Overview
The goal of this project was to develop a site or application that was original and could be sold to a potential partner organization in the real world. The scenario was we were working in/freelancing for an agency, and had to pitch the idea to the agency bosses. They would determine if the product was ready to pitch to the partner.
This was our fourth project and we were given the freedom to choose a problem and which UX methodologies we would use. We were asked to present 3 proposals to the instructional team so they could ensure we started on the right path.
Scope of Work
Our accepted proposal was to develop a native mobile application to help people plan a trip to the supermarket or park, by alerting them to any problems at the location, such as long wait lines, closures or special events. The idea was to minimize misery, by removing those things that can ruin your day.
Partnership with Nextdoor
We chose to use Nextdoor as a partner, as this application was about neighbors sharing information with neighbors and that is what Nextdoor’s mission.
“Nextdoor is the neighborhood hub for trusted connections and the exchange of helpful information, goods, and services. We believe that by bringing neighbors together, we can cultivate a kinder world where everyone has a neighborhood they can rely on.”
Our problem was something that users have posted about on Nextdoor frequently in the last months. The issue is that a response to a post on Nextdoor about the length of the line at Trader Joe’s, is not necessarily an accurate description of the current situation.
Our app would attempt to solve this problem for Nextdoor users, in a way that is different to how Nextdoor currently provides information.
Our application would need many users providing updates to be useful. We have to get the users sharing helpful information, so that it is attractive to more users cycle snowballing. Nextdoor will help us because:
- Its users have a high level of trust in it, they have to submit proof of residency to actually get on the platform.
- Its users are inclined to share with their neighbors
- It has enough users to enable us to scale up quickly.
- We can use the new Local Deals feature on Nextdoor to offer our users rewards for making updates to the site. We can incentivize them to engage, and also help Nextdoor raise awareness of this new feature.
Why a Native Application?
We decided to prioritize building a native application for this product rather than a responsive website, because this product will be mostly used on the go. An app has the following advantages over a mobile website:
- An app grants efficient access to location services on the phone.
- An app is usually equally visible on a screen. In the browser on a phone the user would have to enter the URL in the search bar, bookmark it or leaf through the any number of open windows.
- Finally users can make an update on the app and not lose it if their internet connection suddenly fails.
Process
We followed the Double Diamond framework of UX development.
Problem Space Statement
We started with the safe assumption that people don’t like waiting in lines and are annoyed when they arrive somewhere to find there is no parking, the restrooms offer no relief or the place is crowded for a special event.
How might we help people better plan everyday outings to reduce the frustration when things don’t go as planned?
RESEARCH PHASE (Discover + Define)
We expected our research to validate our assumptions, who wants to wait in a line, so goal was to:
- Interview people to better understand how they plan trips, what factors impact their decision making, and what are their specific pain points.
- We did secondary research into how this app might work. There is no point reinventing the wheel, especially one that broke.
The Interviews
We looked on Nextdoor, found people who had posted or responded to posts about lines or crowds or conditions at the park, and asked them to participate in our study.
We interviewed six people using a discussion guide to ensure we asked the same questions of each person, while hoping that each answer could take us down various paths revealing insights into why people do what they do.
We wrote the observations and quotes from each interview on virtual sticky notes in a program called Miro and grouped them into common themes by the process of affinity mapping.
The Study
Content is key to this application. Google has a busy times and live usage feature for a business that relies on analysing phone location data. They do not publish it in an API.
Some companies scrape this data from the web, but that is probably a violation of Google’s Terms of Service and not a reliable foundation for a business model.
We are unlikely to get enough raw location data to replicate Google’s ability to assess how crowded a place is, and if we did it would require a huge base of users sharing data with us.
The application will have to serve a user need in another way to be viable. The model here is the traffic app Waze. It uses location data, but the real differentiating factor is the user generated content. Any mapping application can tell you how to get somewhere, only Waze can tell you if there is a cop around the next corner.
In 2015 an application called Visor appeared on the market. It proposed to do what our application does; give people information about crowds and wait times. It is no longer available in the App store.
The Insights
Our initial assumption was validated and we distilled the following key insights from our research.
- The Pandemic has elevated these concerns in people’s minds. This gives us an advantage over Visor. This is the moment to launch this app.
- People are open to ways to make life more convenient, but they have to work. One or two bad experience with curbside pickup and people will toss it in “the nice idea, but” bucket.
- Users are reluctant to share personal data with applications, unless they see an obvious benefit to them
Persona and Journey Map
Using themes and comments from our interviews we developed a Persona called Tabitha, and imagined her planning a trip to Trader Joe’s during the pandemic. While fictitious this technique helped us as designers remember our insights relate to problems real people have in the real world. Journey mapping reveals the opportunities to provide a solution to a problem.
Defining the Features
Our Research gave us some ideas about the functionality to include in the site. We ran them through the MoSCoW and Feature Prioritization processes to determine which of these features we required and could be developed prior to the launch of this application
The result was a Minimum Viable Product. At launch the app must include these features. Anything else can be added in later builds
- Location sharing.
- Ability to make updates about the conditions at a place: A rating scale, adding comments and photos
- A rewards program to incentivize users to share data and make updates
- Profile functionality, so we can track rewards
- Information on the following points of the user experience: Parking, Wait times, Restrooms, Special Events and Closures and COVID issues
- Covering the following locations: Supermarkets, Parks, Beaches
We determined that other features and categories of place could be added over time.
DESIGN PHASE (Design + Deliver)
Design Studio
Having outlined the MVP we held a team Design Studio to brainstorm how an app would look and function.
Mid-Fidelity Wireframe
The next step was to develop a mid-fidelity wireframe prototype to test our ideas with users
Link to View Design of Mid-Fi Prototype
Link to View Prototype used in Testing
We ran five usability tests on this prototype asking the user to perform the following tasks. We recorded the users success (Direct, Indirect or Fail), time on task and evaluation of the ease of the task.
- Scenario: You have heard about a new app that might help you know if Trader Joes’ is busy.
Task #1: Start app, go through the onboarding flow and sign up for an account. - Scenario: You want know if there is a line at the nearest Trader Joe’s before you leave
Task #2: Search for the Trader Joe’s and find this information. - Scenario: You are at Trader Joes and want to give feedback on the parking lot.
Task #3: Give feedback in terms of selecting moderate on the scale and by writing a note. (your note will autofill when you tap in the right field) - We also noted if the users understood how the app worked after going through the onboarding process, as we regarded this as a key indicator as to whether they would register for an account and use the application in a productive way.
- Plus we noted if users elected to share location services.
All users completed the tasks
Task #1: Some users wanted to signup with social media accounts or chose to skip registering and continue as an unregistered user.
While users understood the application would rely on location sharing, after the onboarding flow they had very little appreciation that users could also actively provide updates. Given the limitations of location data we needed users to come away with a sense that this application was about people sharing human observations, there are 20 people in this line, not us aggregating anonymous user location data and saying: all those people are in one place it must be crowded.
Furthermore only two of the five respondents agreed to share data always as opposed to only while using the application, so we really could only rely on this data to show where a person was and not how many were around them.
An interesting comment from one of the test takers caught our attention. Asked at the end of the test why later she didn’t select location services all the time, she said for privacy reasons, “A Big Brother thing”.
She then asked about the points mentioned in the onboarding sequence and how they work. When told she would get a coupon for a local business she exclaimed “I’d totally share my location all the time if I got a reward like that!” This woman owned a small business and marketed on Nextdoor. She added that “As a business owner I would love people to know if my store was not crowded. And I’d totally give a customer coupon to get them to try me.”
This one exchange pointed the way forward. If we could educate people on the value of the rewards system they might be more engaged users of the application.
Task #2:
Users navigated to the page of results using the Groceries button, rather than using the search field to enter the name of the particular supermarket requested
Task #3:
We found that users were confused about the rating scale. It had the appeal of being an easy visual representation of a problem, but users were not sure which problem? Was it a measure of the number of free parking spots? Was it just the average of what others perceived the parking situation to be? Others wondered where the data came from.
The second challenge with this task was the button labelled Add an Update did not resonate with the users
High-Fidelity Prototype
Coming out of the first round of usability testing we made the following changes during the development of the High Fidelity Prototype.
- Better promote the rewards system during onboarding
- Stress the need for users to add comments and make updates during the onboarding.
- Make the search functionality more realistic, by including the iphone keyboard in the prototype rather than just having the field autofill on click. The Search is initiated from the keyboard.
- Better define what the rating system represented.
- Make the add update button more intuitive.
We spent some time developing the high fidelity prototype. As of now it has not gone through adequate usability testing.
Link to View Design of Hi-Fidelity Prototype
Link to High-Fidelity Prototype
Additional UX Methodologies
As part of the project we were asked to develop a plan for analyzing the performance of the application after it was launched. We used the Google Heart Framework
The App store has an analytics tool that provides high level data and is limited by the fact that app users have to opt into the sharing information with the developer.
You can measure retention rate, crash rate, the number of sessions and users who access your application, but unlike a website you can not look at data for individual screens and assess time or success of the task. Having an application requires further usability testing and customer surveys to understand the performance in depth.
We were also introduced to APIs, the iOS Human Interface Guidelines and Android’s Material Design Guidelines. This precipitated a reworking of our interface design. We were building on an iPhone 11 prototype, but using the very Android method of shadows rather than transparency and blur to indicate depth.
We were also required to produce a Spec doc.
Next Steps
The final presentation was to an alumni of the General Assembly User Experience Design Immersive program and an instructor teaching another cohort, acting the agency heads.
Inline with the brief we discussed next steps in terms of completing usability testing and making other refinements prior to presenting it to Nextdoor.
