Managing the Whiteboard Space

You’re reading an excerpt of Land Your Dream Design Job, a book by Dan Shilov. Filled with hard-won, personal insights, it is a comprehensive guide to landing a product design role in a startup, agency, or tech company, and covers the entire design interview process from beginning to end, for experienced and aspriring designers. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, commentary and future updates, and a high-quality PDF download.

Just like when you’re presenting your portfolio, you also want to position yourself in a good spot for a whiteboard. This means having enough space for you to write while having your interviewers clearly see what you’re doing. You should also keep track of time, ideally with a timer on your watch.

The surface area of your whiteboard should be proportional to the amount of time you’ll spend on it.

Figure: Managing Space and Time

The surface area of your whiteboard should be proportional to the amount of time you’ll spend on it.

Setting the Context

The first step to any design solution is to understand the problem. Just like in your portfolio project summary slide, you want to summarize the context:

• What is the prompt? What are you trying to solve for?

• What are the business objectives?

• What are the user objectives?

• What are the constraints?

• How do we measure success?

At this stage, you may treat your interviews as stakeholders. They can be your business or research counterparts. Ask questions to understand the problem fully from multiple perspectives and document this on the whiteboard.

When you wrap up: summarize key context points, tell your interviewers what you’re going to do next, and ask if there’s anything unaddressed that they’d like to see. This ensures everyone is in sync and no lingering questions (which can derail you later) remain.

Narrowing Problem Scope

At this point you might have more problems than you have time to solve for. That’s a good sign. Usually, in defining the context you’ll discover many opportunities to go after.

This step is an opportunity (no pun intended) to demonstrate your product thinking by narrowing options to the critical few leading to outsize impact. Show how you think about impact and the criteria you use to evaluate a problem space.

Here are some basic frameworks:

• Impact versus cost. The impact to the business and the user will be high, while the time spent developing this feature will be low.

• Forward momentum. Building this feature will pay down tech debt and position the team to learn and iterate faster.

• Ideal experience. If there are no explicit constraints, what would the ideal solution look like?

Alternatively, you might also be asked to not think about constraints at all (for example, unlimited engineering resources) and to create the best solution. In that case your constraints are driven by user needs, which you want to note down.

​important​ Finally, beware of the curse of knowledge. Take the time to remind yourself of the main goal and pick one big problem that you can solve well in the allotted time. It’s tempting to fight on multiple fronts, but you won’t have the time for that here. Choose meaningful focus over diffused diligence.

Generating Ideas

Now for the fun part—exploring many varying solutions by lifting constraints. Suspend disbelief and generate lots of solutions. The beauty of whiteboards is that you can draw lots of ideas and then either erase or narrow down the list to a promising few. If you get stumped, don’t be afraid to start sketching. The very act of sketching on the whiteboard and describing as you’re drawing can yield additional ideas. Go for quantity over quality at this phase.

Converging on a Solution

Once you’ve considered the world of possible solutions, you can start narrowing your scope down to a few promising options. Now’s the time to go deep. Again, it’s important to refer back to your original objectives. Did you miss anything? Look back to ensure the solution you’re about to expand on hits on the key pain points you’ve learned during the problem phase.

As you’re sketching out your solution, think in journeys and flows. How would someone interact with the service or the product? How would the interaction flow from one screen to the next? At this point you’re usually not expected to think through the edge cases as you’re sketching out a happy path.