Bonus tips for the Remote Product Design Whiteboarding Challenge

Lai-Jing Chu
8 min readMar 6, 2024

Chances are, you know what a whiteboarding challenge is if you’ve found yourself in this article. But in case you are wondering — a whiteboarding challenge (aka collaborative design exercise) is usually a hiring assessment for product designers whereby you are given a design prompt, and on the spot within 30mins to an hour, have to complete a design of a digital product feature in front of your interviewers, and then answer questions about it. The purpose is to gauge your communication and collaboration skills, as well as your product thinking skills and your ability to think on your feet. There is (usually) less demand placed on high-fidelity visual polish.

“I’m not a monkey” is the thought I conjure whenever I think of whiteboarding interviews as a candidate. In real life, I’d never had to design a whole app in 30 minutes, let alone verbally describe my process while doing so. It’s like trying to rub your head with one hand and your stomach with another. While I can see why companies like to include this as an assessment method, there are overwhelming reasons why I don’t believe they are indicative of a candidate’s real ability. But as long as whiteboarding is still in common hiring practice, unfortunately, we will still have to beat the challenge before critiquing it.

So, instead of debating whether or not design challenges are indicative of your ability, why not utilize your creativity to invent a technique and method that will help you get through it?

There is tons of advice about how to get through the design challenge, but none of them helped me address the butterflies in my stomach. So, today I want to highlight the few things “self-invented” techniques that made a real difference for me.

Tip 1: An acronym to lean on for the “discovery portion”

It is 101 that one should never start designing without clearly defining the problems and listing assumptions. Most guides and tutorials and articles have a lot to say about this section, so I won’t repeat those suggestions.

Everyone knows the basics — ask about the user, dig deeper into the prompt, and try to flesh out a picture of the context. But when you have only minutes to dialogue with your interviewer AND write everything down, it’s easy to get into a mind freeze. Hence, I created an acronym to help myself quickly get into the headspace during the test. (Since middle school, making up acronyms to pass exams was my thing. I had my own version of SOHCAHTOA before I knew its existence.)

TEMPLE

T: Trigger

When, why, and where might your user be prompted to use or turn on your product?

E: Environment

When your user is using the product, where might they be? Are they on the go or lying in bed? In the office or out and about? This is especially important for mobile apps because of the portable nature of smartphones.

M: Motivation

What is the high-level motivation or incentive for the user to use the product? How might you persuade them that your product will improve their lives?

P: Painpoints

What are their greatest pain points without your product? What are other existing, similar products failing to solve for?

L: Length of use

How long do you intend your user to spend on your product per session?

E: Emotion

How might your user be feeling about their pain points, and how do you think you want your product to make them feel?

Of course, this is just a short list to get your mind going. What I like about these five points is that it reminds me of questions that are easy to neglect (like “Trigger”) but are great for reacting to during the creative process. It also provides a good blend of user empathy and product thinking to get your mind going.

In addition— Add:

  1. Business back-story: What size and stage of a company are we talking about? What is their business model, and how do they turn a profit?
  2. Set some metrics: What would you be tracking to make sure the product meets the UX and business goals? You can also come back to it after you complete your design. This is especially important because whiteboarding is typically done at a low-fi and sketch level, and the whole purpose of it is to assess your product thinking.

Tip 2: Your user stories and task flows are essentially your ‘to-do list’ for the session

This part is fairly standard. You’d write out a few critical user stories, and outline a simple task flow or user journey. I have little to add here except for two habits:

  1. In a test condition, as I would in real life, I usually draw a checkbox in front of every user story so that at the end I could check them off to make sure my design had addressed all of them (or at least the high priority stories). A handy way to make sure you’ve delivered.
  2. After I draw out a simple task flow containing 3–5 steps, I would take it apart and draw the screen's frame below it. This is like making sure you outline your essay before writing it. It gives you a framework, so you don’t get lost amidst all the adrenaline and nerves.
  3. When you are done, come back to the user stories and check them off! That way, you can guarantee you didn’t miss key features.

