Project Sidewalk
Website | Accessibility Citizen Science
OVERVIEW
The following are highlights of my work during a three-month internship at Project Sidewalk, a website for crowdsourcing data about sidewalk accessibility in cities around the world.
My Contributions
User Research
Solution Architecture
User Flows & Wireframes
High-Fidelity UI Design
Feedback & Critique
Project Management
Cross-functional Partners
2 other designers
1 engineer
Tools
Figma
OUTCOME #1
Redesign UI for crowdsourcing data about sidewalk problems.
New Version
Old Version
OUTCOME #2
Evaluate accessibility-based route planning prototype.
Screenshot of the prototype I tested with 5 participants. The staff engineer made the prototype itself, based on Project Sidewalk’s existing data.
OUTCOME #3
Supporting designer to team designers on adjacent project.
I supported by
contributing wireframes and user flows to ongoing projects led by other designers
contributing ideas and sketches during group brainstorming and ideation sessions
providing feedback and critique on designs
facilitating cross-functional collaboration by actively listening during meetings and providing suggestions that satisfied both technical constraints and UX best practices
creating plans for project management
CONTEXT
Background
A 3-month internship for a citizen science platform
Project Sidewalk is a platform for collecting information about the accessibility of sidewalks around the world through online map imagery, crowdsourcing, and computer vision. This data is used to design, develop, and evaluate navigation and map tools for accessibility.
Over the course of three months, I learned a lot about how to work cross-functionally, consider technical and time constraints, and people’s priorities and motivations when planning accessible routes.
TASK #1: UI REDESIGN
Problem
Old layout has visual design and cognitive load issues
Project Sidewalk is updating its long-outdated interface, and I was tasked with redesigning the context menu—where users input details when labeling sidewalk features in the Explore tool. This is an especially important UI component because Project Sidewalk needs people to submit as much data as they can.
The old version of the context menu. This one is for labeling obstacles in the sidewalk. Each label type has different tags.
Goals for redesign
Improve visual hierarchy for easier scanning.
Reduce visual clutter to lower cognitive load.
Enhance accessibility for all users.
Align input flow with user expectations.
UI REDESIGN
Input Sequence
Comparative usability testing with two interactive prototypes
The team was undecided on the sequence of tags and severity rating. So, I tested two prototypes to see which input order—tags first or severity first—better matched users’ instincts and reduced cognitive load.
Screenshot of one of the interactive prototypes.
UI REDESIGN
Tag Field
I tried different iterations of the visual style along a spectrum of compactness vs. actionability.
I learned that users naturally think through surrounding sidewalk features, such as those identified by tags, when placing a label. Reading tags first aided their thought process and evaluation of severity.
I tried a few versions. While space and the ability to see surroundings was a concern, we ultimately went with the most transparent tagging style (on the left) in order to prioritize actionability.
UI REDESIGN
UI REDESIGN
Specs
UI REDESIGN
Reflection
The new UI is much better, but there are still some things I would have done differently. Here’s what I learned.
I conducted comparative usability testing to resolve an internal debate, and while this yielded interesting findings, digging deeper into the reasons for the disagreement and maintaining the priority of “submit as much data as possible” would have been a better north star in order to create even better real-world impact.
Because optimizing data acquisition is important, quantitative A/B testing could have been a better method to define a version that users would actually submit the most data with and achieve a better outcome.
The new version of the UI is much better now. That being said, I learned a lot by reflecting on what I would do differently.
TASK #2: USER RESEARCH
Opportunity
Use sidewalk data to help mobility-impaired people plan trips
A disability rights group in Chicago (one of the cities Project Sidewalk operates out of) wanted a route planning tool in advance of Election Day, when they would be traveling to voting locations.
Our engineer quickly created a rough prototype using two of the existing site features in order to display individual route data on a map. I was tasked with finding out if this prototype would be useful for our stakeholders, in what ways, and any issues.
Screenshot of the prototype made by the staff engineer, showing a route with labelled sidewalk data.
USER RESEARCH
Method
I conducted cognitive walkthroughs with 4 participants in one week
Because election day was coming up soon, and we needed to know if this prototype would be usable, I conducted cognitive walkthroughs with friends and family. I used the standard guiding cognitive walkthrough research questions (below).
Study Questions
Will users try to achieve the right result?
Will users notice that the correct action is available?
Will users associate the correct action with the result they're trying to achieve?
After the action is performed, will users see that progress is made toward the goal?
USER RESEARCH
Findings
The prototype failed in every test because users couldn’t figure out the next action after entering their route, and they were unable to make timely progress towards determining if a route was accessible.
The form of building a route through clicks on a map and then evaluating its raw data was completely new and unexpected to participants. Because of this, they needed me to explain to them how to get to each next step. Moreover, once they understood how to evaluate a route, they felt they were making little progress when they had to start the entire process all over just to view a second route when their first route didn’t work for them—taking up valuable time.
100%
of the time users failed to identify the next step after building a route
4
number of times a user had to start over to assess another route, on average
9
minutes spent building a route from start to end, on average
18
minutes spent evaluating the accessibility of one route, on average
USER RESEARCH
Outcome
Uncovering these insights provided my team the information to know we wouldn’t be able to put the time and resources into development.
With just one already-swamped staff engineer and a narrow one-week timeframe until Election Day, as well as no algorithm to make route suggestions, leadership decided that we just didn’t have the means to develop a route planning tool.
USER RESEARCH
Recommendation
If we were able to pursue it, this would be my conservative solution.
Even though the route planner wasn’t developed, here’s how I think about it.
The ideal tool would be one that follows industry conventions by entering a start and end destination, and which does most of the evaluation legwork instead of giving users raw data to click through. However, because Project Sidewalk relies on one staff engineer to do pretty much everything and PhD students who choose focused projects for their own degree pathways, that wouldn’t really be feasible since they didn’t have an algorithm to generate routes based on sidewalk data.
So, for more feasible upgrades to the current prototype, here’s what I would do:
Provide users a brief how-to guide or walkthrough of how the tool works so they know how to get from the routebuilding stage to the labelmap stage
Enable users to build and view multiple route options at a time, so they they don’t have to spend so much time going back and forth building new routes and instead see them all in one place.
Redesign the label legend for improved legibility and easier filtering
USER RESEARCH
Reflection
Quantitative data is beneficial for understanding how to feasibly make a product shippable with little time and resources.
I learned a lot about how the prototype was causing friction, frustration, and undue cognitive load on users. All of that qualitative data gave me a great understanding of how I could design a route planning tool that would resolve all of users’ pain points and needs. However, in a situation like this, with so little time and resources to dedicate to the project, turning to the quantitative data—summarized above—was most instrumental in defining realistic usability improvements.
