Your neighborhood-based parent social network
Neighbor is a mobile application designed for parents living in the same neighborhood with the mission of connecting local parents together and making parents' lives easier with kids. I joined the company as the UX Product Manager creating the product from scratch to final production.
- Product Designer
- UX Product Manager
- User Research Report
- Use Model Flowchart
- Personas & User Stories
- Storyboards & Competitive Analysis
- Design Screens
NEIGHBOR UCD APPROACH
At Neighbor, our design team follows the User-Centered Design (UCD) approach that consists of observation, ideation, prototyping, and testing. We then form our own approach as the "Neighbor UCD Approach" as demonstrated by the image on the right. We further break down each stage into small steps and combine prototyping and testing together to quickly iterate and refine our design to meet the needs of an agile startup environment.
WHY VERSION ZERO DOESN'T WORK?
Soon after I joined the company, I was presented with the problem of "Why version 0 doesn't work?". By that time, they’ve released their very first version of the app
but it didn’t gain attraction as expected. My job was to figure out what was wrong with V.0 and redesign the UI of the app to help the company gain attraction from parents
and encourage them to carpool on the platform.
To dig deeper into the issue to find the root cause of the problem, I dived into the observation stage and initiated a round of user research to understand the problem and find fundamental cause.
FINDING THE RIGHT PROBLEM
I started off questioning the problem, expanding the scope of
the problem and diverging to examine the fundamental issues by asking the following questions:
What are different types of Neighbor users?
Why do people want Neighbor? Why they don’t want it?
What works for V.0, and what doesn’t? Where does Neighbor fit into peoples’ life?
When and how is Neighbor used?
How does Neighbor stand out to its competitors?
What features are important?
Working closely with our user researcher, we initiated and conducted a round of user research to uncover issues with existing version.
Eight parents with carpooling experiences were recruited for a user interview. We've identified four types of user personas (see image on the right), and below are our major findings:
- Parents are more likely to carpool with people they know and trust. V.0 doesn't provide enough trust for parents to carpool with people are unfamiliar with.
- Parents would like to network with other parents and engage in the parent community. V.0 doesn’t allow finding another parent unless a matched trip is found.
- Parents want to acquire information about kid’s education, parenting advice, and nearby events. Neighbor doesn’t offer any of these information.
PROBLEM DEFINITION & PROJECT GOALS
We've discovered three major needs from our users (as shown by the image): the need to - build trust, social, and acquire information. We then came up with our problem definition
as "How might we build trust and provide convenience to parents' life?" Three project
sub-goals have been created in relation to the problem:
1) Improve trip experience to provide safe carpool and build trust among parents.
2) Connect parents together and build community.
3) Provide resources and information to make parents' life easier with kids.
PROJECT KICK-OFF MEETING
we've came up with a list of requirements and to-dos for the project considering all of the constraints from multiple stake holders.
In the meeting, we've decided to prioritize and focus on one of our core functions in the product that brings tremendous value to our business: "Improving trip experience by increasing the number of uploaded trips and matched trips." To meet this requirement, design team needs to 1) Improve the UI and flow of creating a new trip 2) Improve "My Trip" section to help parents connect and build trust with each other.
WHAT HAS BEEN BUILT: THE OLD SCREENS
As shown in the images below, the old system do not help users form a good conceptual model of how carpool should work. Creating a new trip was only accessible from a single entry point without clear signifier that you should upload your itinerary before a matched carpool is found. It also takes numerous steps to schedule a carpool. To redesign the UI and help users successfully upload a new trip and carpool with other parents, I started to think about the key steps and the workflow to simplify carpool experience.
KEY STEPS & THE FLOW
There are a couple of required information that our system needs to acquire from our users in order to match them with another carpooling neighbor (see image on the right). Design needs to
force some required data to be filled before moving users to the next step.
In "My Trip" section, I designed three states for each trip -- still matching, matched, and confirmed, to let users know that after uploading each trip, they can wait to be matched, confirm a carpool request, or check out a scheduled carpool and make changes.
SKETCHING & WIREFRAMING
In the first iteration, I just listed out required fields as shown in the image below and thought that they should be very easy for users to follow and take action (which proven to be wrong during user testing). I spent most of my time evaluating the pros and cons for each solution in the visual design of "My Trip" section (see image below) since it's an important area for users to check out what happened to their carpool requests. We got rid of solution #3 due to technical capability and quickly prototyped the first and second solutions for user testing.
PROTOTYPING & TESTING
FINDING THE RIGHT SOLUTION
At Neighbor, the prototyping and testing stages are closely related to each other with quick design iterations.
We conducted user testing to a group of parents and our findings are:
1) The new trip page was confusing: users don't want to name a trip and they got confused when we put trip time and locations together.
2) Solution #2 works better. But they don't understand what "Awaiting Response" and "Still Looking" mean.
Design principle #1: bridge the gulf of execution and the gulf evaluation. Make things available for both gulfs.
For execution, provide feedforward information and make the options readily available. For evaluation, make the results of each action apparent.
I further organize information in the new trip flow and segment them into “Time, address, children, and review” and I introduced a progress bar to provide signifier on where users are in the workflow. Feedback can also be responsively received within each step and constraints are provided by the status of the NEXT button.
Design principle #2: “Mistakes often arise from ambiguous or unclear information about the current state of a system, the lack of a good conceptual model, and inappropriate procedures.” ——Don Norman, The Design of Everyday Things
To make the states of each carpool clearer, I changed tab copy to “Submitted”, “Matched”, and “Scheduled” to make them more comprehensible. Within “Matched” section, visual elements like icons on the upper left corer aand a saturated color with drop-down shadow are introduced to indicate a new status of the card.
When the product was released, we moved on to the observation stage to track what worked vs. what didn't work.
- Increased the number of uploaded trips by 20% per user.
- Increased the number of weekly active users by 10%.
WHAT DIDN'T WORK:
- The number of matched trips didn't increase and we found out that was an engineering issue because the standard for a matched trip was too strict. We later changed that standard and were able to get more matched trips.
-Limited budget for design iterations and user testing.
-Lack of solid user base to recruit users for user interview and usability testing.
-Design with many technical constraints and short turnout time.
-Provide abundant signifiers to inform users of what each area means and what they can do.
-Increase discoverability of new features for each release.
-Test, iterate, test...Try to test and refine the design as many times as possible within given time frame.