Context: Grad School project (2019)
Design question: How might we reduce the number of single occupancy vehicles in Seattle during rush hour?
Outcome: A shuttle-sharing service operating on a phone app.
Process: Three months of research, ideation, prototyping, and testing.
The Problem: Why Should We care?
Seattle is expanding as a fast-developing city, and traffic has always been a problem. The average commute time in Seattle has steadily increased over the years even though the driving-alone percentage is going down.
Approach: Going through existing researches and discussions on potential causes of the problem.
Results: Commute time is the lowest priority when choosing a home location as the environment, entertainment, and community resources take priority. Many therefore live more than 30mins away from their work.
Lesson learned: Can know a lot about the problem space by just doing secondary research, and help narrow down the scope of the design question.
Primary research methods: 3 ride-along observations + 35 survey entries
My Role: Recruit ride-along participants, pilot & reiterate study plan, execute field studies
Most company’s existing shuttle service is inefficient and doesn’t match user’s schedule.
Commuting home is worse than commuting to work.
People believe driving alone is more efficient and flexible.
Getting stuck in traffic while driving is much more stressful than taking public transportation.
Requirements outlined from findings:
The solution should make shuttle service more flexible to users.
The solution should help more with the evening commute.
The solution should outmatch the efficiency and flexibility of single occupancy vehicles.
The solution should minimize user’s stress during commute.
Field study tends to have a smaller scope than the survey. So we limited the scope for field study within Googlers working in Fremont.
Survey’s larger scope and quantitative data can be used for validating whether the findings in the smaller scope can be applied to the bigger problem space.
Approach: 2 personas -> 2 user scenarios -> 2 storyboards -> 1 task list -> paper prototype + test plan (maybe a huge infographic)
My Role: Leading the ideation process
Goal: Outline user’s goal, use cases, and task list
Very easy to fall into the trap of “focusing on design” when making the paper prototype. Instead, the key focus should be the flow of the task list.
Focusing on design will make prototyping high cost, losing the advantage of prototyping.
Approach: 1 pilot usability study + 3 usability studies (maybe a graph showing improving or something)
Result: A picture showing all the usability issues
My Role: Wrote test plan, facilitated usability study session, presented analyzed data
A lot of things can go unexpected! So pilot study is a must.
Can learn so much just from a scrappy paper prototype
Participant might have trouble thinking out loud. Need a little practice at the beginning to help them learn how to do that
Approach: UX flow + Graphic Design + Implementation
A graph for each deliverable, and another one how they relate to each other, maybe vertical so everything can be bigger
Keeping in mind of what should be incorporated from previous deliverables can prevent focusing too much on details
Developers need more than just the mockup and assets. They need to be consistently involved in the design process.
Adjust research scope based on resources
At the beginning of the research, it was hard to research directly on the large problem scope of the entire seattle commuting population with only 3 field study sessions. We made the strategic decision to scope down to commuters from one company, and then scope up and see if the finding still applies to the larger population.
Separate logical design and creative design
Focusing too much on the creative side does more harm than good: it will make rapid prototyping slow and costly, and risk drifting away from design requirements. I realized that it’s easy for me to just think about making the design align with my idea and aesthetically pleasing.
Communicate within an interdisciplinary team
Initiating discussions and debates are sometimes necessary. My teammates with different backgrounds were often confused or disagreed about why we were going through certain design processes. I found it helpful to ask proactively about their confusions.