While we envisioned Paper as a collaborative tool for work, there were clear limitations to the product:
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:
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.
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:
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.
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.