Asset+79%402x.jpg
 
 

G-COMMUTE

 

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 Team

 

Jay Luo

UX Designer

Interaction Designer

 

Bowen Zhang

Software Engineer

Data Analyst

 

Cody Wu

Project Manager


 
 

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.

Decreasing drive-alone percentage

Decreasing drive-alone percentage

Increasing commute time

Increasing commute time

 

USER RESEARCH

Primary research methods: 3 ride-along observations + 35 survey entries

My Role: Recruit ride-along participants, pilot & reiterate study plan, execute field studies

Findings:

  • 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.

infograph.png

Lessons learned:

  • 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.

Digital affinity diagram of the ride-along observations

Digital affinity diagram of the ride-along observations

Quantitative analysis of survey result.

Quantitative analysis of survey result.

 

IDEATION

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

Lesson learned:

  • 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.

ideation.png
 

EVALUATION

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

Lesson Learned:

  • 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  

Instructor participated and provided feedback to our usability study

Instructor participated and provided feedback to our usability study

user quotes.png
 

FINALIZATION

Approach: UX flow + Graphic Design + Implementation

Result:

A graph for each deliverable, and another one how they relate to each other, maybe vertical so everything can be bigger

Lesson Learned:

  • 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.

Finalizing.png

Demo video

 
 
 

REFLECTION

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.