Tip 3: Scared of speed-designing? Study for it.

Build up a mental inventory of interactive and patterns and common UI elements in your head before challenge day. Spent about 2–3 hours the night before your whiteboarding interview observing and sketching out mobile patterns of apps that existed on my phone.

This is the part I struggled with the most and was the part where I realized my brain tended to freeze. This is because, in real life, it was very rare that I’d ever had to draw an interface completely from scratch. At work, I tended to iterate on designs that had already pre-existed. Furthermore, in my previous roles, I designed websites and web apps much more than I did mobile apps, so I naturally didn’t have a lot of existing experience to draw from. And so, when I came to the part where I had to design, my mind drew a blank.

This is the part of my practice that I found was the most useful but had never heard anyone else mention in any of the materials I could find around how to prepare for whiteboarding. That is — I spent about 2–3 hours the night before my whiteboarding interview observing and sketching mobile patterns of apps that existed on my phone. If your phone is anything like mine, it probably contains reading apps, streaming apps, productivity apps, e-commerce apps, and health and wellness apps. I opened them one by one and spent 5–10 mins copying out interactions that I found interesting.

I still think this was the most valuable thing I did to prepare myself, and beyond that, just learning about product design in general. My eyes were opened to a whole world of interactive patterns that, for some reason I hadn’t paid close attention to in the past. What’s more, it is very likely that your whiteboarding prompt may relate to some of these typologies.

Sketch studies of existing apps on my phone

Observe — How do apps carefully position buttons, tabs, slide-out panels, navigation drawers, and menus to make a large number of potential actions or functionalities to be accessible, and the best ones make the interface look deceptively simple and minimalistic. Which elements tended to be prominent, and which tended to get tucked l away? How are elements sized? What kind of information and copy is displayed? What’s the use of grid and negative space like? What makes it delightful or frustrating to use?

In the end, because I had already familiarized myself with a rich vocabulary of design patterns and practiced sketching them out with my own hands when it came to the actual interview, I had a ton of ideas to draw from and didn’t need to draw a blank.

Bottom line: Don’t procrastinate on the design, make sure you don’t leave with a blank canvas.

Just one rule to note: make sure you get to the end of your design; whatever you do, make sure you don’t leave with a blank canvas at the “times up, pens down” moment.

Sure, interviewers want to know that ask the right questions and can think thoroughly about the problem before you start on any sort of solution. However, you don’t want to give off an impression that you’re stalling and avoiding the hard part (i.e., design) by dwelling on and on at the discovery potion—because in real life analysis-paralysis is also a common designer’s pitfall.

Miro, the digital whiteboarding tool I used, had a handy on-screen stop-watch. The fact that I could see the timer right next to my working area and had easy access to it made life a lot easier. Highly recommend. It is a paid feature but you can use it for free for a trial period.

Practice makes perfect

A 30-minute design challenge took me about 7 hours to prepare for the very first time I was ever faced with it, and I had less than a week’s notice while working full-time. The preparation involved two practice sessions involving a real-life person on the other end of the line. It is important to find someone who can simulate the “exam conditions” for you. Sure, it is strenuous and takes a lot of work, but at least once you’ve gotten the hang of it, your skill will apply whenever the next design challenge comes your way.

Just like any performer, once you feel well-prepared, it is actually possible for you to just enjoy being the star on stage. Think of it as your time to shine—your interviewers are your audience. Sure — in real life you’d never have to “perform design.” But to that point, it is indeed the only time you get to show off your design process in real-time in front of anyone! It may come as a shocker, they are there to cheer you on and they want you to succeed.

And if that thought doesn’t calm you down, well then — just think of the whiteboarding challenge as glorified Pictionary.

Image Credit: https://icebreakerideas.com/pictionary-game/

--

--

Lai-Jing Chu

Product Designer @ Polycam and mentor at Springboard / ADP List. I write here to organize my thoughts. My opinions are mine and could change.