A simple framework to help designers with whiteboard challenges in an interview.
Why write about whiteboard design challenges?
Very recently, I experienced a long spree hunting for design jobs. This process was exhausting and very enlightening in terms of what I valued as a designer, my thought-process, and how I tackled challenges that were extremely time sensitive. At first, it was all about just finding a job, but this quickly changed when I realized that my interests did not align with most of the offers I had on hand. This made me look for more, filtering it down to the most primal team characteristics such as culture fit and team processes. This journey led me to many onsite interviews where the interview process was slightly nuanced depending on the company, but the core essence remained the same for most organizations.
Whiteboard Challenges — The common thread
The one common onsite interview round is a whiteboard challenge. Companies like Google had four whiteboard challenges on the day of the onsite interview which can take a toll on your thought process and have you brain-fried for the rest of the day.
It is imperative to have a strategy, a plan on how to tackle the challenge, and a structure to help you think on your feet.
As extempore as it sounds, whiteboard challenges are best tackled when you have a game plan. This draws a parallel with how some of the best improvisational musicians or stand-up comedians did not make it magically, but through sheer rigorous practice.
What do they look for in a whiteboard exercise?
In the process of preparation for whiteboard challenges, I noticed that I was all over the place initially. I was designing good solutions, but on reflection, I noticed that my process did not have a direction. It did not seem like I knew where I was going with the design. In short, I was not in command. I was often told that a structure is not necessary for a design challenge, as design, in general, is not a structured process; it is rather messy. While I agree to it, it is important to know that, you — as an interview candidate — are there to show the interviewers your thought-process, your ability to take a stance with design conviction, and facilitate the conversation by making the exercise inclusive by letting the other team members participate in the process.
The team is not evaluating your solution, but your ability to communicate your ideas, openness to receive critique, and spontaneity in tackling contrasting ideas from other team members.
You often have about 45 minutes to an hour to exhibit these characteristics, and without a strategy to manage your time efficiently, you might not strike a chord with the team.
Why a framework?
To get better at whiteboard challenges, I devised a framework from my design process that highlighted salient considerations to be made while designing. There are parameters like constraints, assumptions etc which exist in our design process which you consider subconsciously. You eventually handle these parameters, but in a time-sensitive environment you might jump the gun and get to designing solutions directly without these considerations.
I decided to note these parameters and create a structure around it to help me design better on my feet. I noticed that using such a framework helped me improvise better, led to more conversations with the team, the outcomes were solid and backed by significantly stronger rationale.
Let’s go through the framework for the following design challenge —
“Design a toy building application for kids.”
There are two parts to this framework —
- The Quadrants
- The Experience
I follow a two-step process while designing the solution for whiteboard challenges. There’s no hard and fast rule that these steps need to be followed in any particular order, but structuring the session linearly helps with your thought process, and also helps with keeping people on the same page.
I draw four quadrants on the whiteboard first when I get started and name them —
- User Needs
- User Goals
Don’t jump to screens directly when given a problem — this is an immediate red flag. Might seem like a no-brainer for a designer, but in a design whiteboard challenge, you get too carried away by the problem statement that you almost forget to ask questions about whom you are designing for. What are their needs? What pain-points of our users are you trying to design for? By painting a picture of the user you are designing for, you build empathy in the minds of the interviewers about the user, and also setting the stage and context for what you are designing for. This is what you try to arrive at about the user. This talks about the importance you give for user-research. A good exercise here would be to build a persona whom you are designing for.
The best way to gather information about a hypothetical user you are designing for is by asking one of your interviewers to role-play as a user.
This works wonders. You can treat them as a primary research source and try to understand their behavior. Note down their needs on the whiteboard.
Kids of what age am I designing for? Consider one of the interviewers as a parent and interview them.When do parents buy their kids a toy? How do kids select their toys currently? What is a child’s behavior when shopping in a store? What technology do parents make available to their children? How do siblings behave when buying a toy? And so on..
You cannot tackle all the problems in a short design exercise, so take the lead and confidently point to a specific problem that you feel is interesting to solve for (intuition — more on this further down). Exercise caution while doing this, though, you don’t want to be doing this too early in the design challenge, and not at the fag end either. This will help to narrow down the problem and provide a focus to design for.
Let’s assume I am designing for kids between 7 and 12 who have access to an iPad. The parents allow kids to buy a toy if they finish their chores for the month on time (finding through talking to interviewers A.K.A your primary research participant).
As you learn more about your user, you start noticing patterns or an overarching goal. Note that down — this is what your end-user goal is.
Your design should aim at achieving this goal.
Throughout the exercise, make sure your design addresses this goal. For me personally, in most design exercises this was singular, but there have been challenges where I was designing for multiple goals.
Kids should be easily able to build a toy on the application that affords selecting various outfits, superheroes and cartoons from television.