The power of the design framework. Dropbox File Viewer Redesign

We ve redesigned Dropbox s file viewer from the ground up for a long time. In this article, we will share with you the information we learned during the rework process.

Have you ever noticed the tool you use to view the file? If we at Dropbox do a good job, the answer is no. This is because you are paying attention to the content you are viewing. You can do what you need to do without fuss.

So if you don t notice the evolution that the Dropbox file viewer has undergone, it s no surprise. We iterate the new design step by step.

Considering the number of Dropbox visitors, the file viewer is at the core of the experience. It appears in many different contexts. It must meet a wide variety of user and business needs.

To provide this flexibility, we decided to rely on a framework. With this approach, you gain the advantage of a solid and scalable foundation. In this article, we will take a look at the main lessons we learned in the process of designing a framework.

Wait, but why?

When I joined the preview team in 2018, we were shaping a new vision for the product. However, realizing our vision was not easy. The product base is outdated. The existing information architecture was unable to adapt to the changes we needed. And working on top of the legacy codebase would slow down our progress.

Aside from some visual tweaks, the file viewer hasn t changed much over the years. Its limited architecture cannot scale to support the ideas that our team set out to implement.

As the design director said Jenna bilotta, you shouldn t hang garlands on a dead Christmas tree. So instead of continuing to build features on top of a fragile foundation, we decided to invest our efforts in a new one.

The new file viewer should become a platform. This would make future iteration easy and flexible to support many different needs. This way, our new Christmas tree will remain evergreen.

Plan like a chef

In the French culinary world, there is a concept called mise en place (everything in its place). It reflects the meticulous habit of chefs in planning their work and workplace. They check the ingredients and set the order of the tasks that the chefs must complete in order to successfully prepare each dish. They place each tool in a specific location for optimal efficiency. Rigor in preparation results in fast execution that meets high standards.

We had a design driven project ahead of us, and we did a similar ritual. First, we have put together the main ingredients. Extensive research has allowed us to identify the main areas of work for our users. Interviews with stakeholders throughout the company resulted in clear prioritization of business needs. A simple set of design guidelines will guide your decision making.

We then streamlined the process into a design roadmap. We ve expanded on the classic double diamond model by dotting it with breakpoints. We have detailed the methods that we will use at each stage.

This map was not created to represent a waterfall development process. Rather, it was a powerful anchor throughout the project. Files touched every part of Dropbox, so the entire organization had to be involved. Our roadmap has made our approach transparent. At any moment, we could determine where we were in our process. This helped to set expectations and earn the trust of our employees.

It also made us think more responsibly in our research before settling on certain ideas. By setting the deadline, we have allocated the space needed for quality work.

The importance of models

In any platform project, it is important that UX and technical planning come together. Therefore, before moving on to pixels, we started with a model that would be the basis for both design and development.

Expert Hugh Dubberley defines the model as a hypothesis of how the system might work. At their core, “models describe relationships: the parts that make up the whole; structures that link them; and how the parts behave in relation to each other. “

A good model forms a grounded design point of view because, as Dubberly writes:

The models are not objective. They draw the line between what is modeled and everything else; between the system and its environment; and between the elements of the system.

Creating a system, that is, defining it, is editing. What we think of as natural boundaries inside and outside the system is rather arbitrary. The people who create the model choose which borders to draw and where to draw them. This means that they must agree on their choice.

In the beginning, we disagreed on the key questions that we wanted our model to answer. Where should our solution be based on automatically selected characteristics, and where on user-selected ones? What core value will our solution offer to end users? How do you organize a rules-based system so that it can handle a variable number of file types and jobs?

We have encountered various answers to these questions using models. This led to intense discussions, during which a common point of view was expressed about our key elements:

• Modes: Too many jobs were required for our single file viewer. A complex solution can lead to too high a complexity of the product. Our model would represent the concept of modes – different representations for different tasks.
• Attributes: There were a lot of file details to consider. For example, extensions and types, collaboration states, visibility settings, etc. The number of these parts will increase as our technology has become more sophisticated. Our model must support countless attributes.
• Controller: The preview must be context sensitive. That is, he must be smart enough to show the right tools at the right time. We need technology that can determine the correct display mode based on the attributes. To begin with, we could give our controller a heuristic algorithm. In the long run, its logic will become more elegant with machine learning.

Here s how we presented these key elements and their relationship at a high level:

And an example of things our model can take into account:

And an example script. Javier completes the first run of the client s presentation and shares the file via Slack with his creative director, Carrie. Carrie opens the link to view the file and leave comments. For an optimal collaborative workflow, Carrie works in commenting mode.

The creation of this model was of great value to the team. It was expandable enough to support an infinite amount of data.

Test assumptions

While we made a commitment to rethinking, we didn t want to switch to a new design without testing it out. Therefore, we adopted an iterative approach from the beginning.

What s the cheapest way to test our model? Without creating anything new, we tested the concept of modes in an existing product. We used the tab structure that already existed, so working in the comment tab was similar to working in comment mode. Our tests didn t touch on any of the key business metrics, so we knew we were on the right track.

When we started developing the new information architecture and interface, we collected data from various places. We ve collected feedback on lightweight prototypes and card varieties. This helped us understand the pros and cons of different lines of research.

We disagreed on possible solutions to our problem.

When we got to the concepts that were ready for testing, we broke them down into parts. We then grouped these snippets as short-term, medium-term, and long-term. After that, it was easy to organize external experiments for each of them.

We also conducted internal stress tests to ensure that our projects would withstand a wide range of contexts. These exercises contained many custom scenarios, edge cases, and platforms. They were critical to the reliability of the new foundation.

One of the most valuable artifacts of the iterative process was our guess log. As we worked on the design, we tracked open questions and assumptions. This made it easy to collaborate with our research and analyst teams to develop curricula. We ve also prioritized according to the level of confidence. This exercise helped us move faster by focusing on low confidence assumptions.

The ultimate value for Dropbox and our users

Our technical and design systems are now flexible and expandable. This means that in the future, our file viewer will be able to keep up with innovation. The preview is no longer a landing page. It is now a multi-platform, multi-dimensional application designed to foster collaboration and profit.

We ve already launched some of the new preview formats, but that s not all!

The above example demonstrates our model in action. The file viewer takes various forms and modes depending on the context. Thumbnails help you identify files when you don t have time to open individual previews. If you open a comment notification, full screen commenting mode is enabled.

On the web, a full-size preview seems appropriate. Content in the foreground. The sidebar component contains key actions, information and modes. From now on, the product can be expanded to support a wider variety of file-based workflows.

The sidebar component can be scaled to support current and future preview modes. Easily switch between modes or collapse the panel to view more content.

We are excited about the possibilities this framework has given us. We are just starting to create the best file experience.

Thanks to the designers and researchers at Dropbox NYC who contributed to this project: Jenna Bilotta, Kim Bost, Erik Choi, Rebecca Hillegass, Sam Jau, Ryan Morrison, and Alessandra Mosenifar.