For a single design position, it’s not unusual to look through a hundred candidates’ portfolios and résumés just to get to five interviews. Even with strong candidates, making the step from serious candidate to full-time hire can still be an intimidating decision to make. How does a company decide that a person has the right skills and a process that will work with the rest of the team? We decided to create a design test to better analyze the candidates we like to make sure they’re a good fit for us…and that we’re a good fit for them!
Not all our candidates come from a background of making or are interaction-savvy, so we needed a test that reveals process more than technical capabilities.
Before we even got into the content of the test, we established three principles:
Everyone’s time is valuable. We shouldn’t ask or expect anyone who isn’t seriously being considered for hire to take the test. We want to remain fair to the candidates and won’t ask for anything that we’d estimate more than a day’s worth of work. We’ll always do a proper interview beforehand to make sure both sides feel it’s worth pursuing before she (or he) gets the test. This will confirm if we’d be a good fit personality-wise, and give them the chance to meet us all and envy our roof deck.
It shouldn’t feel anything like an attempt to get free work from prospective candidates. We’ll make sure the test is close enough to what we do so the candidate’s abilities and fit will be evident, but will never use a problem that we ourselves are trying to solve.
And finally, we won’t expect perfection. A successful design test isn’t a clear-cut pass or fail. We’ll use the test as a talking point for those who pass, and ideally, this will be a learning experience whether the candidate gets the position or not.
So what does a good design test include?
A taste of how we work with clients. Some candidates come straight out of school, while others come from years of experience. We want to see how adept our candidates are approaching problems, so we present the brief as if it were an existing app that received negative user feedback.
Realistic constraints. No design brief ever comes without constraints. We included some basic brand guidelines in our design test files to set some boundaries. We also constrained the scope of the test so that our candidates wouldn’t misinterpret it as a full app redesign, and can appropriately focus their attention on the problem at hand.
Opportunity to go above and beyond. We kept the definition of the deliverable loosely worded. Most might interpret it as delivering a pdf presentation, but we don’t want to keep anyone from delivering a prototype, a movie, or whatever other form they choose to answer the brief. We like to be surprised!
A writing sample. We ask our candidates to walk us through their process in writing because we look for designers who share our value of communicating clearly. A good designer can articulate their thoughts in a way that adds value to static screen comps.
A few sly traps. After all, it is a test! We might have left a few intentionally bad decisions in the original app assets. It’s our way of seeing how much attention is given to the details, while also giving them the chance to nerd out on improving things like iconography or photography choices.
We’ve tested our design test internally, and were glad to discover that the results had a broad enough range to give true tells about each designer’s strengths and way of working.
If you’re in a company as small as ours, every hire molds the office in some way or another. When creating a design test, determine which criteria are essential for a new hire, and which you’re willing to teach. Make sure the test caters to the essentials first, and allow room for the test to reveal other strengths or weaknesses that might become the more valuable talking point.
And if you do choose to hire them, having some experience working together gives the advantage of knowing where to start and what they’re ready to handle. If you’d like to try out our test for yourself, apply now.