Context & Problem

A central use of the Map Maker application was to draw polylines on city maps Uber planned to operate in. These lines represented everything from road edges, to driving paths, to road paint, to speed limits.

Polyline drawing itself compromised the majority of a user's daily work, both in drawing annotation on new regions of the map, and updating and fixing existing regions. All polyline features were required to have “military-grade accuracy”, which allowed a 10cm margin of error.

EXAMPLE OF DRAWING POLYLINES OVER FLATNESS-SCANNED GROUND IMAGERY IN USER TASK AREA

The business wanted a unified and efficient design for polyline tool mechanics, as map specialists heavily relied on it for daily work.

The map production team at that point was $250k/mo to run, and were using only basic polyline drawing functionality which was prime for optimization. There were also more polyline features that were going to be added to Map Maker based on stakeholder teams’ needs, so polyline efficiency would only become more impactful. On top of that, Map Maker was planned to be scaled out to a new India team that would 12x the size of our current map production user base.

Strategy & Collaboration

Constraints were apparent. I was just recently brought onto the team, so engineering was blocked until it received design specifications for improvements.

Engineering needed to be unblocked as soon as possible, but the design solutions needed to be deeply considered such that they wouldn’t have unforeseen aftereffects when scaled out across polyline workflows.

The process of designing a solution involved tight collaboration with our internal 40+ user base.

I consistently checked in with users for thoughts and opinions. We'd have discussions throughout the problem's identification phase, throughout design ideation, and I'd gain team approval on final designs.

Early on, working with users I identified that how polylines were being drawn was error prone and unnecessarily labor intensive.

I spent a significant amount of time early on in discussion with users, understanding their work, how they used polyline tools, where they saw problems, and discussing ideas of how their work could be made better. What I found was, these problems cost the business more, and lowered the satisfaction of Map Maker users.

Many polyline features overlapped. For example, speed limit polylines had to be drawn on top of driving path polylines nearly perfectly for the the autonomy stack to read them correctly. This is one of dozens of examples of required overlapping of polyline annotation. Users then had to zoom very close to trace lines perfectly. And if the whole line was off, users would have to redraw all overlapping lines.

SUBSET OF ICONS OF AVAILABLE POLYLINE FEATURE TOOLS

An easy win would be a simple feature - allowing tracing of existing paths by other features. Quickly snapping to existing lines, and editing a snapped line would move all traced lines that shared affected points.

Polyline tracing was conceptually simple, but had significant implications with stakeholders for data integrity and requirements.

After validating the approach’s strengths with users, I collaborated with my PM and engineers first to gauge feasibility and engineering cost in comparison to potential user efficiency gains. My engineer in charge of implementation was sold on the solution after about 20 minutes of discussion.

My PM was understandably very hesitant about data integrity implications. As such, my PM, engineer, and I spent hours at a nearby whiteboard fleshing out the advantages, design options, and how it could be built to maintain data integrity. We arrived at a solution that enabled both data integrity and significant user efficiency gains, with low engineering overhead to implement.

EARLY WHITEBOARD FROM AN ENGINEER COLLABORATION SESSION

Solution

After identifying these issues, I designed tools and interactions that allowed users to easily reuse geometries of existing features. Speeding up delivery, reducing reworking, and eliminating tracing errors.

This resulted in two feature sets, for different use cases of polylines. The first was called “portions”, which were polylines traced on subset sections of existing polylines. The second feature was snapping interactions. Both features were validated for different polyline feature use cases with users and production managers.

STATE DIAGRAM FOR POLYLINE DRAWING WITH PORTION OPTIONS

Portions allowed users to annotate any existing polylines in two clicks, allowing them to generate new polyline annotations tracing previous ones exactly.

This eliminated time spent by users tracing polylines, and eliminated errors caused by lines not overlapping properly.

STATE DIAGRAM FOR POLYLINE SNAPPING

Snapping interactions allowed tracing of existing annotations to be much less error prone.

Intersection annotation and parking area annotation - which partially follow other existing polylines, but not always - were able to be created more quickly and with lower rework rates.

SAMPLE OF INTERSECTION TRACING DESIGN SPEC

Impact

These changes drastically sped up creation across polyline annotations, and provided universal mechanics the business could rely on as they planned scaling up.

The coming expansion to India was significantly de-risked, as our product was immediately showing efficiency gains on critical tool usability. These gains would only scale with the expansion.

Users were able to produce more, and their work was less stressful by omitting hours tedious tracing tasks. Further, users felt heard through our discussions, and with this first significant set of features delivered I also build a good deal of trust with stakeholders right from the start.

IMPACT METRICS OF PORTION AND SNAPPING FEATURE SET ADDITIONS

Traced existing driving path polylines sped up significantly, with Speed Limit annotation of driving paths becoming 60% more efficient.

Speed limit annotation is another ubiquitous annotation, which traces all driving paths. Efficiency gains here were a significant win.

Original polyline drawing tasks sped up as well, with driving path drawing becoming 11% more efficient.

Snapping made a big impact here in regard to data quality, as mappers had to maintain continuity of features across adjacent workspaces. Snapping made that fast and easy, and this showed in the efficiency gains of driving paths which required precise continuity.