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: