A Lean UX Iteration on Dropbox Photos
Part 2 in a series. This process identifies user needs, prioritizes needs to work on, and narrows the scope to the best areas to design…
Jared is a snap-and-go kind of photographer.
“Sometimes I’ll take photos. Share them. Look back on them. But it has to be easy—managing my life can’t get in the way of me living it.”
Jared has 4 important needs in how he handles photos.
- a single place for everything—Jared stores different sets of photos across different services, and he often forgets what is stored on where.
- convenient security—He’s a casual user who doesn’t transfer or back up his photos at every new album, but he wants to know his photos are safe in the event of any hardware malfunctions/theft.
- an easy way to share—Jared takes pictures to share memories with friends and family, some of whom are less tech-savvy. When Dropbox requires recipients to download the app, he gets frustrated with onboarding his aunt to Dropbox over the phone.
- organization—After a week of adventures, Jared dumps batches of photos into his libraries, often without any effort in organizing them. He finds his resulting library time-consuming to view and sort through.
I’ve got to help Jared! His needs are a common denominator among 95% of the 16 people I’ve interviewed about their photo management habits.
How can I resolve those needs?
I’ll start by breaking down his broad needs (epics) into sets of smaller needs.
Breaking the epic into smaller needs allows me to narrow the scope of this iteration. A narrower scope means I can closely validate each subsequent step of my design process to a shorter and more specific checklist of needs.
(Alternatively, accounting for long lists of needs has dangerously led to a compromised solution/feature creep/downward spiral of overdeveloped features that people don’t actually need.)
Let’s break down Jared’s needs.
Jared’s needs as epics:
The most important story to Jared is keeping track of his photos in one place, and easily sharing those photos to his friends.
I’ll be resolving this story, one step at a time.
To narrow the scope of this iteration, I focused within the pink epic, then focused on the two needs that didn’t have an existing fix. These two needs became the scope of the project, and they were broad enough to be broken down further:
The smallest needs (yellow) are now specific enough to begin designing solutions for.
How do I think about design solutions here? I use job stories to translate needs into design jobs.
I’m utilizing this process described by Intercom, who:
“frame[s] every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome.”
Sample job story:
The two epics of the scope have been translated into a list of design jobs. The list now serves as a checklist of everything my design solution (the new feature) needs to accomplish.
Building against the checklist ensures I solve for the scope. Nothing more, nothing less.
How do I begin building?
Building a new feature can be daunting. I use task flows as a starting point to outline the system of my suggested feature. A task flow is a walkthrough of the interactions a user takes to complete a story. It’s analogous to mapping out a blueprint of a building before I build it.
Task flows are a tool to help us think through the design before a feature is actually developed. They allow us to interject the user into the flow of the application and determine if the conceptual model agrees with the user model.
— “rk” on ux.stackexchange
The task flow for the new feature needs to fulfill the two epics of this scope:
- grabbing all the things
- automatically backing up all the future things
We’ll call this feature “import settings”.
Dropbox’s current flow, and where this new feature would fit:
The task flow of Import Settings should resolve Jared’s most important story (the following is a very specific version of it):
Jared wants to add photos from his Facebook to his Dropbox. He wants to know that his future Facebook photos will continue to be transferred and kept safe.
This bird’s-eye view of a task flow helps me in two ways:
- account for all of the screens I’ll have to design for in the next step.
- see where things are getting overly complicated (requiring lots of interaction). These areas are opportunities for simplification, ensuring an easier experience for the user (and servers!)
Task flows give me the chance to plan an efficient system before I mock it up in higher fidelity.
Looking at task flow version 1, I had a realization. The flow does a couple of things. After the prerequisite connection and authentication sections, Jared must walk through 3 sections:
[1. view, select: albums, photos]
[2. import albums, photos]
[3. auto import future albums, photos]
I had 2 needs to solve in this scope. But I created 3 solutions here.
One of these does not belong!:
I didn’t catch this until I made a couple of screens:
The MVP iteration should solve the need. Nothing more, nothing less.
While the interaction of viewing/selecting photos seems a reasonable assumption, lean UX is about validating core needs, and validating our solution as an answer to those needs, before iterating additional versions of the solution.
Let’s simplify the task flow to only address the needs of the scope:
Task Flow, Version 2:
From here, I’ll design a prototype while considering design patterns and heuristics.
Where we are in the series on Reimagining the Dropbox Photos Experience:
Part 1 — A Guerilla Usability Test on Dropbox Photos
Part 3—Wireframes and a prototype of the new feature to follow.
*I don’t work for or represent Dropbox. I’m a curious Visual Designer shipping UX projects at 2 design programs until the end of March. I study under Laura Klein & Kate Rutter @Tradecraft and Megan O’Rorke @GA_SF. Send me design challenges come April ☺