Dropbox Paper, Dec 2017–Mar 2018

I was knee deep with the team through the entire thing—from defining problems, to scoping down the work, to executing on visual design, to building dashboards, to working with engineers to polish to the final product. The team included two web engineers, one iOS engineer, a product manager, a writer, and a researcher.

User problems and Paper problems
Paper didn't work the way people worked

While we envisioned Paper as a collaborative tool for work, there were clear limitations to the product:

  1. It was impossible to create in-house templates that met every conceivable team's processes.
  2. Workarounds to copy and paste were a compromise for users who didn't feel like Paper is a tool that works for the way they work.
  3. Teams struggled to have consistent processes across projects which hindered their abilities to be efficient and effective.
  4. What's more, the templates we offered during our onboarding experience were limited and not customizable.
Measuring success
A lever for activation and collaboration

Our goal was to create a differentiated feature that would make Paper appealing, activate people and their teams, and ultimately retain them in the long-term. Metrics that measured how valuable the feature would be were:

  1. Percentage of all docs created from templates
  2. Percentage of people collaborating on docs creating from templates
Scoping a minimal viable product
Workflows that would enable us to test our hypotheses

I explored a few original workflows for user stories based on the problems we found. We tried to pare it down to the most essential workflows for an MVP.

As someone who manages team processes, I want to be able to create canonical versions of docs so that our processes are consistent and repeatable.

As someone on a team, I want to make changes to templates so that our processes can improve and everyone seamlessly adapts new processes.

As a new member of a team, I want to be find the templates I need for my job so that I can get up and running as quickly as possible.

From there, we broke down the components that would be require to fulfill these workflows.

First was the template library—a place for people to find all the templates they and their team had created and to create new templates from.

We landed on creating a reusable dropdown component that we'd attach to different entry points. While we knew it wouldn't scale, it was fast to build and we also didn't expect people to have that many templates to begin with.

We'd be using the same back-end editor as regular Paper docs but we needed to make sure that people knew they were editing a template. I explored a variety of visual treatments for this cause.

We landed on a treatment that used a similar architecture and layout as our default doc header, but was salient and novel enough that indicated to people that this was something different they were editing.

We started out by using adding the template library to all of the existing surfaces where we'd enable doc creation.

Internal feedback, usability tests, and Amplitude charts
Mental model mismatches and surprising data

We removed the entry point from within docs because we got feedback that it slowed down the doc creation process by adding one more step. The remaining entry points were also the most frequently used for template usage, with their relative percentages below.

We also usability tested with 10 people who had use cases for templates. Places where our assumptions broke down were:

  1. Templates themselves weren't collaborative—usually one person made them and shared them with their team to use
  2. The "plus" icon was confusing
  3. People didn't associate "blank doc" as a template
Learning after launch
People had unmet expectations of templates

We knew that the feature set that we released with was limited, so we reached out to people who had tried out the feature to learn about how they were using it. I conducted and led the planning of these interviews.

Since our pre-built templates came with placeholder text in them, people who were making their own templates expected the same for their custom templates.

People weren't able to find their templates and therefore believed the feature was buggy. So, we added templates to search results, visually differentiated them, and also enabled doc creation.

We also learned that team coordinators valued organization and wanted to be able to hand off folders that essentially conveyed processes. By adding a templates section to folders, people shared on the folder could understand which types of docs to create within the folder.

Investing in visual language, sharing, and examples

While the colour-block and icon differentiated templates from docs, the iconography itself doesn't lend itself to being read as a template. I'd love to go back and explore that more so that templates can appear in more of Dropbox's surface areas and be instantly recognizable.

Additionally, templates are incredibly powerful in showing team members, as well as new users the potential of Paper. We scoped it out of our MVP, but adding more pre-built templates that expose Paper's usecases, as well as finding a way for templates to be easily shared within a team could both accelerate people's processes.