How to Ace the Dreaded Whiteboard Challenge
And what to do when you’re faced with one…
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.
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:
You have thirty minutes to write all your thoughts on this board, and then we will come in for you to present to us for another thirty minutes. Make sense?
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.
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:
- How do you currently approach problems?
- What is the step-by-step process you currently use when faced with a project?
- What about that process would you like to improve?
My Whiteboard process:
I am 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.
- 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 are trying to understand customers, interviews are phenomenally helpful. If you are 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 for the company that they might be targeting (that is why it is important to do some research beforehand). I will also include information such as number of participants and whether we will 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 is 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, I will sometimes 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 is good practice.
- 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.
- 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 are not solving that problem, or going in that direction, the final steps will feel disjointed.
- Take note of your own questions. Was there a place where you wish you had more information, or you were unclear about something? That is okay! Admit it. It is 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-method 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 is 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 is 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 4 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.
This can seem like a lot to remember and write down within thirty 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.