WorkResumeAbout

Walkabout

Pedestrians need a navigation tool that fit their wayfinding habits and help identify optimal routes. However, many navigation tools today are designed based on the driving experience, or are more like a map-based Yelp, recommending businesses. Walkabout satisfy pedestrians' navigation needs by providing quick directional and destination information, easy switch among multiple routes, and using navigation methods that make sense to walkers with multiple abilities.

VIEW SLIDE DECK


Role: Majorly UX and UI design, participated in research, ideation, and project management

Walk Pals: Spencer Wilkerson, Brooks Robinson, Abhi Yadav

Time: 7 weeks

Design Question

How might we design tools that satisfy pedestrians' multiple needs in different situations?

Process

Research

Triangulated Methods to Understand the Problem

To understand city dwellers' habits and needs for navigating in familiar or unfamiliar places, we did the following research:

Surveyed 67 people

8 contextual inquiries

Wayfinding literature

Research Findings

Context

Users are occupied when navigating

Touch point

Naviation info is needed at the begining, the end, and the intersection of routes

Users Quotes

User's need #1: efficiency and safety

"I want to get to where I am going quickly, but I also want to be safe."

User's need #2: accurate information

"I am frustrated when my map directs me to a closed route -- I need accurate information."

User's need #3: accessibility information

“I need to avoid stairs and hills, find a route with not only curbs but also curb cuts, and find the accessible entrance not only the entrance.”

Define

Design Requirements

Consider a wide range of navigation habits, needs, and priorities

Facilitate efficient information display and interaction

Ideation

Brainstorm, Evaluate, Prioritize & Iterate

In the individual ideation session, my team generated 20+ concepts in response to the design questions. We used an affinity diagram to group the concepts and then prioritized by evaluating their feasibility, desirability, and originality. We selected three most promising concepts and iterated by adding details and annotations. Finally, we created a storyboard to present the user flows.

Highlight — "Do not harm"

We originally planned to combined crime data to recommend "safest routes" since users expressed they cared about safety. However, learning that such a feature might unintentionally provide inaccurate indications of neighborhoods, we gave up the concept. We wanted to be cautious if our design might cause unethical consequences. We did not want our app to harm.

However, we still wanted to satisfy users’ need for learning if a route is safe or not. I brought up that there were different attributes for "safety", and crime rate was just one of it. I suggested using other indicators such as if the route was well-lit . After discussion, we decided to change "safest route" to "well-lit route".

Prototype & Test

Test to Empathize

We prototyped our hero flows and tested with 5 users for clarity, efficiency, and most importantly, values to them. We specifically focused on 4 scenarios that were either significant or potentially confusing. We then sorted users’ feedback with the Feedback Capture Grid and prioritized our focuses.

Feedback for Consideration

Due to time limitation, we were only able to iterate base on part of users' feedback. Below is how we decide what to iterate on.

We discussed iteration for the prioritized feedback. For some iterations that we were not sure about, we ran another round of testing with 3 users.

Highlight - Enter & Exit AR Mode

Iteration 1: Drag/tap to change modes

Pros:

  • "Drag to enter AR mode" was intuitive. 2 out of 5 users said that it makes sense to have a "drag down bar" at the top as the AR mode enters from the top.

Cons:

  • "Tap to return map" was not intuitive. 3 out of 5 users tapped the "exit" button to exit AR mode, instead of tapping the map.
  • "Drag down for AR mode" was not reachable when people used one hand to hold their cell-phones.

Iteration 2: Tilt up/down to change modes

Pros:

  • Tilting up and down to access camera mode (AR mode) was intuitive.
  • 3 out of 3 users liked it.

Cons:

  • "What if I put down the phone by accident?" A user expressed she wanted control in the AR mode.
  • The gesture(tilting up/down to access camera) is not necessary in users’ mental models.

Iteration 3: Add a lock to freeze modes

After some sketching, our team decided to add a lock to give users more control of entering or exiting the AR mode.

Hi-Fi Prototype

Highlight: Adding accessibility

I iterated the final UI design based on users' feedback. One major change was to make the routes more legible by increasing its contrast against the background. I wanted to include users with multiple visual abilities and to consider use cases where users view the screen against bright sunlight (which is likely when they are outdoors). I made sure the contrast of the routes and background pass the Web Accessibility Contrast Check.

I also enlarged the size of and spacing between buttons so that they are more reachable when used with one hand, a common use case identified in user research.

Before

After

Final Demonstration

Reflection

Be intentional with every design decision

Meaningful designs require careful considerations at every stage. From "would this feature bring values to people?", to "is the color of the text legible and reflective of information hierarchy?", designers always need to understand if their designs are valuable, useful, and delightful for their target users.

Stay in lo-fi longer

We should have conducted a round of usability testing with paper prototypes. In that case, we could have validated our assumptions about some key features in an early stage of design, which would have saved us lots of efforts. Also, users might be more likely to give feedback that requires more significant changes when they interacted with lo-fi prototypes. We also learned that different types of prototypes are used to elicit different kinds of feedback. In the case I discussed, lo-fi prototypes should be most useful for eliciting feedback on if the features are valuable and functional to users.