Last summer I switched teams at Facebook. My first project seemed simple enough: redesign the sign up flow for Facebook Lite, an app for low-end Android phones.
I couldn’t wait to start the project. It seemed like a textbook design problem. “Reduce confusion and friction for people signing up for your product.” Got it.
I did what many of us tend to do when we start on a problem solving exercise as a designer: I went back to my desk and dove in. I read through UX research reports, tested other apps, and eventually put together a very solid proposal, or so I thought.
When I met with the team I expected them to be blown away by my designs. Instead I had run to the finish line of the wrong race.
My initial designs violated three fundamental commandments of doing work as a new designer on a team:
- Build on the team’s knowledge from previous projects
- Have a strong hypothesis
- Know what success looks like for the team
By ignoring the knowledge the team had learned in the past, I managed to create one of the most context-free, unscientific, and useless designs the team had seen.
"I wasted time playing in Sketch when I should have been asking questions about how we got where we are today."
I didn’t fully understand the goals of the team, which meant that I couldn’t articulate why we should build my proposal in a way that would resonate with the team.
As designers, it’s easy for us to jump into the work without fully considering the historical context and what a successful solution should accomplish.
Maybe you can relate. You work hard on a project only to be told that you skipped a crucial step, forgot to ask the right questions, or completely missed the goal of the project.
It’s like being told you put your belt on, but forgot your pants.
Once you know more about the history of your team’s work, you’ll learn about their goals and how they measure success. Every team has metrics that are important and if you ignore them, you might as well be speaking a different language.
When everyone is on the same page, the team can smoothly transition to a healthy collaborative environment. Teams produce better products than lone wolf designers.
To create a collaborative environment and arrive at better design solutions, I’ve learned to ask three simple questions at the start of every project.
1. How did we get here?
Understand how your product and team got to this point. Even if you are working on a new product, there is a lot you and your team can learn from asking these questions. Get lunch or coffee with some members of the team and ask them questions like:
- What are some of the major milestones the team has hit?
- What project are they most proud of? Why?
- What projects do they want to work on, but haven’t had the chance to get to yet? Why?
There are a lot of factors that shape the path of a product. One of my favorite ways to explore that history is by looking at the visual changes that have happened over the years. Facebook designers share their work on an internal website where you can scroll through the years of work that were put into a product. It doesn’t tell the entire story, but it’s an eye-opening exercise and can give you some good questions to bring back to the team.
Document what you hear from the team to help others who join in the future get up-to-speed on the valuable knowledge you glean. People should understand what the project was, why you worked on it, and what the results were.
2. What’s our hypothesis?
Having discussions about the team’s hypotheses are a great opportunity to align the team and flush out assumptions.
Once you are ready to write your hypothesis, answer these questions:
- What’s the change?
- Who does the change impact?
- Why are you making the change?
- Where can you document the hypothesis so everyone can easily access it?
This outline of your hypothesis serves as a guide that you can revisit as you move into a design phase. You can evaluate whether the proposed designs will give you the data needed to make an informed decision.
My team happens to communicate through Facebook Groups. This allows us to have discussions in the open where everyone can contribute. It doesn’t matter what tool you use for documentation, but it’s helpful if it’s a common place for collaboration.
3. What does success look like?
Every goal has metrics that are associated with it. These metrics can range from “decrease the number of error messages” to “increase the number of people who say they’d recommend your product.” As a team, you should be able to answer the following questions about those metrics before starting a project:
- What metrics will you look at?
- What magnitude of change are you expecting?
- If you don’t hit that number, what would the next steps be?
- If you do hit that number, what would the next steps be?
If you wait until you have results back to define success, it’s easy to loosen your definition and launch something because you’ve already worked so hard on it.
At Facebook we have a robust set of tools for monitoring metrics. However, interpreting these results is not always black and white, so my team sets aside time each week to discuss the results. These meetings are cross-functional and give people the opportunity to talk about success when results fall in the grey area.
Defining success at the beginning of your project ensures that you’re headed towards your ultimate goal: making sure people who use your product are having the best experience possible.
Look back to look ahead
The history of a product gives you a chance to see the full picture. It stops you from proposing solutions that have been tested before, helps you understand what design constraints there are, and reveals the decisions that led to the current iteration of the product.
Thanks to Tanner Christensen, Jonathon Colman, and Jasmine Friedl
This article was originally published on Jason's Medium page.
