Scaling data collection


An entirelly new way to collect fresh imagery coverage by tasking hired drivers. Participated in product strategy, principal designer and led the product design team.




Interface for creating and running capture projects, managing drivers, doing payments, and a new smartphone application. My designs enabled drivers to capture thousands of km's of imagery coverage. At the biggest project to date it served a thousand concurrent drivers in 40 locations in 4 countries.

My role

  • Principal Product design
  • Interaction design
  • Usability testing
  • Design system

What I've learned

Platform-native mobile experiences for multiple platforms pose two problems: design overhead for maintenance and usability problems due to version differences.

The problem

Provide means for a project administrator to define, manage, run, and deliver imagery collection projects.

How would one administer drivers, add them to projects, where would those projects live? How does all this connect to the existing product? How does capture work?

I sketched the admin interface to add/remove projects and drivers left, setting up a project and looking at the task states top right, creating a seamless drivers experience. middle

For the drivers, I wanted to create the most simple workflow: just tap a button and start driving. Since we know the geographical areas for the tasks, we can start and stop the recording session automatically. bottom

Having established the fundamentals I proceeded of designing a full journey concept. Below is a selection of artifacts I presented at one of the first critiques.

The complete journey concept consisted of the three main pillars:

1 Managing drivers
2 Managing capture projects
3 Drivers experience

Assumptions I had made, but were later removed: task area subdivisions, go "off the clock".

To answer more complex cases, for instance, what should happen when a driver is driving and the administrator shuts down the project or what should happen to the imagery coverage that was captured during this time, I created a series of diagrams:

To document task state changes I created a detailed flow diagram describing the complete life-cycle:

1 Created
2 Assigned
3 Accepted / Rejected
4 Submitted
5 Approved / Rejected
6 (Reassigned)

References such as this are found to be especially helpful later on during development let the question be front-end, back-end or experience related.

Admin interface

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.

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

The main admin view keeps conventions by showing map and sidebar. The sidebar allows the manager to access the tasks or manage drivers. The navigation only goes two levels deep: either top level or a task view. This is the same for drivers: driver list or driver view.

Task completion assessment was originally based on a progress meter, but this wasn't feasible to implement. Instead, the manager goes task by task and explores uploaded imagery, then makes a decision.

Drivers app

For the drivers, I designed a card based, context sensitive paradigm. Once I had the visual concept ready, I built a simple interactive prototype to show how the basic navigation worked.

To provide familiarity, the visuals matched the native look on iPhone OS.

A company offsite proves to be a good source for doing usability tests. During these session I could pinpoint and fixing interaction design related problems.

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

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

Capture projects invented its own lingo: sawtoothing is an elaborate way to cover the streets of an area in an efficient fashion.

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:

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.


To truly understand the problems of the interface and workflow, 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).