The Ninja Skill for UX Designers

Earning Your Whiteboard Belt

We’ve seen one big trend in how startups interview UX designers: companies want to know how designers think through a problem.

The Whiteboard Design Challenge

Solve a design problem.

On a whiteboard.

In 20 minutes.

In front of others.

This is the tour-de-force of the designer hiring process. Can you cogently think through a problem? Can you bring others along in your thinking process? Can you externalize your ideas with words and sketches?

Whiteboard challenge: designing a book list feature for university professors using the Amazon API.

Practice Makes Perfect

At Tradecraft, we practice this skill weekly. Whiteboard Design Challenges are hard. And scary. And fun. They develop a great set of skills, from exploring a problem to facilitating a process.

  • One person is the designer and the other acts as host.
  • For 20 minutes, the designer works through the design challenge on the whiteboard, asking questions of the host as needed. They think out loud while writing to demonstrate how they are exploring and solving the challenge. Common elements that are covered include: personas, design stories, metrics, task flows, conceptual models and UI sketches. It’s kind of terrifying. And exhilarating.
  • When the 20 minutes is up, the host gives 10 min of feedback, then they swap roles and do it again with a different challenge.
  • The visible progress on problem-solving skills is dramatic across weekly whiteboard challenges.

Quick Tips By Role

:: Quick Tips for Designer ::

  • Plan the board. Where will you put the background info? How much space do you need for a task flow? Where should you put the UI sketches?
  • Ask for time-checks.
  • Write clearly, in all caps if possible.
  • Try to get to UI. Much gets worked out in UI. In UI, consider using a different color marker for CTAs or interactions.
  • Close strong: walk-through the solution as an answer to the challenge, and incorporate the design stories.
  • After, write your name and date and take a photo of it so you can track improvement.
Manage time. Be willfully humble in feedback.

Still Want More? Let’s Delve Deeper:

1. Start high level

What is the host asking you to design? What is the feature and or task that you have been charged with evaluating? Write the prompt down, and bullet any details they give you. Create a single task that communicates at a very high level what the product or feature will do. Don’t move on until you are clear on your mission’s directive. Ask if there is a metric they are trying to move. If so, write it down.

Ask questions for clarity. Your acumen is revealed in the questions you ask.

2. Who is it for? Move to the persona

Who is the product or feature designed for? Ask the host if they have done any research with users. Do they know who the user will be? Where does the user live, what they do for a living, or what are their needs? Depending on the host, they may give you a validated list of needs and behaviors or you may need to create your own list of assumptions.

Creating a persona provides stakeholders with a reference point when reviewing design decisions.

3. Create the main flows of the design story

Once a persona has been created, you are ready to pull together the primary tasks for this feature or product. The main flows are the primary tasks your user will perform when using your product. I suggest listing out these flows and including checkboxes in front of them for when you move onto to task flows. Once you have the main flows, begin to list out cases that are less common, but still occur. These will be your alternate flows. Even more rare then the alternate flow? These will be your edge and corner cases. Definitely remark upon these instances. Maybe you don’t need to write them on the board, but state them aloud.

The design story addresses the actions a user can take.

4. Work through task flow if given enough time

Depending on the time you have been given, you may want to actually demonstrate a task flow for one or more of the main and alternative flows. Remember that the task flow is designed to demonstrate how a user would perform a task, and where the user could potentially become ‘stuck’ or confused in the design. Look to the main and alternate flows for guidance while creating the task flow.

Task flows inject the user into the process— are there potential conflicts? System requirements? Usability issues?

5. Draw 2-3 wireframes of the user interface

If you’ve created a design story, the user interface should come much more easily. I begin by drawing out the constraints of the UI hierarchy. Broad level to specific. Draw out the navigation, body, footer, sidebars, etc. Next: where are the titles? The images? Then begin to call out the interactions: where are the links? Begin to show how the links or buttons connect user interface #1 with user interface #2. Recheck your task flows. What part of the user interface is on the task flow, but not communicated in the interface?

User interface sketching takes the abstract into the concrete.

6. Wrap up by revisiting the persona and design story

If you’ve kept a good handle on time, it is always great to ask questions from the host (assuming they haven’t been peppering you throughout). If they aren’t taking the chance to ask questions, give a final walk-through. Now that you’ve worked through broad theory to granular, interface specific fields, you can begin to show the common links between the epic, persona, design story, task flow and wireframe.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store