How sharing my story helped amplify other voices at work
A few months ago, I gave a talk to our Design team of over 100 people and asked the audience members to do something vulnerable.
Stand up if you feel like it’s harder to advance your career because of who you are.
The question was based on conversations I’d had with women on our Design team, so I expected only a subset of the audience would relate to this statement (and an even smaller fraction would have the courage to stand). To my surprise, at least half the room rose. And it wasn’t just women.
I continued: Stand up if you’ve ever felt like your peers are given more opportunities than you … if you’ve left a meeting with a lowered sense of self worth … if you’ve avoided talking about your accomplishments out of fear of being judged … if you’ve felt like leaders don’t represent you.
People continued to rise, again and again, each time with more momentum. There was power in standing up for how we feel and relief when we realized we’re less alone than we thought. I was struck by how safe we all felt sharing vulnerable feelings and welcoming hard conversations.
We went on to talk about what we could do about these feelings, which led to change and strengthened our community. And I’ll get to that.
But first, what did it take for us to get to this point?
About two years ago, I joined Dropbox, fresh out of a college design program with two-thirds women. I was used to seeing women leading projects, asking hard questions, and being supported by peers. Sure, I’d read stories about challenges women can face as an underrepresented group in the tech industry. But to me they were just that — stories in the news — until one day I looked up from my desk and realized I was the only woman in sight.
That day, I started paying attention to gender dynamics at work. In meetings, I noticed men talking more confidently and more often than women and non-binary coworkers. I saw women getting interrupted and then apologizing. The patterns I’d read about were playing out before my eyes, and suddenly I couldn’t stop noticing.
This made me wonder, who else was noticing? I brought my observations to my manager and then to our HR partner, who encouraged me to talk to other women on the team about their experiences at Dropbox and in their careers. This curiosity ultimately grew into an initiative to help women in design share their stories openly and improve their experiences at work, in tech, and in the world.
I invited my teammate Sheta Chatterjee to join me, and over a couple months in late 2017, we talked with women across Product Design, Brand, UX Writing, and Design Research. While many women told us about the kind and well-intentioned community at Dropbox, we also heard many stories like these:
A woman walked out of one of our company-wide meetings called “All Hands” around that time because she felt alienated by the presenters, who were all men.
Multiple women said it was hard to get a word in during meetings because the men in the room were clamoring to talk.
A woman said she felt the need to “police her tone” when giving feedback in person or in writing because she was afraid she’d be seen as too aggressive.
Hearing this chorus of women talking about workplace challenges was overwhelming. As a woman beginning my career, I felt disillusioned and worried about my own future. However, in listening to the many voices, I also realized how much our stories overlap. If we talked about our experiences more openly, I believed we’d feel less alone, and even more — we could push for change.
Sheta and I wanted to share these powerful stories with the Design team, but first we needed to dig deeper. We hosted a couple of workshops and invited all the women in Design. Our goals were to gather more context about what we’d heard, pick out the challenges we felt most strongly about as a group, and brainstorm solutions. Here are the top challenges and recommendations we ultimately presented to the Design team:
Women didn’t feel represented by leadership, so we recommended our team increase the visibility of women leaders, give more recognition to women for their accomplishments, and expand opportunities for women to develop leadership skills.
Women weren’t feeling confident in meetings, so we recommended people help facilitate meetings, amplify women by actively crediting them for their ideas, and give direct feedback to people to help them be more inclusive.
Women were feeling stunted by our team’s tendencies towards agreeableness, risk-aversion, and self-promotion, so we encouraged people to lean into debate, share more early stage work, and celebrate individual growth.
Know we’re not alone
Our presentation not only helped people gather around shared challenges, but it also inspired support. Immediately after, some amazing things happened:
A man on the Design team scheduled an hour with me and Sheta to learn more about women’s experiences and develop empathy.
Another man told me he realized he and his male teammates were dominating conversations in design critiques, and he was going to bring these concerns to his manager.
A man told me he wanted to create an allies group at Dropbox and scheduled time to share his ideas with me.
Multiple men recognized Sheta’s and my efforts in our design team Slack channel, which sparked a discussion about diversity.
In the two years since joining Dropbox, I’ve noticed many other positive changes. Our design team has continued to invest in Ladies Who Create, a community for women and non-binary creatives. Thanks to this type of programming, the Dropbox Design team is 55% women today. In broader Dropbox news, two women were promoted from within the company to the executive team. They often speak at All Hands meetings, which now always include female presenters.
So, I’m happy to say, I haven’t felt so alone as I did that early day at my desk. Looking around now, I’m typically surrounded by a diverse group of people, and that’s really amazing. But I’m also aware our society has deep-rooted workplace dynamics that exclude women, people of color, non-binary people, and anyone who isn’t represented by the majority.
And it’s when things start to look good on the surface that it becomes easy to stop paying attention to how we’re really feeling. Now it’s more important than ever to seek others’ perspectives.
I wanted to share the story of how I noticed something wrong, talked to the women around me, and things started to change. But mine is just one story of many.
Want to read more women’s stories?
I recently created a zine that features stories from four women in design at Dropbox. When considering a theme, I reflected on the name I’ve been calling this initiative: Ladies Get Loud. I’d chosen that name because it sounded different, even unusual. There was a tension built into it — women aren’t traditionally encouraged to be loud.
Women struggle with being seen as too loud versus too soft, too masculine versus too feminine, too emotional versus too cold, the list goes on. However, describing these challenges in binary terms would be too simple. “Tensions” acknowledges the possible range of behaviors, the conflicting costs and benefits that can exist within a single choice, and the complicated balancing act many women constantly perform.
The zine has four interviews with women in design at Dropbox about tensions they’ve felt in their careers. The goal isn’t to provide the “right” answers but rather to explore the diverse ways women can experience and deal with conflicting expectations.
These stories are powerful and important, and we’d love to share them with you. Request a zine, and we’ll mail you a copy. We hope it inspires you to amplify other voices around you.
Demystifying the fear of failureZine by Garrett Prince & Andrew Richdale
Have you ever not done something at work because you were afraid to fail? I have. But, what is it about failure that induces this fear? Is it the thought of losing support from my lead, getting pulled from a project or even losing my job? Or, on a meta level am I afraid that my failures will define me?
After conversations with peers about failure, it turns out I am not the only one thinking about this. In fact, it seems like failure is actually quite mysterious, personal, and misunderstood given everyone’s unique relationship to it. While everyone had a different perspective, it was clear that someone’s fear of failure, or a lack of fear, could be the catalyst to their decision making. With this aversion to risk-taking we limit the projects we choose to tackle, our need for experimentation and we’ll likely have a harder time reaching any real breakthroughs due to fear.
Working at a company focused on innovation, our black ops design team became inspired to raise awareness to a topic as polarizing as failure in order to help shift our mindsets. But, in order to approach this problem we needed a simpler goal: get people to start understanding how fearing failure, instead of recognizing failure for what it is, can negatively affect our productivity and success.
With jobs in the tech industry, it’s often hard to step away and avoid time in front of a screen. Between being glued to our phones, using computers, and watching TV we absorb a majority of our content now behind glass. This is a rare and more recent phenomenon that will likely only get worse with time, and with such a saturation of digital content, what is the content that actually gets through to us?
In order to change people’s perception of failure, we knew a post or email would feel too familiar and get lost among the clutter. Instead, we leaned into a more tangible, yet risky, medium for our content — paper. We decided to print a short-form illustrated zine that examines failure through the emotions it evokes, aiming to spark more open dialogs about failure at Dropbox.
These zines were made available to grab at people’s leisure, because we really wanted this experience to feel less prescriptive and more like a natural discovery. We didn’t want to tell anyone how they should react or force any modifications of behavior, but instead bring light to a concerning topic and arm people with a variety of relatable strategies to approach failure the next time it presented itself.
In the early stages of research for our zine, Failure Minded, it became clear that there’s a dichotomy around failure. On the one hand, people praise failure as a stepping stone on the road to success. On the other hand, some view failure as a crippling obstacle that must be averted at all costs. We wanted to try to understand the duality of this topic by exploring how this has affected successful people throughout history. If the people who we deem as successful also struggled with the same emotions we tie to failure, this could help provide comfort in knowing we’re all human and we’re not alone in our experience. This was also to prove a point that failure exists—it’s not something that needs to limit us or be an obstacle when setting our sights on big goals.
Archetypes of failure
To start our research process, I began reading articles about people throughout history who were considered failures. There was a lot of sifting through these articles to find quotes about failure, most of which felt cliché or were one-off examples that didn’t provide any real substance for this project. This was until I stumbled upon a quote from Michelangelo that really resonated with me:
The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aim too low and achieving our mark.
As a creative, Michelangelo fascinates me. I remember learning that when he was commissioned to paint the Sistine Chapel in Vatican City, he had little-to-no experience as an actual painter, which reminded me a lot of the concept of imposter syndrome.
Often in a creative field, when we take on larger and highly impactful projects, especially when navigating problems we may be unfamiliar with, we can feel we’re unequipped to do the job. I think some of us can also feel siloed and that we’re the only ones who might feel this way. I know I have.
After learning about Michelangelo, it was refreshing to know that someone who people idolize as one of the greats also had similar feelings as obstacles to his own success. In fact, he also often gave context to those he worked with that he lacked experience in certain artistic areas, just to avoid being labeled as a failure.
This example felt relatable, and helped me use this model as a launchpad to explore what other human symptoms might arise for people when presented with failure. As I continued, it became clear that some people’s emotional tendencies produce a negative effect, limiting their productivity, while other people actually lean into risk and failure for a more positive result!
In total, we were able to assign four concrete archetypes that felt most present and relatable when dealing with failure: The Imposter, The Saboteur, The Expressionist, and The Enthusiast.
The Imposter: Self-doubting, suspicious, driven
The Saboteur: Pessimistic, avoidant, cautious
The Expressionist: Unconventional, curious, determined
The Enthusiast: Supportive, empathetic, optimistic
Form and failure
Knowing this project referenced a lot of people preceding our time, I wanted it to feel classic and historical in presentation, which was why I chose to work with a vendor to produce a more traditional newspaper-print quality.
Type was also extremely important to me. A newer and more unique serif typeface for the title and main headlines promoted an elegant yet modern experience for the reader. This typeface also happened to be botanically influenced, with its lines relating to the growth of plants, which was an unexpected complement when thinking about how we’re trying to encourage growth and varied perspectives within the zine.
For the illustration work, I was inspired a lot by early surrealism and psychedelic design, specifically for the conceptual absurdity that a lot of this type of work possesses. This style of work feels experimental to me and represents altered states of mind, which felt perfect when thinking through the various emotions we can conjure out of fear. To me, failure, as well as topics like self-defining your own archetypes, can be deeply personal and not something people spend enough time exploring. I wanted each illustration piece to be a reflection of either the fears or the exciting unknowns associated with the process of risk-taking.
An opportunity to learn
Granted, we’re not sharing the bulk of content from our zine in this particular article, but we can share our most important learnings, which we find applicable to anyone who may be struggling with inactivity due to an irrational fear of failure. The first is to recognize that failure is 100% normal. It happens to us all! It’s a completely normal event for any team that is exploring a problem creatively and boldly. In fact, if you’re not failing, you’re probably not aiming high enough. Every failure is another opportunity to learn.
The second learning is when you fail, reflect. After any project, especially a failed one, meet with your teammates for a lightweight retrospective. During the retrospective, a team reflects on what happened in the iteration and identifies actions for improvement going forward. Ask each other honest questions and be candid. Record any learnings that could be applied to future projects on your team or other teams.
Finally, shifting our mindset on failure is a group effort. We’ve all developed certain behaviors around failure. Ask yourself how we can change these behaviors and shift our attitudes towards failure. By doing this, we’ll not only work together better, we’ll take the right risks we need to grow — both as individuals and as teams or companies.
Let’s be honest. In general, failure is misunderstood. The attempt of this entire analysis was only to scratch the surface and leave things more open-ended, to inspire others (you) to continue researching this and better help us all interpret our thoughts and opinions surrounding failure. As a creative, you’ve probably felt the pressures of delivering on a project with a risk that what you produce might not fulfill the desired needs of a client or team, and you’ll fail.
How do you navigate this experience and what are some ways you’ve learned to cope with the fear of failing? We’d love to hear from you.
Introducing the Team Values Toolkit — a new way to design and align on work culture.Illustration by Fabio Benê
Two years ago, a few of us on the Design Research team at Dropbox set out to better understand the qualities of highly collaborative teams. We spent time in cancer research laboratories, university classrooms, music venues, and in the offices and workspaces of many different kinds of organizations observing and interviewing groups that were exceptional at some aspect of collaborative work. These were teams who called each other friends or, in some cases, family. They had enviable working relationships and through their partnerships made tangible impacts in their organizations and communities.
As the days unfolded, we started to notice an interesting practice many of these teams had in common. Namely, these teams were making their own group norms shared and explicit—defining the ways they wanted to be at work and with each other—by co-creating social contracts.
This wasn’t about culture fit — each of these teams had different values and norms. Rather, this was about culture making — the way these groups were taking an active role in shaping and making their own culture.
Enter the team contract
When we came back from this research trip, we started to ask ourselves what would happen if we viewed social contracts as products designed around our needs as a group. What if we engaged in the same discovery, prototyping, testing, and iteration processes that we use to create any product or service, except as a means to develop and strengthen our working relationships?
Since 2017, we’ve been exploring these questions with various teams within Dropbox and beyond. We’ve created a toolkit and facilitated dozens of groups to design their own social contracts. Next month the design team will be launching several Culture Kits — tools that can support you to facilitate the making and shaping of your own culture.
One of those kits, the Team Values Toolkit, is one we’d love to share with you today. The toolkit includes a set of several activities, with instructions that can lead you and your team toward the development of shared values and norms.
Become a values-first team
Creating a team social contract is a way to co-determine and align on your team’s values and working practices: how you want to communicate, make decisions, share information, and support each other. It’s a way to set a better foundation for your team to prosper, based on shared understanding and purpose.
Team collaboration styles and work habits often develop organically rather than intentionally. Processes and interactions formed by most people on a team might not always include everyone. When teams are disjointed around values, energy, or focus, misunderstandings can lead to missed opportunities to connect and thrive.
As we work to make our workplaces inclusive places where people of diverse backgrounds and working styles can flourish, we need to find new ways to give voice to what matters, share power, and co-define our culture.
We believe designing and aligning on shared team contracts, in concert with participatory culture making, is one way we can take shared responsibility for making our work cultures more inclusive. It requires us to update our ideas about what counts as “work” and make space for the development and cultivation of relationships alongside our work tasks, by acknowledging the legitimacy of giving voice to our unique values and working styles.
It’s not always easy work but we believe the products we make and the companies we build will benefit from developing a capacity to make our teams and working cultures more inclusive and aligned.
The Team Values Toolkit is free, adaptable, and made for anyone who wants to make work better. We share our tools to empower and equip you to shape your own work culture.
We can bring the lightIllustration by Justin TranEvery word matters
Every moment of a user’s interaction with your product counts. Every single word in your product’s interface sets your product up to succeed or fail. The words in your user interface (UI) directly influence the decisions your users have to make. The role of a user experience (UX) writer, sometimes called a product writer, is to provide the user of a product or piece of software with a positive and easy experience.
Dark patterns and UX writing
Dark patterns are user interface patterns specifically designed to trick a person into making a choice they wouldn’t want to make. When the words in your product frustrate, shame, or manipulate people into taking actions they wouldn’t otherwise have taken, the user experience fails.
Even if your goal is to create friction with the intent to prevent fraud — say, if you’re in a highly regulated sector — the words in your design set the tone for whether a person will put up with the friction or abandon your product altogether.
You don’t have to write dark
UX writers are responsible for making sure the language is clear, correct, and helpful. It’s better if the language is also inclusive and accessible, and it’s best if it doesn’t unfairly manipulate the reader.
There are times when a writer might be tasked with creating language that just doesn’t feel right. While some writers might think they can’t push back on a client’s requests, that’s not necessarily the case. Here, we’ll take a look at some examples of manipulative language and give some guidance on how to handle it as a writer.
Three places you can startOpt-out links pile on the guilt
The scenario: You’re browsing healthy recipes on a website when a modal or overlay pops up asking if you’d like to sign up for their newsletter.
Your options are:
Enter your email, or
2) No, I hate being healthy!
You don’t want the newsletter, but — well, you don’t hate being healthy, either. In fact, you’re on their website specifically looking for recipes to help you stay vibrant.
If you click the opt-out link, you know you won’t somehow draw ill health toward yourself. But it still feels weird to “agree” that you “hate being healthy.” Signing up for the newsletter isn’t the option you want, and it feels like you’re playing into their hands. You feel manipulated and uncomfortable with either choice.
If you’ve closed a web page in the past year, you’ve probably run into at least one instance of this kind of “confirm shaming.” Sometimes also called “manipulinks,” these manipulative bits of text attempt to guilt you into taking an action you don’t want to take.
Fake door tests lead users astray
Now imagine another scenario. This time, you’re writing for an app. Your job is to make sure the words a person sees or hears when they use your product are clear, concise, and correct. You partner with a product designer and product manager (PM) from the conceptual stage of a project through the post-shipping stages, to craft words for the product.
One day, you’re attending a kick-off session for a new project that’s launching in a month. Your PM says the goal of the project is to gain insight into whether people would be interested in paying more if you offered a particular new feature.
They want to have a modal pop up during the user’s flow, asking if they’d like to try the feature. There should be one Yes button and an X to close the modal.
Sure, you say, sounds great… so… what happens when they click Yes? Does it take them directly to the new feature?
Oh, we don’t actually have the new feature yet, they explain. We just want to find out how many of them would be interested in it. Just say something like, “Thanks for your interest.”
As a user, that’s not a great experience. Sometimes called “false button tests” or “fake door tests,” these tactics to gain insight into users’ interests are also manipulative and can feel like bait-and-switch. But are they dark patterns? Or are they just badly worded (and poorly designed)?
Canceling cancels the cancelation
Now consider this scenario. You’re placing an order online for some food, when your roommate walks in carrying dinner for both of you. You navigate to the Cancel order button when this modal pops up confirming your cancelation.
Are you sure you want to cancel this order? It asks, with the options OK and Cancel.
It’s unclear what either option means. Does Cancel mean you’re confirming the cancelation, or does it mean you’re canceling the cancelation and therefore exiting the cancelation flow? Does OK mean you’re sure you want to cancel, or does it mean you’re OK with continuing the order?
Are they dark patterns or just bad copy?
As mentioned above, dark patterns are specifically designed to be manipulative, to trick a person into making a choice they wouldn’t otherwise have made.
In the first instance, the manipulink is trying to guilt the person into making a decision they don’t want to make. But the user does have the option to choose the link with the guilt-mongering text. It’s annoying, it’s been proven to have poor results, but it’s ultimately just bad copy.
In the second instance, the false button copy (Yes, I’d like to try this new feature) deliberately leads the person astray. They think they’re making a choice that will provide them with one outcome, but they are intentionally given a different outcome. This is a dark pattern… and it’s also bad copy.
In the third instance, the exit modal presents the user with two confusing options. But it’s unlikely that the goal is to keep them in an infinite loop inside the app. This might be a dark pattern, depending on the intent behind the design… but it’s likely just bad copy.
Better copy creates better experiences
Sometimes, improving an entire user experience means changing some of the words in the design. This is why it’s important for writers to work closely with designers, researchers, and product managers.
When someone who’s deeply immersed in the copy signals the need for a change, perhaps they’re seeing something beyond just the words. Keeping the product copy clear and useful can help prevent a project from becoming dark.
Consider how different the manipulink example might be if the options to sign up for the newsletter were something like:
1) Enter your email, and
2) No, thanks
Consider how different the experience might be if the modal with the fake door test made its intention clear from the start. It’s honest and straightforward to simply ask someone if they’d be interested in a feature, and there’s no manipulative copy involved.
In the cancelation flow example, consider how different the experience might be if the modal said something like:
[Keep shopping] [Cancel my order]
UX writers can bring the light
How can a product writer balance responsibility to the bottom line with thoughtful, ethical approaches to the words a user experiences?
Since not every team has dedicated writers, it’s important to note that “product writer” here means the person who is writing the words that will ship in the product. Maybe it’s a dedicated UX writer, but maybe it’s a product designer, PM, engineer, or communications intern.
The point isn’t that only someone with the title “UX Writer” can write their way out of dark patterns. The point is that anyone who is writing product copy should be able to write their way out of dark patterns.
Not every writer feels they can take ownership over the final language decisions that get shipped.
Having the confidence and ownership to push back takes experience and wisdom. It also takes some guts. But as product writers whose job is to make the user experience feel effortless through the words that exist in design, it’s also our job to make sure the words we use are accurate and not misleading.
It’s our job to offer solutions to poorly worded experiences, but it’s also our job to maintain the integrity of our writing by refusing to write copy that deliberately misleads users.
If you’re a writer in a situation where you need to push back, here’s some language that could be helpful to use, depending on your circumstance:
I don’t feel comfortable writing language that misleads users. I suggest we use ___ instead.
This flow seems misleading. How might we get the information we’re looking for without implying the feature already exists?
UX writing best practices typically have the button call-to-action match the verb in the header. This modal would be more clear if the implied action in the title matched the CTA. How about we rephrase it like this: ___?
Once you’ve put some of this language into practice, it becomes easier to hold steady to the goals of UX writing. As a writer, you can maintain the integrity of the user experience you’re creating, while knowing you don’t have to write stuff that feels wrong. The more that writers can help maintain clarity and ease of use, the better for everyone who’s using your product. And for many of us, that’s the ultimate goal.
Your team decided to redesign the onboarding experience for your product. This flow is outdated and needs a refresh. The goal of the project is to increase the number of users who take the key action of your product in the first launch experience. The hypothesis is that by doing so, you would see an uptick in user engagement and retention.
As a product designer, your first step in this process would be to correctly frame the problem. Usually, this starts with a broad design question like, “How might we use onboarding to increase the number of users creating a folder in their first-time use?” This prompt brings up a lot of research and data questions, the answers to which can help you identify where the problem is and what the design should focus on:
[Quantitative] What is the current completion rate for the onboarding?
[Quantitative] How many users are taking the key action?
[Qualitative] How much education do users need for your product?
[Qualitative] What is the job to be done users hired your product to do?
… and so on.
Once you get these answers, then you form a more informed understanding of the problem to develop a better-framed hypothesis. This makes it easier for you to know where to start this redesign.
Questions are everywhere
This is just one example. But for every project, there are a ton of both quantitative and qualitative questions. One thing designers struggle with at both big companies and small is feeling empowered to get answers to these questions.
Is there any past documentation I can dig into to get these answers?
Is there anyone in the company who can get me these answers?
Are there any internal tools I can look into?
Is this information even being logged?
In this article, I have shared some ways Dropbox designers get answers in the problem discovery phase. While the amount of data accessible and the tools vary from company to company, this can spark ideas for tactics you could incorporate into your design process to be more data-informed.
5 ways you can start getting answers1.Look into numbers with product analysts
At Dropbox, we have embedded Product Analysts (PAs) in our product teams. They help to monitor our logging and analyze our data to find insights. To make these insights accessible, they create dashboards using Tableau, which the team uses to look at the funnels, cohort analyses, long-term trends, and more.
Designers work with analysts to understand how to navigate the Tableau dashboards. Digging into these numbers, we are able to validate the project goal or find counter-evidence which can help the team pivot to solving the right problem. Along with Tableau, if digging into large databases and writing SQL queries is your jam, then you can query the tables and pull your own insights!
2.Build user empathy by talking to customer support
Customer support is one function that knows your users’ pain points and frustrations really well. From managing the customer calls and email queries to publishing help articles and responding to customers on forums, they are in touch with your customers 24/7.
At Dropbox, our Customer Experience (CX) teams are spread across the globe. Every product area has a dedicated Product Operations Manager who manages the team of agents and specialists who talk to our users and resolve their issues. Getting to know our CX partners and checking in with them regularly helps designers build more empathy towards our customers. We also dig into some of the CX tools to go deeper into users’ problems.
The first tool, Zendesk, is our ticket management system at Dropbox. Going into the tool and reading through actual support tickets gives us insight into the troubles customers are having. The second tool we use displays the analytics data for our help articles. These dashboards show the traffic we get on our help content and the helpfulness ratings on those articles. This helps us know what issues our users look for the most.
3.Understand how sales teams sell your product
Sales and CX teams are closer to your customers than designers are because they’re talking with them every day.
Sales teams pitch your product to customers and learn about product perception and feature requests. Listening into sales calls and looking at sales chat transcripts can give you a lot of insight into user needs and your brand perception.
At Dropbox, the Sales team sends out regular reports with some of these consolidated insights to the product teams. These reports help us find answers to questions like what is the main reason customers download Dropbox for?
4.Read what your customers are writing
Users write app reviews, fill out surveys on why they are deleting their account or canceling their subscription, and post about your product on social media. Reading through these can give you a better understanding of customer sentiment and product perception.
At Dropbox, we use Appfigures to cross-publish reviews from the App Store and Play Store to Slack. So every time a customer reviews our app, the product teams get that on the Slack channel. Same thing with cancelation surveys and Twitter feedback.
5.Finally, listen to users talk first-hand!
The best way to get qualitative insights into how your users use your product is by talking to them face-to-face. Designers at Dropbox are super-lucky to have an amazing User Research team that makes this happen.
Every other Wednesday, we conduct what’s called a Real World Wednesdaysession. Anyone can sign up and talk to 5–6 users for 15 minutes each and get user feedback on stuff they’re working on. We also use usertesting.com for quick testing and getting feedback from users virtually.
These are only a few ways that help us get answers to questions when the project is in the problem discovery and definition phase. What are some approaches and tools you use in your process? Share your thoughts in the comments.
Tips from a product designer on building valuable partnerships with engineers.
Right after college, I started working at Dropbox as a product designer. What I expected was that my first year working would make me better at my craft — at typography and layout, at asking the right research questions, at constructing intricate prototypes. What I didn’t expect was that so much of being successful as a designer would depend on my relationships with cross-functional partners, and in particular, with engineers.
Eager to learn more, I met with designers and engineers on the Paper team at Dropbox. I asked everyone two questions:
Go back to a time when you had a great experience working with (engineers/designers). What worked well? Why did it work well?
Tell me about a project when you felt stuck or frustrated with (engineering/design)? What was difficult? Why did it end up that way?
Here’s what I took away, packaged up into bite-sized insights that you can take with you into your own design process.
Learn what makes them tick
Resolve ambiguities about how you’ll work with the engineers on your team upfront. Do this by taking the time to get to know them. Make sure to be direct about how you’ll help each other do your best work.
Grab coffee at the start
Early in the design process, sit down with the engineers on your team and learn about how they work. Ask about things like:
What do they expect at hand-off?
How do they like to communicate?
What were their past experiences working with designers like?
What energizes them about their work?
Having answers to these questions can optimize both of your processes. For example, some engineers like designs to be redlined before implementing. Others like to be more ad-hoc and sit down with designers to get the design pixel-perfect. Figure out what works best so you know what to expect later on.
Be desk buddies
If you’re going to be working with a group of engineers regularly, make sure your desks are nearby. It’s a great way to naturally build rapport and have insight into each others’ work. All the scheduled meetings and Slack conversations can’t compare with the spontaneous conversations you’ll have sitting together.
On the Paper team, designers are integrated with their cross-functional teams (engineers, PMs, writers, etc.). Being close by, I get to catch up with the team in the morning over coffee and everyone else gets to peek over my shoulder when I’m cooking up something new.
Give engineers their design hats
Even early on, don’t forget to involve the people that’ll actually be building the thing you’re designing. Engineers provide a unique perspective to design. What’s more, including them in the process will make them better product- and design-thinkers.
Have an engineer in the room
Bring engineers into conversations and share early on, so everyone has context on the goals of the project. If the project isn’t staffed with engineers yet, work with an engineering manager to get at least one on it. Even if they won’t be working on it full-time for a while, you can start looping them in.
Kate Apostolou kicks off projects with a brainstorm to align and ideate together. This way, she gathers a diverse set of ideas and gets everyone excited about a common goal.
Make design visible
Post work in visible places and don’t be afraid to share in-progress work. Waiting for perfection and only sharing close to hand-off makes for infeasible solutions.
When the Paper design team started hosting design sessions on boards by our desks, engineers and PMs felt less intimidated to drop in, and often did, to see what was going on. It made other people on the team feel like the design process wasn’t just for the designers.
Train their design muscles
Invite them to research studies, design sessions, brainstorms, and more! These are opportunities to have engineers understand the problem at hand. These experiences also pay dividends in the future, when they’re able to contribute valuable ideas back to the project.
On the Paper team, engineers are always invited to design sprints. They’re involved in everything from forming the problem statement, all the way down to drawing storyboards. It’s a great way to get everyone motivated by the same user problems.
Get to a solution together
Leverage engineers for more than just implementing designs. They have an intimate knowledge of the product and its inner-workings. Working together will help you converge to a solution that’s both technically sound and user-centric.
Use design as direction
Designs don’t need to be complete for engineers to start work on them. Sharing incomplete designs lets engineers get a head start on building while you’re still ironing out the details. One caveat here is to set expectations around which parts aren’t set in stone. This way, you avoid unnecessary thrash.
As Bjørn Rostad says, “the best hand-off is no hand-off.” Iterating on design while engineers build creates a back and forth that doesn’t stall for anyone. It’s one smooth transition from ideation to implementation.
Don’t put all your eggs in one basket
It can be easy to prune the ideal solution for weeks before handing it off to engineers. Instead of having your one idea shot down because it takes too long to build, present a range of options so you can compromise on something feasible.
Joey Grillo describes this situation as “MacGyvering.” This is when design comes to the table with many explorations, and engineering does the same technically. Then, the team works to fit together a solution that both meets users’ needs and is also within the project’s technical constraints.
Think like an engineer
Build your own repository of technical knowledge. If an engineer says no to an idea, push back and use the opportunity to learn how the system works. Figure out the realm of what’s possible and what’s not.
David Stinnette always asks engineers to explain the technical constraints that exist. He uses it to find room for negotiation and propose solutions that engineers may not have thought of. Plus, it’s helpful to build an understanding of the way the codebase works for future projects.
Spot the edge cases
It’s hard to predict all the different edge cases and unique logic a design might have when you’re just mocking something up. Instead of leaving engineers to deal with edge cases when they’re implementing, work with them to determine what they are and how you’ll solve for them.
Early on, I’ll create and share a “design explorations” doc with wireframes, workflows, or low-fidelity mockups. Engineers will pepper the doc with questions around micro-interactions, empty states, error messages, etc. — things I usually haven’t thought about yet. With these questions in mind, I’m able to account for an extra level of detail in the next iteration.
Own communication, don’t expect it
In the implementation phase, good communication ensures that great design makes its way into the product. Instead of waiting for engineers to communicate about their progress, set up opportunities for that to happen.
On larger projects, slice a project into smaller one-week or two-week milestones. While this might take a lot more work upfront, it creates accountability. It also forces everyone to check in without having communication fall into any one person’s responsibility.
Because the Paper Growth team works on experiments, their projects usually have a timeline of one to two weeks of design work and one to two weeks for engineering work. With a small scope and short timelines, the team avoids long communication drop-offs. Try modeling larger projects the same way to reduce the risk of radio silence.
Carve out time to share
Make a regular habit out of sharing designs that are works-in-progress at team meetings. Also encourage engineers to demo if they’re able to get something working ahead of time.
Anbu Anbalagapandian, an engineering manager, created a bi-weekly meeting for sharing designs. The engineers on her team were excited by getting a sneak peek into what they’d be working on in the future. The meetings also gave designers time to collect feedback from the team.
Just sit down together!
Take the initiative to stop by an engineer’s desk or schedule an informal work session. These reduce back and forth and build the habit for check-ins outside of meetings.
Across the board, both designers and engineers on the Paper team found informal check-ins to be helpful. One way they did this was to both sit down at a computer together and walk through the implementation.
Don’t forget the final mile
The design process isn’t over just because you’re no longer mocking up or prototyping. Getting across the finish line means making sure that what’s built is high quality and that everyone understands the value of doing so.
Bug hunt together
Instead of leaving tickets or Slack-ing back and forth about polish, save time by combing through the experience together. You can be precise about the implementation feedback you give and work through any design details together.
Bryan Guillemette emphasized that as an engineer, he finds these informal QA sessions really valuable. Designers catch bugs core to the user experience and engineers are able to fix many of the bugs on the spot.
Prioritize design fixes
Understand the time constraints for a project and figure out which pieces of design are most important to get right for each release. Maybe it’s okay to release to 10% of users without having all the spacing perfectly tweaked, but maybe getting the right error messaging in is crucial before releasing to everyone.
Emily Lutz is an engineer who likes working with designers to create a prioritized polish list. This way, she’s able to focus her time on the most important parts of the design before an early release.
These tidbits are brought to you by both designers and engineers on the Paper team. They reflect the best of our experiences, as well as the places where we could improve. During your next project, try out a few of them to bring engineers closer to your design process.
After all, designer, engineer, product manager, whatever — we’re in it for the same reason. We’re all striving to make great products to do right by our users. So, the better we are at working together, the better we’ll be at doing just that.
Thanks to Justin Tran for the illustration, as well as Andrea Drugay, John Saito, Ryhan Hassan, Kate Apostolou, Emily Lutz, and Kurt Varner for their thoughts and feedback. Special thanks to Justin Hileman who propelled this process with an internal guide for engineers working with designers.
A few months ago, our Internal Communications team at Dropbox was getting ready to launch a new intranet for employees. As a UX writer, I worked closely with them to make sure the user experience (UX) copy was clear and that the navigation felt effortless.
But we knew we had to do some user research before launching it. Design research is the heart of UX, and it’s a philosophy upon which Dropbox Design is built. We wanted to be sure we were applying our design principles and best practices to internal tools as well as to the external Dropbox product.
The information in the new intranet was highly confidential, which meant we were somewhat limited in our research scope. We needed real insights from real Dropbox employees; remote testing with people who didn’t work for Dropbox wasn’t a viable option.
A new approach
I suggested we run a research session based on a style our Design Research team uses. With the help of Senior Design Researcher Paige Bennett, we pulled together a 2-hour session that I facilitated. We were able to gain insights quickly and put suggestions to use right away. And it was extra-exciting to me, because as a writer, I don’t usually run research sessions. I learned a lot about facilitating research, and I’m excited to do more in the future.
Whether you’re looking to learn from internal or external people, the process is the same. Here, I’ll walk you through it, so you can do something similar — no matter who you are or what your day-to-day role is.
The problem: You need research, but you’re not a researcher
If you’re at a company or on a team where you get to work directly with design researchers, consider yourself lucky. You already know the benefits of having research insights at your fingertips. You can work closely with your research partner to create a better experience in your product.
But not every team is lucky enough to have a dedicated researcher, and not every company has the resources to staff a Design Research team. Sometimes user testing is up to the designers, writers, marketers, or anyone who can squeeze it in.
Fortunately, there are plenty of options for basic, online user testing, like UserTesting.com and UsabilityHub.com. But the insights gained from unmoderated or remote testing can sometimes be limited.
For one thing, designers and writers sometimes get concerned that their prototype isn’t polished enough to test. It’s easier to explain a rough concept in person. Also, you can ask follow-up questions more easily in a moderated session than you can during a remote or unmoderated test. Sometimes, only live user testing will do.
The solution: We call it Real World Wednesdays
Real World Wednesdays (RWW) is a rapid, speed-dating style research session. You can do it with internal employees, external people, or both. It’s a great way to test mocks, works-in-progress, and half-baked concepts with users. Plus, it saves time, and it’s a fun way to get real, live, valuable, high-quality feedback.
John Saito mentioned it briefly in his blog post, How to stay scrappy. I’ll walk you through how to do it in more detail, so you can create your own live, in-person user testing with real humans.
From Paper to the real world
Real World Wednesday developed from a speed-dating concept proposed by Aruna Balakrishnan, Design Research Manager at Dropbox. The idea was fleshed-out and introduced to the team by Mira Rao, Senior Design Researcher, and Leona Dondi, Design Researcher, on the Dropbox Paper team. The designers and researchers on Paper wanted a way to quickly and iteratively test mocks, so they started doing fast, lightweight research sessions every other Wednesday. Our Design team practices No Meeting Wednesdays, and a lot of us have found we can use the unstructured time in creative ways.
“Real World” meant they’d be getting feedback from real people. They’d also be getting feedback earlier and often, since sessions ran bi-weekly. It was frequent, scrappy, and sometimes kind of messy. It turned out to be a great way to check in with users and let real people be part of the design process.
Once RWW proved its success with the Paper team, they started hearing from other teams who wanted to do something similar. So the sessions expanded, other teams joined, and more people started participating. Some of our teams in other cities even created their own versions, with unique twists that suit their needs.
How does it work?
We usually compare it to speed dating or speed networking. For an hour and a half, five participants give feedback to five different research groups. You can adjust the numbers to suit your own research style, but we’ve found five gives us diverse feedback with a manageable number of participants.
We gather in one of our collaborative spaces (a giant, open meeting room) and sit at five tables. There’s one participant (the “user”) and two “researchers” at each table. Each user talks with a pair of researchers for 15 minutes, then they move on to the next table. We repeat this four more times to fill out the hour and a half.
After we’ve thanked the users and they go home, we debrief with the other researchers. Afterward, we synthesize their input with our product teams and iterate on our projects.
So that’s a total of five “users,” 10 “researchers,” and one or more facilitators. The setup looks something like this:
Example of a table setup for Real World Wednesdays
What kind of things can you test?
Because these are scrappy, short research sessions, they’re best suited for things that don’t require a high degree of confidence. For instance, it’s a great way to get iterative feedback, but not the right place to make important product decisions. Here are a few examples of great candidates for RWW-style testing:
Feature and flow comprehension: Do users understand what this does?
Discoverability and flagging user questions or concerns
Language and copy feedback
When we tested the intranet, we focused on the information architecture and language. The researchers were all testing the same project, but since we were looking for different insights, we used different research approaches. For example, one table did a card sorting exercise for the structure, while another did a highlighter test for the language.
You don’t need to have anything polished or finished to put something in front of users. In fact, the earlier in the process you can get feedback, the better. You can test anything from hand-drawn sketches to printed-out mocks, or fully built experiments that users can play around with.
Do I have to do it exactly this way?
Not at all. The setup I just outlined is a basic framework for Real World Wednesday. There are a lot of variables in a research project, which means you can adjust things to suit your needs. For example, you could:
Have fewer or greater numbers of participants, or researchers, or both. For instance, you could have pairs of participants or even trios. Some people refer to these as “micro-focus groups.”
Use a longer format, like 30 minutes instead of 15.
Try a remote session. Set up five conference rooms, each dialed in to a scheduled video call with a different participant. The researchers swap rooms every 15 minutes. The participant stays dialed in but who they’re talking with changes.
Why do a Real World Wednesday research session?
It’s an easy way to get great feedback from real people. You can get outside your bubble and get high-quality feedback right away.
It saves time. Through rapid testing, you don’t have to sit in research sessions all day.
Anyone can participate in or run a session. Anyone! Designers, PMs, engineers, researchers, UX writers, and more.
It de-mystifies research. The conversations are only 15 minutes, so even if it’s a bad conversation, it’s over quickly. The short, lightweight style makes research a lot less scary, and it gives you a lot of practice in a short amount of time.
It builds confidence. It’s a great way to get practice talking with people and becoming more comfortable with it.
It’s fun. Really!As you build confidence talking with people this way, and as research itself becomes less intimidating, it can be fun to learn about other people, their daily lives, and how they interact with the world.
The important thing to remember is this is a framework, not a must-do. As Senior User Researcher Christopher Nash says, “Real World Wednesdays is one solution, not the only solution.” It can be a great jumping-off point to more in-depth testing, and a great way to get experience if you’ve never done research before.
How to do it, step by stepBefore anything else
Determine who your participants should be
Recruiting participants is often the thing that takes the most time.If you want to find out your customers’ needs, you’ll need to put some time into figuring out who those people are. When testing the intranet, we had a built-in audience, which made finding participants easy.
“But if you’re doing this in the real world,” says Nash, “you’ll want research participants who can identify with the problem your product is solving. … For example, you wouldn’t want to test your concepts for a design tool with people who aren’t designers.”
You’ll want an audience that’s going to have enough context that they can identify with what each of the research duos will be showing them.
Send out a call for participants
Once you’ve determined who the right people are, then think about ways to connect with them. You might need to get creative. Try your friends and family networks, social media, Craigslist, professional forums, Slack communities, conventions, meetups — or anywhere else your potential audience might hang out, either in person or online.
Consider offering participants an incentive for their time, like a gift card or pizza. We brought fresh doughnuts to employees when we tested the intranet — a treat we don’t usually have in the office — because we were testing first thing in the morning. Coffee and doughnuts helped get everyone off to an energetic start.
The week before
You’ll want to do some prep work before running a Real World Wednesday. The week before your session, here are things you’ll want to do.
Find a space
Secure a good space where you can conduct the sessions. If you don’t have an open-space collaborative area, try a large conference room, or even a cafeteria. You’ll meet in groups of 3, so make sure you have separate areas where different people can gather.
Plan for 2 hours of research time
Each session is 15 minutes, and you’ll have a few minutes in between sessions to rotate. With introductions at the beginning and thank-yous at the end, the whole thing takes about 2 hours.
Send out a call for researchers and buddies
Let your team know you’re going to be running a research session, and find out if people have projects they’d like to test. There are two people per “research team.” One person is the “researcher” who asks the questions and guides the participant; the other is a “buddy” who helps take notes.
Ask your research duos to decide what types of tests to give
The fun part is that you can run several different tests at the same time: each research duo can run a different type. For the intranet research, we did two tests: a highlighter test and card sorting. But there are many other types of tests you can run, depending on where you are in the development process and the insights you’re hoping to gain.
Create a sign-up sheet
Have each researcher duo sign up for a slot and note the type of test they’re going to be conducting. Here’s an example of a sign-up sheet created in Dropbox Paper:
Have your research duos list out the questions they want to ask
Some people call this a “discussion guide,” but it doesn’t have to be overly detailed. It’s a list of questions and topics to cover with each user, that you can refer to during the testing. You can write out the questions, or create an outline of topics. Decide the kind of feedback you want to get, and the questions you want to ask. Writing a discussion guide is also an excellent way to prepare a brief explanation of the project.
Set up the room
Get to the space early so you can set things up. You’ll want to have the following on hand:
A timer (or a charged phone or tablet with a timer app)
Highlighters and pens
Incentives (gift cards, pizza, whatever you like)
Business cards to hand out after for follow-up questions
Before participants arrive
Give your researchers and buddies an overview of the game plan.
Make sure your researchers and buddies have multiple printed copies of their prototype, mocks, wireframes, copy doc, or whatever it is they’re testing.
Hand out name tags.
Before the testing starts
Introduce yourself and your researchers and buddies to the participants and thank them for coming. Give them a quick overview of the sessions.
Each session is 15 minutes.
The facilitator will give a 3-minute warning at 12 minutes.
At 15 minutes, it’s time to rotate. The participants move to the next table, while researches and buddies stay where they are. Allow a couple of minutes for everyone to rotate.
The facilitator announces when the next 15-minute round starts.
Remind the participants they don’t need to have specialized knowledge for anything they see. If they need context, the researchers will provide it. It’s also helpful to make sure participants know that honest feedback is the most useful, and that there are no right or wrong answers.
After the testing
Thank your participants. Hand out your incentives and business cards, and walk them out.
Debrief with your research duos on how the session went.
Did they get helpful feedback?
Were there any surprises?
Do they know what to do now?
Tips for testing
For people who aren’t used to conducting research sessions — or facilitating them — there are a few things to keep in mind. Interviewing people can be intimidating, but with 15-minute sessions, you’ll get a lot of rapid practice. Remember to always ask permission before recording anything, and try to listen way more than you talk. Here are a few other tips:
Make sure each researcher has a note-taking buddy
Don’t try to conduct the interview and take notes at the same time. The team can switch up roles in between participants, so each one gets a chance moderating and taking notes. Set up a note-taking doc ahead of time. You can copy your discussion guide, and adapt it to make note-taking easier.
Capture what the users say, not what you think they mean
Try to record what people say in their own words. If you’re testing a prototype, try to capture what they do: “Clicked Submit” or “Dismissed dialog without reading.” You’ll have time to analyze and make sense of it all later. Quoting a user word-for-word can be a persuasive element of research.
Treat your users like experts
You’ve invited people to give you their thoughts, so take the time to listen to them well. Starting on a warm and welcoming note helps a lot. Be polite and friendly. Don’t interrupt them or put words in their mouth. Their insight is invaluable, so treat them like experts and don’t correct them.
Use regular language
Sometimes we get stuck in a bubble when talking with people at work, where we know the internal projects and processes well and don’t have to describe them. There can be things we don’t think of as exclusive but that are jargon, like design sprint or copy doc. Use clear, plain language, especially when referring to projects, processes, or products that people might not be familiar with.
Use silence as a tool
As Design Researcher Marian Oman says, “This can feel awkward at first, but be patient. Wait for participants to answer, and don’t rush to the next question.” If they end up on a long tangent while talking, you can guide them back to something you’re hoping to get feedback on: “What do you think about this section over here?”
Use “Why?” and don’t assume anything
Try to understand the reasoning behind their thoughts. Ask them to explain their reasons. Don’t assume you know what they’re going to say, and don’t assume you know what they “really” mean. Ask “stupid” questions, and ask for examples if you need to. Marian suggests saying, “I think I understand, but can you tell me more about why that’s important to you?”
Avoid leading questions
Leading questions are those that influence the user to give a single answer. Try to keep things as open-ended as possible. Instead of, “Was it easy to find the support you needed in the help center?” say, “Tell me about how you reached the help center.”
Rotate the order of your different versions
If you’re having users compare different versions of the same thing, mix up the order in which you show them. So User 1 sees Copy Table A, then Copy Table B. User 2 sees Copy Table B, then Copy Table A.
Do an immediate debrief
After you’ve run through all of the sessions, regroup with your research duos. Ask if they got the information they needed, if there were any surprises, and if they know what to do next. “It can be short, if needed,” says Paige, “but it’s necessary for capturing things while they’re still fresh.”
Now, you try it!
Research doesn’t need to be scary, intimidating, or something you can’t do just because you’re not a design researcher. With some forethought and logistical planning, anyone can run a research session.
I hope this post inspires you to create new ways to learn from your potential users and customers. If you have suggestions or tips of your own, please comment and let us know.
I live and breathe music. The moment I’m out the door in the morning, I’m finding the album or playlist that I’ll be listening to on my commute. And once I’m in the office, if I’m not talking to someone or in a meeting, I’m most likely listening to something while working. Music fuels my creative process and I can’t work without it. I’m listening to music now as I type this post. For those of you who don’t know me, I’m an Associate Creative Director on the Brand team. I lead a small team of amazing interactive designers focused on Dropbox.com.
At Dropbox, we build products that help remove the blockers of collaboration and coordination so you can get work done. So we wanted to create themed playlists just for those moments when you need to be productive or inspired. Each month we’ll put up three playlists based on the themes of Focus, Flow, and Creative Energy.
FlowArtwork by Justin Tran
Never distracting, but never dull. This lively playlist spans a variety of genres old and new — from the incredibly smooth track “Hands” by Octavian to the folky soulful sounds of Micheal Nau’s “When.” Sure to keep your mind moving while you flow through the day’s work.
When you need to unleash your best ideas in a brainstorm or tap into your inner artist, Creative Energy’s got you covered. This compilation includes cuts from artists like The Japanese House and Glen Campbell. Guaranteed to keep you inspired while you transform problems into creative solutions.
No playlist is complete without some cover art to go along with it. Each month will feature art from a different creative with their own take on each playlist theme. The format is pretty open and we’re excited to see what’s expressed each month through illustration and photography. This month was designed by our very own Justin Tran.
Fun fact: Justin sketched this month’s artwork on his iPad Pro with an Apple Pencil using Procreate. We also collected inspiration and reviewed the artwork using Dropbox Paper, and the process couldn’t have gone any smoother. If you haven’t used Paper yet to collaborate with someone, we highly recommend it.
Let us know what you think
We’d love to hear what you think! Leave a comment below letting us know if these playlists have helped inspire your workflow. Post the music you love to work to. And if anyone has read any interesting articles on the science behind sound and concentration, please feel free to share so we can make these even better month by month.
True or false? To be effective, growth teams have to always be working rapidly: iterating, shipping and moving to the next “win.”
At Dropbox, the Growth Design Team has learned that while this statement is often held as the ultimate doctrine of growth, there are times when slowing down is not only necessary but streamlines efficiency and findings.
1. Spend time getting to know your user
Growth teams tend to start by comparing two versions of an experiment (A/B tests) to determine what experience is most successful. But running a full-length A/B test takes time to design, build, and collect results.
Our Growth team recommends starting with research and following a traditional design process: discover, ideate, refine. This will help you understand your user’s goals, motivations, and needs. While it seems like this process requires more time up front, it will help you be more thoughtful in your approach to experimentation.
How did we do it?
We’re Constance and Shirley, a designer and researcher embedded on Dropbox’s Growth team. Our sub-team’s focus area is the user’s first experience with Dropbox, right when they are deciding which Dropbox plan is the best fit for their needs.
Like most growth teams, we started by rapidly shipping experiments with the goal of building on those that were most successful. Over our first few months on the team, we ran a handful of different experiments, which didn’t result in any conclusive results. We were back at square one.
After talking with our team, we realized we didn’t have any knowledge about our new users and their intentions when they come to Dropbox. We decided to pivot away from running more experiments and instead conduct a series of qualitative interviews. We realized the way we framed our plans didn’t resonate with users. We then used these research findings as a basis for future experimentation.
Before we launched more experiments, we also went back into research to help us determine the best design solution. Our team’s typical process is to run multiple design approaches as an A/B test. Instead, we ran a quick round of usability testing on UserTesting.com to identify which approach resonated most with potential users. We had a decision on design and copy within a week, saving us time that would have been otherwise spent building out an A/B test.
An overview of the journey our users go through to choose a plan2. Bring in your cross-functional team early
It’s tempting to skip this step because it can be a pain to coordinate everyone’s calendars. Resist the temptation! Bring in cross-functional partners early to call out potential technical or business blockers. This will save your team significant time and money in the long run.
How did we do it?
When we were kicking off our ideation phase, we hosted a brainstorm session. We asked for at least one person from each of the following roles to attend: engineers, product managers, growth managers, product marketers, customer support, design, research, and analytics. We encouraged everyone to contribute their different perspectives, and, most importantly, identify any potential blockers. The solution that came out of that brainstorm was one that would be a positive user experience, not technically difficult to implement, and a large business win.
Ideation brainstorm with cross-functional partners3. Take time to learn why an experiment was successful
Traditionally, growth teams learn from their losses and iterate to make future experiments better. We believe it’s vital to learn from your successes. If you can understand why an experiment was successful, it will help you create stronger experiences in the future.
How did we do it?
We ran an experiment designed to improve on our goal of helping our users choose the best Dropbox plan for their needs. By all measures, this experiment was a success: it exceeded paid start rates by 3x and had an 88% completion rate. However, when we debriefed internally, we only had hypotheses on why it had performed so well. We sent out a follow-up survey to better understand the root of what made the experiment successful. The survey findings also gave us a qualitative metric to use as a benchmark, so that we can track our continuous improvement on how we guide new users to different plans.
Now that you’ve mastered the thoughtful approach, let’s learn when to be quick!1. Don’t wait for the perfect solution
While our team was focused on running experiments, our company was also developing a segmentation model that would predict which plans are the best fit for certain users. Rather than waiting to execute once the model was developed, we decided to run a series of experiments aimed at this exact goal. The intention behind this was that any learnings are good learnings. We decided to test a more manual approach, where we asked our users a series of questions about themselves, to inform a plan recommendation. This provided learnings we could act on, while we waited for the model to be developed.
A manual approach to help users choose a Dropbox plan2. Don’t be afraid of running parallel experiments
If you’re working with a large enough traffic size, try to run parallel experiments. Doing so will help you learn at double the speed, and you don’t need to wait until the first is complete before running the second. Just make sure that you understand why one might be more successful than the other, so you can build on it in the future. Our team decided to run parallel experiments to move quickly. We then came up with a cohesive solution that took into account both experiment learnings.
3. Leverage existing components to save time
At Dropbox, our team always tries to design thoughtfully. However, when a team needs to move fast, component libraries can be their biggest asset. Building new components takes additional time and resources. Our team leveraged existing illustrations for our first experiments. This gave us time to evaluate the success of our experiment before investing the time in creating new illustrations.
Now it’s time to experiment!
We’ve found success on our Growth team by knowing when to move quickly and finding those moments to move more thoughtfully. Utilizing both has helped us build more successful experiments. This has resulted in a better, more cohesive experience for our users.
We’d love to hear from you! As you think about making improvements to your process for the new year, what are some ways you’d like to move thoughtfully? When are times that you have intentionally slowed down? What did you learn? Share in the comments below!
The Dropbox Brand Studio recently kicked off I Love Your Work, a semi-regular event series dedicated to creative appreciation and good conversation. For each event, we choose someone whose work we love, and invite them to join us for a conversation with folks in the creative community.
Raising Up the Dead, with NYT editor Amy Padnani
A few Tuesdays ago, we gathered at the Brooklyn History Society to speak with Amy Padnani, the New York Times editor behind the award-winning Overlooked series. Overlooked tells the stories of remarkable people who never got a Times obit. Obituaries function as the “last word” on who gets remembered, and up to now they’ve been dominated by white men. We love Amy’s work because it offers a richer perspective on the narrative arc of history — one where women and people of color play a meaningful role.
In our conversation with Amy, we learned what it was like to convince the New York Times to acknowledge they’d overlooked key historical figures (answer: relatively smooth, now that the Times has a dedicated gender editor); why obit writing is the purest form of storytelling; and why Amy’s second-favorite obituary is the story of Frances Gabe, inventor of the world’s only self-cleaning home.
We’ll share a transcript of the interview soon.
We believe that showing appreciation is a radical act. So we’d love to hear about someone whose work you love. Write your person a letter outlining how they’ve inspired, moved, or transformed you. Then send it to the I Love Your Work team (ILYW@dropbox.com)to keep the conversation going.
Stay tuned for the next I Love Your Work
We’ll send details about the next I Love Your Work in the new year. In the meantime, we hope your holidays are filled with loads of appreciation, and good conversation.