How to Ace the Dreaded Whiteboard Challenge

I can always tell when interviewing season is upon us. The number of “Wait, what is a whiteboard challenge?” and “Oh, my...how am I supposed to get through this?” questions increase substantially.

My inbox is filled with subject lines like “WHITEBOARD CHALLENGE????” and my video discussions filled with sighs or silent contemplation on whether or not UX was the right career choice.

Yes, the whiteboard challenge can be a dreaded and anxiety-ridden experience, but you can also turn it into a fun, enlightening exercise.

Jump to

• What is a whiteboard challenge?
• What am I supposed to do?
  • Research portion
  • Design portion
  • Miscellaneous

Okay, so, you've scared me...what is a whiteboard challenge?

Imagine the following scenario: you just arrived at your in-person interview. You have been looking forward to this for the past week. Exciting thoughts of new opportunities and twinges of nervousness rush through you. You meet the first few people. The interviews are going well. There’s some nice conversation. You don’t feel like you’re in an interview, you feel like you are part of the team. The vibes are good.

Suddenly, they slide a piece of paper in front of you. It has a vague prompt about their company. You take the whiteboard markers being handed to you. Time slows down. You hear the terrifying words:

Somehow, you nod your head. All too quickly, you are left in a room, alone, with your racing mind.

This is a whiteboard challenge. You don’t always know it will happen. There isn’t a 100% guarantee. But they are becoming more and more common in the UX research interview process.

Essentially, your interviewers will give you a vague prompt and want you to give them an idea of your process. This allows them to evaluate how you go about approaching a problem in a “real life” setting, beyond your curated portfolio. Companies are increasingly valuing employees’ thought processes over their qualifications.

Understandably, this can be a really difficult experience, which is why you should practice beforehand! Whiteboarding your approach is a great skill to have in general.

Getting ready to start a new UXR job or role? We’ve got an onboarding guide to make your first day, week, and month a breeze. Snag it for free here.

Back to top

What am I supposed to do?

Whiteboard challenges are about showing a company how you process ideas. So it wouldn’t be useful to explain how exactly you should go about one. Instead, I’ll give you a framework for you to apply to your experience.

One thing I would encourage, before you read on, is to jot down your own “thought process” for approaching a project. That way you have an awareness of how you currently think, and can add that to the below framework in a way that works for you. I follow these steps:

1. How do you currently approach problems?
2. What is the step-by-step process you currently use when faced with a project?
3. What about that process would you like to improve?

My whiteboard process

I'm a UX researcher, but I do include a separate portion here for UX design. In addition, this process can be applied to both generative (discovery) research and usability testing, as well as any other methodologies that would make sense given the statement.

Adapt this process to make it your own, unique method. It is completely moldable, and should be changed however you see fit.

During this challenge, one thing I can’t stress enough is:

It may feel as though companies want you to come up with the perfect idea in an impossible amount of time. But really, they just want to understand how you approach a problem. They don’t particularly care about your solution, and, if they do care that much...run.

Back to top

Research portion

✔ Understand the statement

You’ll usually get a piece of paper that states a goal for the company. They may want to try some new feature, innovate a product, or make a major change to the current offering. The prompt can be just a few sentences long, or contain more robust information (timelines, participants, questions that need to be asked). Make sure you understand what’s written before you grab the marker.

✔ Define the problem

The statement generally does not consist of a problem, but more about what the company wants to accomplish. Restate this into a research problem: What is the company trying to learn, at a high level, and what problem is the company is trying to solve?

✔ Identify potential business impact

How could doing research on this problem impact the business? What are general KPIs—such as retention, acquisition, growth, monetization, innovation—to watch? Tie your research back to business. In this step, I also mention how I would like to meet with internal stakeholders, to ensure we are aligned.

✔ Determine the research objectives

Write 3-5 objectives based on your research problem. We want to be able to answer these at the end of our research project, and, with these objectives, we want to be able to address the overarching problem statement.

✔ Decide on your methodology (and reasoning)

What methodologies are you going to use to get insights that help you solve the larger research problem, as well as smaller objectives? If you're trying to understand customers, interviews are phenomenally helpful. If you're trying to evaluate a product, usability testing is key. Just make sure to give your reasoning behind why you chose that given method. More than one is fine (see below for more information).

