The Conversation That Keeps Coming Up
From mentoring sessions over the past year, I’d say about 70% of the designers I talk to are now dealing with design tests as part of the hiring process. And almost all of them hate it. I hate them too, honestly. There’s something that feels fundamentally off about being asked to prove yourself for free after you’ve already spent years building a body of work.
But here’s the thing: hating design tests doesn’t make them go away. If you’re actively looking for a role right now, you’re going to encounter them, and how you handle them matters more than how you feel about them. The old days of walking into an interview, presenting your portfolio, shaking hands, and getting an offer are mostly gone. The process has gotten longer, more structured, and more demanding, and that’s true whether you’re junior or senior.
So instead of having the same debate about whether design tests should exist, I want to talk about how to navigate them in a way that protects your time, your work, and your sanity.
Why Companies Started Doing This
Let’s be honest about why we’re here. The workforce is global now. A job posting that used to get fifty applicants now gets five hundred. The pile is huge, and hiring managers are drowning in it.
On top of that, portfolios have gotten harder to trust. I don’t say this to be cynical — I’ve seen it firsthand. Designers who followed a tutorial step by step and presented the result as their own thinking. People who pulled a visual style directly from Pinterest, polished it into a case study, and couldn’t explain a single decision when you asked them about it in person. They can make a beautiful JPEG, but when you put them in a room with a real problem and a real deadline, they freeze.
Employers are scared because they’ve been burned. They hired someone whose portfolio looked incredible and then spent three months realizing that person couldn’t actually solve problems independently. Design tests became a way to close that gap between what someone’s portfolio shows and what they can actually do under real conditions.
I’m not saying the system is fair. I’m saying it’s understandable if you look at it from the other side of the table.
The Two Camps (and the Third Option)
There are generally two loud camps in this conversation. The first one says “never work for free” on principle, refuses any test, and draws a hard line. The second camp doesn’t say much publicly — they just quietly complete the tests because they need the job and the rent is due.
Both are valid positions. But I think there’s a more useful third option, which is to engage strategically. Not every design test is the same, and learning to evaluate them before you react is a skill worth developing.
How to Evaluate a Design Test
Here’s a simple framework I walk mentees through when they receive a test prompt:
1. Check what they’re actually asking you to design.
This is the most important filter. If the company is asking you to redesign their actual homepage, their real product onboarding, or any other piece of their live product — that’s spec work. You’re giving them free labor on a real business problem, and there’s no guarantee they won’t use your ideas whether they hire you or not. Walk away from those.
If the prompt uses a fictional company, a made-up event, or a clearly hypothetical scenario, that’s different. That’s a skills assessment. They want to see how you think, not steal your output. Those are generally worth engaging with.
2. Look at the time expectation.
A reasonable design test gives you a constrained timeframe — usually two to four hours of work, maybe a weekend if it’s more involved. If a company is asking for a full week of unpaid work, that tells you something about how they’ll value your time once you’re on the team. A test should be long enough to show your thinking process but not so long that it becomes a free consulting engagement.
3. Assess the evaluation criteria.
Good companies will tell you what they’re looking for. “We want to see your problem-solving process” is a green flag. “We want a pixel-perfect, fully interactive prototype” for an unpaid test is a red flag. The best design tests care about your thinking, not your polish.
4. Consider the role and the company.
For a senior or lead role at a company you genuinely want to work at, a well-designed test might be worth your time even if it’s more involved. For an entry-level role at a company you’ve never heard of that won’t even tell you the salary range, probably not. Match your investment to the opportunity.
Protecting Your Work Without Being Weird About It
One of the biggest concerns designers have is that their test work will get used without credit or compensation. It’s a legitimate worry. Here are two approaches that protect you without making things awkward.
The Email Clause. When you submit your test, include a short paragraph at the bottom of your email that states something like: “This work was created as part of an interview assessment and remains my intellectual property. It is shared for evaluation purposes only and may not be reproduced, distributed, or used in any commercial capacity without my written consent.”
You don’t need to make it aggressive or legalistic. Just clear and professional. Most hiring managers won’t even think twice about it — and the ones who push back on it are telling you something important about the company.
The Subtle Watermark. Don’t slap a giant “CONFIDENTIAL” stamp across your work, because that looks defensive and makes the presentation harder to evaluate. Instead, add a small footer on each page: “Concept work for interview purposes only. [Your Name], [Date].” It documents ownership without disrupting the work itself.
Both of these take about thirty seconds to add, and they give you a paper trail if anything goes sideways.
Think Like You’re A/B Testing, Not Auditioning
Here’s a mindset shift that changed how I think about design tests, and it’s something I now teach to every designer I mentor.
Stop treating a design test like an audition where you’re hoping to be chosen. Start treating it like an experiment where you’re testing a hypothesis.
When you frame it as an audition, every rejection feels personal. You poured your thinking into it, you stayed up late polishing it, and then you didn’t get picked — and it feels like they’re saying your work isn’t good enough, or worse, that you aren’t good enough.
But when you frame it as an experiment, the emotional weight drops significantly. You’re testing whether your approach to a problem resonates with this particular team’s way of thinking. If it doesn’t, that’s data. It doesn’t mean your solution was wrong — it means this team values different things than you prioritized, and that’s actually useful information about whether you’d be happy working there.
How to apply this practically:
- State your hypothesis up front. Before you start designing, write down what you think the core problem is and what approach you’re going to take. Include this in your submission. It shows the evaluators your thinking and gives you something concrete to learn from regardless of the outcome.
- Document your trade-offs. Every design decision involves giving something up. If you prioritized simplicity over feature density, say that. If you went bold with the visual direction at the expense of convention, explain why. This is the kind of thinking that separates designers who can solve problems from designers who can only make things look nice.
- Define what success looks like to you. Before you submit, write down what you’d consider a successful outcome from this test — separate from whether you get the job. Maybe it’s practicing a new prototyping tool, or getting better at time-boxing, or building a portfolio piece you’re proud of. If you hit that goal, the test was worth it regardless.
When Your Design “Loses”
Even with the right mindset, rejection still stings. That’s human. But building emotional resilience around your work is one of the most important career skills a designer can develop, and design tests are actually decent practice for it.
When you don’t advance after a design test, here’s what I’d suggest: wait 24 hours before you do anything. Don’t fire off a frustrated email, don’t post about it on LinkedIn, don’t spiral. Just let it sit.
After that, ask for feedback. A simple “I’d love to understand what you were looking for so I can improve” email goes a long way. Some companies won’t respond, but the ones that do often give you genuinely useful insight into how your work was perceived. I’ve seen designers get hired for future roles at the same company because they handled the rejection with maturity and stayed in touch.
Then, if the work is solid, add it to your portfolio. Seriously. You already did the thinking and the execution — you might as well get something out of it. Some of the strongest portfolio pieces I’ve seen from designers came from interview tests, because the constraints forced them to be resourceful and focused in ways that self-directed projects sometimes don’t.
The Bigger Picture
Design tests aren’t going away anytime soon. The market is competitive, trust is low, and companies are going to keep looking for ways to de-risk their hiring decisions. You can choose not to participate, and that’s a valid choice. But if you do engage, engage smart.
Check the prompt. Protect your IP. Treat it like an experiment. Learn from the outcome whether you get the job or not.
The designers who navigate this well aren’t the ones who never have to do tests. They’re the ones who turn the process into something that makes them better, regardless of the result.
What’s your experience been with design tests? Have you found ways to make the process work for you, or are you still figuring it out? Hit reply — I’d genuinely love to hear how you’re handling it.
-K
