The power of framework design

Have you ever noticed the tool you’re using to view a file? If we’re doing our job well at Dropbox, the answer is no. That’s because your attention is on the content you’re viewing. You can do what you need to do with it, no fuss.

So if you didn’t see the evolution that the Dropbox file viewer has undergone, it’s no surprise. We’ve been iterating the new design quietly, bit by bit.

As Dropbox’s highest-traffic surface, the file viewer is a core-experience primitive. It appears in many different surfaces and contexts. It needs to accommodate a slew of user and business needs.

To ensure that kind of flexibility, we adopted a framework-first mindset. Lifting up the hood of the new design reveals the benefit—a robust and scalable foundation. In this post, we’ll walk through the top lessons we learned about framework design in the process:

• Plan like a chef
• Model before mocks
• Guess and check

Wait, but why?

When I joined the previews team in 2018, we were forming a new vision for the product. Executing our vision would be a challenge, though. The product’s foundation was out-of-date. The existing IA couldn’t flex to accommodate the change we needed. And building on top of a legacy code base would slow down our progress.

As design director Jenna Bilotta put it, you shouldn’t hang lights on a dead Christmas tree. So rather than continue to build features on top of a fragile foundation, we decided to invest in a new one.

The new file viewer would become a platform. It would make future iteration easy and flex to support a ton of different needs. By doing so, our new Christmas tree would remain evergreen.

Plan like a chef

In the French culinary world, there’s a concept called mise en place (everything in its place). It captures the fastidious habit chefs make of planning their work and workspaces. They vet ingredients and sequence the tasks cooks must execute to make each dish a success. They place each tool in a specific spot for optimal efficiency. Rigor in preparation translates to swift execution that meets high standards.

With a high-stakes, design-led project ahead of us, we enacted a similar ritual. First, we collected the main ingredients. A rich body of research allowed us to distill the core jobs to be done for our users. Stakeholder interviews across the company led to a clear prioritization of business needs. A simple set of design guidelines would assist with decision-making along the way.

Next, we sequenced the process in a design roadmap. We expanded on the classic double diamond, dotting it with milestones. We detailed the methods we would use at each step.

This map was not created to introduce a waterfall process. Rather, it was a powerful anchor throughout the project. Files touch every part of Dropbox, so we needed to work across the organization. Our roadmap artifact provided transparency in our approach. At any given moment, we could pinpoint where we were in our process. That helped set expectations and build trust with our collaborators.

It also held us, as designers, accountable for diverging and exploring before we settled on ideas. By scoping a timeline to do so, we carved out the space we needed for high-quality work.

Model before mocks

With any platform project, it’s important that UX and technical planning happen together. So before we got into pixels, we tackled a model that would ground both design and engineering.

Expert Hugh Dubberly defines a model as a hypothesis for how a system could work. At their core, “models describe relationships: parts that make up wholes; structures that bind them; and how parts behave in relation to one another.”

A good model will inform a strong design opinion, because, as Dubberly writes:

Models are not objective. They leave things out. They draw boundaries between what is modeled and what is not; between the system and its environment; and between the elements of the system.

Framing a system—defining it—is editing. What we think of as natural boundaries, inside and outside, are somewhat arbitrary. The people making the model choose what boundaries to draw and where to draw them. That means, they have to agree on the choices.

To start, we diverged on key questions that we wanted our model to answer. Where should our solution live on a spectrum of automatic vs. user-controlled? What core value will our solution offer to end-users? How might we organize a rules-based system that could handle a variable number of file types and jobs to be done?

We grappled with different ways to answer these questions with models. Doing so led to rich discussions that informed a shared point of view about our core elements:

• Modes: There were too many jobs required of our single file viewer. An all-in-one solution would lead to too much product complexity. Our model would introduce the concept of modes—different views for different jobs.
• Attributes: There were many details about a file that we needed to account for—things like extensions and types, states of collaboration, visibility settings, and beyond. These details would grow in volume as our technology became more sophisticated. Our model would need to support infinite attributes.
• Controller: Previews should be contextually aware—smart enough to show the right tools at the right times. We needed technology to determine the right mode to show a user based on attributes. To start, we could set heuristics for our controller to follow. In the long term, our logic would become more elegant with machine learning.

Here’s how we represented these core elements and their relationships at a high level:

And a sample of things our model might consider:

And an example scenario. Javier completes a first pass at a client presentation and shares the file with his creative director, Carrie, over Slack. Carrie opens the link to review the file and leave comments. For an optimal collaborative workflow, Carrie lands in Commenting mode.

Establishing this model unlocked a tremendous amount of value for the team. It was extensible enough to support infinite future inputs and outputs.

Guess and check

Though we committed to a wholesale rethink, we didn’t want to flip the switch on a new design that had never been validated. We took an iterative approach from the outset.

What was the cheapest way to prove our model? Without building anything new, we tested the concept of modes in our existing product. For a proxy, we used the tab structure that already existed—so landing a user on the comment tab was like landing them in Commenting mode. Our tests didn’t regress any of our key business metrics, so we knew we were on the right track.

As we moved into designing a new IA and UI, we collected data from a few different places. On the qualitative end, we gathered feedback on lightweight prototypes and card sorts. This helped us understand the pros and cons of the various directions we explored.

When we arrived at concepts that were ready to test in the product, we broke them into pieces. Then we bucketed those pieces as near-term, mid-term, and long-term. Once we had these phases in place, external experiments were easy to organize for each one.

Internally, we also conducted stress tests to ensure that our designs held up in a wide range of contexts. These exercises contained a gauntlet of user scenarios, edge cases, and platforms. They were critical in bulletproofing the new foundation.

One of the most valuable artifacts from the iteration process was our assumption log. As we worked through designs, we tracked open questions and assumptions there. Doing so made it easy to partner with our research and analytics teams to develop learning plans. We also prioritized our list according to confidence level. This exercise helped us move faster by focusing on our low-confidence assumptions.

The end value for Dropbox and our users

Because of the rigor we put into the invisible part of the iceberg, we were able to realize long-term value. Our technical and design systems are now flexible and extensible. That means, going forward, our file viewer can support innovation. The preview is no longer a landing page. It’s now a multi-platform, multi-dimensional application, designed to grow collaborative and revenue-driving actions.

The above example showcases our model at work. The file viewer takes on different forms and modes based on context. Thumbnails help identify files when you don’t have time to open individual previews. If you open a notification about a comment, the full desktop preview lands in Commenting mode.

Over on the web, the full preview design is consistent. The content is front and center. A side pane component contains key actions, information, and modes. From here, the product can grow to support a larger variety of useful file workflows.