✔ Think about which participants to recruit

I usually take a stab at a general demographic the company might be targeting (which is why it's important to do some research beforehand). I will also include information such as the number of participants and whether we'll conduct in-person or remote sessions. Finally, I talk about recruiting processes, and what I have used in the past in terms of tools, agencies, or internal recruiting.

✔ Include some sample questions

I will usually write down some overarching framing questions, so they get an idea of how I form questions (which is an important part of being a researcher). I use the TEDW approach (“talk about,” “explain,” “describe,” or “walk me through”) for generative research. For usability testing, I’ll write some sample tasks instead.

✔ Touch upon analysis techniques

I like to talk about how I summarize the research and how I do recaps with teams after each session. I will also include processes I use, such as brainstorming sessions, affinity diagramming, and insight tools I have used in the past. Lastly, a stakeholder insight report and presentation. It's important that we take this research and make it actionable. That is what companies hire us for!

✔ Explain some potential expected outputs

I have found interviewers really appreciate this step, because it helps you tie the output back to the overall objectives and research problem. For example, by creating personas and customer journey maps, we can more deeply understand the customer, and start prioritizing the roadmap based on these needs or pain points.

✔ Write down any biases/hypotheses (optional)

If time permits, sometimes I'll write down any of my assumptions, biases or hypotheses. I usually use this information to brainstorm with teams in my day-to-day job, so it's good practice.

✔ Talk next steps

Briefly talk about what you think any next steps or follow-up would be. It could be as simple as usability testing or more concept testing, in order to further validate a product.

Back to top

Design portion

✔ Write some user stories

Take what you thought of for the research portion, and write some (assumptive) user stories based on that, so that interviewers can see the thread between the two areas.

✔ Brainstorm some (assumptive) ideas

Based off of your assumptions, and the initial statement, what are some of the problems the user may be having, or something the user may need? Choose one idea to continue with (or more if you have time).

✔ Create user flows

Imagine the journey users will go through with this idea. How would they land on it? What would they do? What will they try to achieve?

✔ Include some rough sketching

Again, this doesn’t have to be perfect, but it is the culmination of all of the work. Make sure the ideas, flows, and sketches can roll back up into the main problem we stated from the beginning. If they're not solving that problem or going in that direction, the final steps will feel disjointed.

Back to top

Miscellaneous

✔ Take note of your own questions

Was there a place where you wish you had more information, or you were unclear about something? That's okay! Admit it. It's okay to ask questions. The more shared understanding we have, the better the outcome will be. Be sure to include that you had some questions and would love to ask the relevant people.

✔ Use additional methods to supplement the study

Yes, we’re focused on qualitative research here, but a mixed-methods approach always wins. I like to include some quantitative metrics, such as surveys, A/B testing or using Google Analytics to validate trends in the qualitative research, or to work alongside the research. Thinking about projects as mixed-method, in general, is good practice.

✔ Establish success metrics

How will we know we were successful when the research project is finished? Often, it's hard to determine the success of qualitative data, but we certainly can come up with some ideas. Are we able to give teams action items that help them hit their KPIs? For example, can we give a retention team UX improvements that allow them to increase the number of users returning to the app/website/service? Were we able to create personas? Are those personas being put into user stories?

✔ Establish a timeline

Everyone loves a good timeline, especially when it comes to user research. It's important to show user research doesn’t have to take forever. But make sure you’re realistic about it. For instance, I estimate a generative research project to take about four weeks—from recruitment to analysis. No matter what I project, I explain where my estimate comes from, and write ideas for where we could cut down, or where we could add more time.

Phew.

This can seem like a lot to remember and write down within 30 minutes. But it makes the entire presentation go so much more smoothly when you have a flow that you can explain.

Remember, nothing is—or ever will be—perfect. Especially in thirty minutes! So be very open to questions and feedback from the team. It’s a lot for them to understand, too.

Finally, the more you practice whiteboarding, the better you will be.

So take a deep breath, be confident, grab a marker, and start practicing. Try out this random challenge generator, or take on a pre-set challenge. You've got this.

Back to top