Users were finding themselves struggling to locate content they had stored, especially when working with others across shared files, which resulted in users leaving us for competitors.
Why should we focus on metadata specifically?
We know this is a problem area worth focusing on because we've been losing users everyday to our lack of functionality in this space. As I dove into the research as well as some customer feedback from our community forums, it was clear that there was lots of room for impact here.
How might we help users find and retrieve their data?
Before we dig deep into the work, let’s start by defining some terms, just so we’re all on the same page:
metadata
noun
a set of data that describes and gives information about other data, such as the resolution of an image file
free-form tagging
noun
unmanaged metadata applied to resources by users, such as how hashtags are used on social media platforms
My mentor, Omeed Chandra, and a researcher named Lisa Hanson executed some very thorough research on the problem space of user-generated metadata, which included what sorts of things our users (across the board, including personal and enterprise) struggled with or longed for, and where our competitors stood within that space.
Many users were interviewed between the Europe and the US, collectively representing thousands of Dropbox seats, and yielded the following insights about user needs in this problem space.
Research indicates that we create 2.5 quintillion bytes of data everyday. That's a bit hard to comprehend on its own, but also consider that 90% of that data isn't organized. This means that we're generating a ton of data that is unique to how we, as individuals, see and interpret information. Imagine how much that complicates things when you're collaborating, as many of our Dropbox users do.
This led us to revise our research question, as we realized the need to focus on user-generated data, and how language can vary from user to user.
How might we derive users' latent taxonomies (aka their unofficial, preferred way of describing content) to help them find and retrieve content?
"Helping users find and retrieve content" is a very generic goal, and therefore also a large problem space that can be approached in a number of ways, including ideas like key-value pairs, labeling, machine learning-based classification, etc.
Since the goal of this project was to create something we can learn from to better inform the feature’s roadmap, I proposed free-form tagging as the ideal first step, as it allows us to evaluate how users organize and classify their content by studying their own taxonomies for defining their work and how that fits into larger workflows.
This diagram shows the way I sorted different user needs into what we need to solve for today vs. what we can do later.
In this work, I also found it incredibly important to touch base with the engineering team regularly. By bringing them in early, and building relationships with them right as I joined the team, we were able to discuss the feasibility of the design intent before I'd spent too much time exploring any extraneous features. This helped me understand how the design would fit into the existing Web and Desktop experiences, and helped me build trust with the engineering team by making the design a team problem, not just the designer's domain
A screenshot of a meeting with my project manager, the engineering team, and I, where we discussed the scope of this project and its feasibility.
Based on our research, we identified these needs as highest priority to solve for in the MVP:
There’s an incredible number of ways to approach this problem, so a lot of the exploration following the MVP proposal revolved around further clarifying and narrowing the scope.
I explored various scenarios while trying to understand what was most important to design for, and what needed to be scoped out. Ultimately, I focused on the following use cases. Based on previous usability testing, I understood these use cases to be the most common experiences for users, and therefore the most important to design for.
There were a lot of explorations around the visual and interaction design of this experience, and how the design might fit into the existing design system, so I'll focus here on showing and describing those that influenced the final design most.
I identified from the primary use cases that users will typically search based on tags, so they need to be visible in both the search bar and the search results view. It was crucial here to work with the engineering team, as this work could conflict with existing search bar functionality.
Adding a tag seems like simple functionality, but I explored a ton of different ways to do so because every nuance to the design can change the interaction drastically if you consider how repetitive the function can be. Here's a few highlights below.
Since a similar function didn't exist in the product that could be replicated, we needed to better understand how to make this a feature that was easily identifiable upon launch, not invasive for the many users that don't typically use these functions (as research showed, approximately 20-30% of users will actually take the time to add tags), but also efficient for those that will use it. Even though there's few people that are shown to use this kind of functionality, we've identified that those that do need it to work well for power users.
The final design resulted in two primary scenarios—one centered around search and the other centered around modifying tags on selected content.
You can also check out the final hand-off spec here:
