Trusting the Process

As a designer or developer, how many of you have been asked at some point to take a “test” for a job or freelance gig?

Just as we expected. Every. Single. One. Of. Us.

What other industries deal with this? Would you test a home builder’s skill level by asking him to build a wall before determining if he’s qualified to build the entire house? Would you ask the dentist to clean one tooth for free, and if you’re satisfied, you’ll pay for her to do the rest? No. That’s not how life works.

So why is it acceptable to ask candidates to complete a design or development challenge in order to prove themselves to potential clients or employers?

Let’s be frank and set the record straight. We’re not innocent in this. In the past, our team at Made By Munsters is guilty of this infraction on our industry too. We’ve asked our top job candidates in the past to complete a small assignment so we can see how they perform. We’ve also used those tests along with the interview process to determine who we then hired. While it may be a small indication of how a person may perform, that still doesn’t make it right.

So why do companies feel it’s necessary to ask this of us before committing? Is it out of fear of selecting the wrong person or firm for the job? Difficulty in making a decision? Do they really have no clue for what they want or what they’re looking for? Do multiple concepts from a variety of people really help them make decisions?

No clue. But let’s talk about why this is a hazard to doing great work:

Spec Work vs. Paid Work

Every designer knows the dreaded phrase: “spec work”. While the word is never clearly said directly from a potential client or employer, we know what it involves. It always starts out the same way:

“Hey, we’d like for you to do a design and if it’s to our liking, we’d like to work with you on more things”. What this really means is, “Hey, do this work for free and there’s a small chance we’d pick you out of dozens (or hundreds) doing the same thing”.

It’s also when someone who likely has money to pay for our services decides to run a “contest” to get a heap of options to choose from, and as a designer or developer, you can get “exposure” from doing so.

Spec work never clearly indicates what problem you are trying to solve. And as designers and developers, that’s our primary goal. Spec work tends to come with a half-assed brief that gives you very little insight into what you’re trying to solve, yet that’s how companies determine whether or not you’re qualified to work with them.

Sometimes, companies are gracious enough to pay your for a limited amount of your time to do these assignments. While that’s slightly better, there are still major issues with accepting this work. Again, limiting your time based on what they want to pay you to test your abilities hinders the process of actually doing great work. Now that we’re on the topic of time, let’s talk about time-boxing these assignments more in-depth.

Time-boxing

Time-boxing is a way for a potential client or employer to limit the amount of risk they take on, while still trying to assess whether or not you’re good enough to join them. They may not want to go “all-in” on a candidate because they’re unsure of the quality they may get.

Again, there are many issues with this methodology. By limiting time spent on a small part of a project, it doesn’t give you the designer or developer enough of a chance to determine the problem, how to properly solve it, and then execute on it with the confidence you fully possess.

At Made By Munsters, we often try and alleviate our potential clients’ concerns by offering an inception (or discovery) workshop. This gives everyone with stake on a project the chance to get in a room, talk about all issues associated with the upcoming project, and then formulate a plan for success. This provides our team with enough information to properly assess all aspects of the thing we will likely build, and helps instill confidence in our ability to do it properly.

Lack of Context

Through our inception workshops, we remove the potential for lack of context you may get from spec work briefs or small challenges. Our team works directly with our clients to figure out all moving pieces of the product we plan to build, create a highly detailed roadmap of our tasks and goals, and create an action plan to complete it.

Without proper planning and understanding of the project, you’re setting yourself up for failure. You can assess and validate a designer or developer based on a simple assignment, but at the end of the day, it can cause issues and you, the client, take on a huge risk in selecting the wrong person based on simple conversations and aesthetics versus a well-developed process. Which brings me to my next and last point.