Questions To Ask As A New Designer On The Team

Posted 1 month ago by Jason Cashdollar

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:

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:

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:

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:

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.

Product designer at Facebook. Say hi on Twitter and follow my writing on Medium.

Related Posts

Collaboration between designers and developers is essential for creating great products. Every company has different organizational structures for designers and developers. Some companies have designers and developers on two separate teams. Those development teams may also break up developers in sub-teams as well. For example, they may separate by front-end developers and back-end developers. In other companies, designers and developers… Read More →

A good product is a lot about the problem that you pick & the ideas that you implement. But a well-sorted & deliberate design-development process can play more than a handy role; ironing out quite a few wrinkles that can cause unnecessary escalations and ad-hoc duct-taping later during the execution phase. “As designers, we are the guardians of execution and… Read More →

A mechanical engineer by training, I’ve always chaffed at using the word process to describe something as messy and nonlinear as design. At MIT, I learned about processes for solving problems like how quickly heat moves through a block of metal, or how to calculate the impedance in an electrical circuit. To me, a process is something with a set… Read More →