Whiteboard Design Challenge Framework
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.”
The Framework
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.
The Quadrants
I draw four quadrants on the whiteboard first when I get started and name them —
- User Needs
- User Goals
- Constraints
- Assumptions
User Needs
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).
User Goals
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.
Assumptions and constraints are uncovered as you engage with the team and learning more about the user. They do not actually belong to any particular step, but get populated in the course of the process.
Assumptions
As designers, we make a lot of assumptions. Over the course of time, we validate them and make iterations accordingly.
This is an important fraction of our design process, and highlighting that we account for this would make you stand out. List every assumption you make on the whiteboard. A few of the assumptions can be validated by cross-verifying with our primary research source (one of the interviewers). Most assumptions would remain unverified, and that is okay. Acknowledging the fact that they are assumptions, and that they require validation, makes you seem less biased towards a design.
We’re making an assumption that kids have access to a tablet. Also, we are making an assumption that kids like to customize how the toys look.
Constraints
As you uncover more about the user in the exercise, start noting down constraints that you encounter in the process. If you do not constrain yourself, you would end up designing for almost all the problems you notice, and a 45-minute exercise does not suffice. Start asking your interviewers questions about the business side of things.
Again, it is worth asking another interviewer to play the role of a Product Manager, or an Engineering Manager to uncover business and engineering constraints.
While it is good to design for an ideal experience, it is important for designers to question about some of the business needs like —
Why a toy building app? What is the success criteria for this project? What existing market research do you already have about this section of users? What are some of the engineering constraints that stand out in the technology that is currently being used? Android or iOS? And why?
Designers right out of design school have a tendency to shoot for blue-sky designs. In the real world, this is hardly possible. There are priorities, business goals, timelines, and many other constraints that you uncover.
There are chances that your interviewers might not really provide you with solid constraints. In that case, question them to uncover constraints. In a few of my interviews, I have been asked not to think of constraints at all; then just design blue-sky ideas. Go mad.
The Experience
Now that you have majority of the research done about our user, you get into this phase what designers like to call interaction design, where you are drawing a picture of what you know about user’s current behavior and what aspects of it stand out as a challenge to be tackled.
Current Journey/User-flow
The user goal that you defined is the end result that you would like to achieve. Now, draw the current user journey of how users achieve it without your design. There are chances that your user is not arriving at the goal because of breaks in their existing journey. Highlight that visually as you walk your interviewers through their existing journey. It can be as simple as something like —
How do parents buy their kids a toy currently? Kid watches a cartoon -> asks parents for a toy -> parents take them to the store -> they do not find what the kids want in the first store -> they look for the toy in other stores -> kids end up buying something else instead of what they came for -> a couple of days later, the kids want the same toy they went looking for.
While you list down the breaks in the journey, start brainstorming with the team on how these gaps could be addressed. A good design team will jump at the opportunity to ideate with you. Make use of this and build on ideas suggested by other team members.
At multiple instances, your ideas might not align with the team’s, or you think one of the ideas suggested by the team member is poor because it did not account for something critical. At this point, brutal honesty will take you a long way. Also, it gives you an opportunity to counter check how your teammates respond to critique. Hey, in all fairness, you are not just looking for a job, you are looking for a good team to play design for the next few years to come; so it’s important for you to evaluate your teammates as well.
Sketches/New Experience
This is the point you start sketching ideas on the whiteboard with your teammates. Pay close attention to detail, and sketch ideas. It is good to get started on a high-level experience first. Start sketching how an ideal experience would look like (bearing in mind the constraints and assumptions). Start placing your user in hypothetical scenarios.
The kid decides that she wants a toy after watching a cartoon on the television. She wants a different costume on the character though.
Some design exercises are not very high-level but very detail oriented — make sure you account for edge-cases in these scenarios. Talk about the ideal experience, then start brainstorming the team with “What if?” questions addressing edge-cases.
What happens when the kid finishes designing the toy? Does the kid place the order for the toy? Does this mean the kid can just buy a toy whenever? What other measures need to be taken? How do parents make sure their payment information is safe? What other user-flow can be thought of to add the element of parent authentication in the process? Is the experience fragmented if the child designs the toy and then hands over the iPad to her parents for completing the order?
Asking such questions, and drawing parallels from it in your design solution will help with creating an experience that accounts for possible critique questions from your interviewers. You have beaten them already by asking yourself these questions, and giving them answers before they can even question you.
This step in the process is to paint an image of the new experience, and point out the pros and cons of the design. Be critical of your own design, and be honest about the trade-offs. A good designer knows and accepts where the designs fall short; potential ways to address shortcomings of the design can be brainstormed as well.
Final Thoughts
Trust your designer intuition
You have built a killer intuition over the years of design practice — make use of this. It is totally acceptable to say in a challenge that “My intuition says”, and then taking the design forward. In design school, you are trained to present a rationale for every decision and direction, but this is not feasible in a whiteboard design challenge. You always make assumptions while designing. Trusting your intuition and accepting that it is a direction you are taking with an assumption will express your clarity of thought to your interviewers.
This is not written in stone.
I would like to stress on the fact that this is not how every whiteboard challenge needs to be tackled. This is more of a structure that I created for myself to help design better in a whiteboard challenge. There have been multiple occasions where I have had to stray away from this format and adapt to how the challenge progressed based on feedback from others in the room. It really helps to practice a lot with your designer/engineering friends. Most of my ideas in interviews have been from practice sessions.
Now that I am at the other end of the spectrum, interviewing candidates for whiteboard design challenges, I’ve noticed that candidates who address most of the above-mentioned parameters are usually a thumbs-up from the team. Remember, they are not judging your solution, they’re observing how you think.
