Back

Mapillary was, and still is many years after joining Meta, an open mapping platform for creating map data using computer vision and tooling for humans. Uploaded street view images are not only positioned spatially, but features like traffic signs are automatically extracted and placed as coordinates on the map, making map editing easier.

I got to experience the company's growth from the early years until 2020 when it was acquired.

As an early designer in a startup, my responsibilities spanned across product design for Android, iOS, and web app, brand design, production design for trade dress at various mapping conferences, and managerial tasks such as hiring, mentorship, and design system governance.

Scaling data collection

Although in the industry there were automated processes in place, at scale, maps were still edited and verified by humans. One way to collect high-quality, up-to-date street view imagery where map editing occurs is by commissioning drivers and directing them to capture images in a specific area.

I worked on this initiative between 2019-2020.

We already had a quite capable imagery viewer so the problem was really about figuring out a workflow for admins and drivers.

After distilling my thoughts from the discussions, I left my notes at the office for anyone to comment.

I narrowed down the problem to focus on the essentials. This way we can provide value for the first release already and leave the stage open for future iterations.

Admin: add/remove/setup projects, add/remove drivers
Project: assign/review tasks, driver management
Drivers app: capture, pick up/reject tasks

I blocked out the full journey early on. This helped align everyone involved around the scope what we need to build.

Admin UI

Answering the question of how to display drivers contributions on the map, I opted to not color code drivers' tracks. Instead, avatars were introduced and sidebar filtering option to see individual contribution.

The main admin view kept product conventions by showing map and sidebar. The sidebar allowed the manager to access the tasks or drivers.

Task completion assessment was originally based on a progress meter, but this wasn't feasible to implement. Instead, the manager visually inspects uploaded imagery.

Only one new color was added to denote not yet uploaded imagery. I designed it to look the same as regular coverage, but with the actual image missing.

Drivers app

An important element in the puzzle was an accompanying mobile app to help drivers carry out capture tasks. This new app was designed and built from the ground up. I specifically chosen a horizontal orientation because our users in most cases capture imagery that way.

First I tried to nail down the core interaction for our app. Once I had the visual concept ready, I built a simple interactive prototype to show the basic workflow.

Reassigning drivers involved three different parties: the admin, driver A, and driver B. I created a detailed video showing how reassignment affects them.

I mapped out how a simple function, such as remove a driver from a project, can affect the user experience for admins and drivers.

I love making these focused, simplified product screens along the design development to help explain what can we expect in terms of user experience.

Testing

I spent several days doing a managers work in a live project: contacting drivers, checking on progress, accepting and rejecting tasks.

Hands on experience allowed me not only to identify, but to effectively address several of the low hanging fruit issues (task display, links to profiles, distance from task centerpoint, driver home location, approve/reject colors).

Dogfooding is a great way to acquire learnings. I spent several days doing a managers work on a live project: contacting drivers, checking on progress, accepting, and rejecting tasks.

In addition, a company offsite proves to be a good source for doing usability tests.

For example, I discovered task acceptance related usability problems and the recording indicator was not performing well either.

Learnings

The most important is how to slice the problem down to the bare essentials. At a startup with limited resources and ambitious goals this has to be an art form. The organizations product maturity affects this, but you, as a designer, also affect it.

As a designer there will be many things not right or feasible to implement. The better I understand the tech stack, the easier it will be to come up with ux solutions. How to refocus after a failed attempt. How to convince engineering about a ux solution when they set out to solve a problem in one way.

Dogfooding is a great way to acquire learnings. I spent several days doing a managers work on a live project: contacting drivers, checking on progress, accepting, and rejecting tasks.

Exploring further

We did release a first version and made several successful capture projects for organizations. During that time we were exploring directions how to make data collection more effortless.

One direction, for instance was around implementing sawtoothing as an effective way to cover the streets of an area.

To create an illustration of an expected driving route for an onboarding video, I observed an actual image sequence from one of our drivers and recreated the exact movement (technically importing the GPS trace into After Effects). This helped us think about directions how to automate tasks.

(The mathematical problem, known as the "Chinese postman", is a different, more thorough approach.)

We also were experimenting with a solution like that to make it part of the drivers app. Below is an exploration how a future iteration would work where drivers play a pacman-style game experience collecting dots. Fun!