Designing for Cloud Files
At Dropbox, we use Paper for nearly everything. Ideation, tasks, and even design specs all happen in Paper. We think it’s a great collaboration tool, and want our users to also experience this enjoyable way of working.
The way we work, however, isn’t necessarily the way our users work. In fact, many of our users don’t see Dropbox the way we do, much less Paper. What we spend our entire day using is just one of many tools in our users’ arsenal, and while we were busy polishing Paper, they were adding more tools to their kit.
Problems
This became a problem as we introduced new teams to Paper. First impressions were always good, but the same things would keep getting in the way of further usage…
The first and biggest problem is that Paper docs don’t live alongside regular files. Sam uses Dropbox to back up all her files but didn’t understand why Paper would take her to a site that feels different and separate from the rest of her file system. Likewise teams have gotten used to working with meticulously organized shared folders, but don’t want to start over when using Paper. This causes many advocates of Paper to eventually stop using it altogether.
Sara thinks Paper has a nice minimalist feel, but was used to using the Google suite and other storage products. All her Docs, Sheets, and Slides are organized in Google Drive. People are often using different tools that behave differently and are isolated. These problems also affected power users of the mobile app.
Opportunities
We realized that the problem we were solving for was beyond just Paper. Our users wanted the option to stick with any cloud file type they preferred, whether it was Paper docs, Google docs, or something else.
Dropbox began years ago as a tool for backing up and sharing your files. 10 years later, we’re still known as a tool for backing up and sharing your files. Paper was our first stab at being more than just file storage, but in the process of escaping the file system, we forgot that our core user-base still lives and breathes files.
Our north star
We approached the Paper problem first, intending to apply our learnings to future additions. The north star prototype we made revolved around the ideal user flow we envisioned for Paper users to be able to create, collaborate, finalize, and share, all from Dropbox.
We also established design principles to both guide and to set constraints for our solving of the aforementioned problems:
- Solve our user problems without sacrificing user trust in our current products
- Maintain the quick creation and open collaboration benefits of cloud files
- Respect user intent according to a hierarchy (admins, owners, members)
The first problem
Unifying two worlds
Cloud docs needed to move into users’ Dropbox folders with as little disruption as possible. This required rethinking and prototyping the site’s overall information architecture, which would create the new Dropbox home experience.
Unified home (IA changes)
The first challenge was modifying the Paper app, an intimidating task which would affect the growth and user experience of the product. Certain features like tasks, calendars, and projects lived in the Paper app and moving them elsewhere could prove confusing.
The new Dropbox home would need to maintain Paper’s quick creation and collaborative benefits, while merging the two experiences into one. Moving the aforementioned features would make the Paper app feel less robust, but they would be more discoverable and relevant in Home.
Dropbox home became the new entry point for web users, granting a bird’s-eye view of all their content on Dropbox, complete with tasks and activity. Files and Paper became a more stripped-down and focused browsing experience.
The mobile experience
Introducing cloud files to the mobile app meant introducing an entirely different way of interacting with Dropbox on the go. We wanted the context-switching between third-parties to feel seamless and intentional.
The Dropbox app was made optimized for organizing and browsing while deeper edits and text-specific searching could be made in the third party apps. Using Paper as our starting point, we learned that users easily understood when and why an app change would occur.
There were still technical constraints as we envisioned a more fleshed out experience, extensible not only to Paper, but also eventually Google Suite tools and more. It was particularly important to keep the design principles in mind while designing for edge cases.
Where we were able to, we supercharged the standard Dropbox app. Features such as rich previews and the ability to reply to comments in the third-party editors were among the additions. Since mobile work often involved quick commenting or responding as opposed to deep work, the current flow allows commenting from the Dropbox app to populate in the third-party editor.
Migration
The next challenge came from the fact that two file systems would need to be combined into one, in a way that makes sense to users. For this, proper education would be required, both in the form of pre-emptive messaging and in filesystem warnings.
As we migrated existing Paper docs and folders into Dropbox we made sure that users’ existing organization could be maintained. At the same time we also provided default folders which would teach users how to best use the new feature.
The second problem
Pointers v. files
In the past, we had experimented with allowing users to save Paper and Google docs as links in their Dropbox, and results were inconclusive. Users didn’t understand the value of having URLs live in Dropbox alongside their files, especially if they didn’t behave like files.
After weighing the pros and cons of pointers and files, we decided that the ideal user experience was one in which these cloud-based docs would behave as similarly to regular files despite their technical differences. This approach had to be extensible across all potential products, such as Google, Adobe, and even Figma or InVision files, so we relied heavily on our north star for this future vision.
Making it work like files
The future of the Dropbox filesystem would now accommodate cloud files. For this, user interactions would need to remain consistent despite unpredictable differences in functionality and permissions.
This meant that actions such as “move,” “duplicate,” and “delete” would behave predictably; only when technical limitations restricted an action would we notify the user. With proper education we believed users would hardly notice the difference.
Filesystem warnings
On Dropbox web and in the doc editor, changing certain UI elements made educating new users straightforward. On Desktop, however, there was more room for users to act in unintended ways. We designed a system of restrictions to limit the consequences of such actions. We also took this as an opportunity to audit and standardize Dropbox’s file interactions.
The end?
What started as an attempt to grow our Paper user base evolved into a much broader effort to design the next version of the Dropbox file system. The cloud docs initiative has been underway for well over a year, and will likely continue as new partnerships are made.
For now, Google docs, sheets, and slides, as well as Dropbox Paper will serve as the starting point for users to maintain one centralized space for all their work. Next steps will certainly include designing a system extensible for all potential cloud file formats.
As cloud-based tools such as Figma and inVision become more heavily adopted, the future of the Dropbox filesystem also becomes more exciting. I’m eagerly awaiting our user response as we release this beyond our office.
The (current) result
We received some press, some optimism, and some scrutiny. It’s clear that Dropbox has a reputation to uphold and the ongoing success certainly hinges on the users’ response, in addition to the company’s business goals.
https://blogs.dropbox.com/dropbox/2018/03/google-cloud-integrations/
