Hey and welcome back to a new week!

A design take-home can tell you a lot about a role before you even start making anything. This week, I’m looking at how to judge whether a task is fair, use the tools the brief allows, and show the decisions behind your work.

In this issue:

📕 SUPERCHARGE YOUR AI USE

The 8-hour workday is becoming a 4-hour workday for people who know how to use AI.

Everyone else is still catching up.

This AI work playbook shows you exactly how to cut your work hours in half using AI.

Sign up for Superhuman AI and get:

Claim your AI playbook

You get through the portfolio review and the first interview. Then a brief arrives: improve an onboarding flow, redesign a dashboard, or make part of a product “more intuitive.”

It is tempting to open Figma immediately and make as much as you can. I would pause first. Before you decide what to design, you need to know whether the task is fair, what you are allowed to use, and what the team actually wants to evaluate.

Those three questions can save you hours. They also tell you a surprising amount about the company.

A take-home can be useful when the company is already interested in you and wants something concrete to discuss. It should have a sensible scope and give you a chance to explain your decisions.

There are three situations that would make me cautious:

Payment changes the calculation. If a company offers meaningful compensation for a larger exercise, I am much more comfortable with it. A token gift card does not turn several days of work into a fair exchange.

You can ask how long they expect you to spend, how the work will be used, and who will review it. If the answers still leave you feeling like you are building their next feature for free, you can decline.

Some take-homes will invite AI use. Others will limit it or prohibit it. Follow the actual brief. If the company says not to use AI for design production or writing, do those parts yourself. If it bans AI entirely, do not quietly use it for research either. It is not worth risking your credibility over a shortcut.

I would start with research. Ask a tool with a deep research feature to map the audience, the product category, competitors, common complaints, and open questions. This can give you a much better starting point in an unfamiliar space without eating the whole time budget. Plenty of candidates still skip this step.

If the brief concerns a B2B product, G2 can be useful for finding competing products and reading what users say about them. If the task is fictional or unrelated to the company's product, research the domain in the brief instead. Do not force competitor research into a problem where it will not help.

Treat AI's research output as a map, not evidence. Open the original sources, check the claims, and cite what you actually used. You should be able to explain where an insight or assumption came from. Unless the company asks for a tool-by-tool account, you do not need to narrate every search that helped you find a source.

If production use is allowed, explore copy and flows, generate alternatives, look for edge cases, and make something people can click through. Figma's AI features, Lovable, or Claude Code with Artifacts can help you get to a working prototype quickly. You do not always need a full application; a small page made with HTML, CSS, and a little JavaScript may communicate the idea just as well and be easier to hand over.

The extra speed should buy you time to inspect the output. Can you explain the decisions? Does the flow work beyond its nicest screen? What did you keep, change, or reject? That is what I would want to hear in the presentation.

You can move faster still if you have a starting point ready before the task arrives.

Keep a small Figma kit with common components, text styles, spacing choices, and patterns you know how to adapt. Or use a good existing library. If you build prototypes in code, choose a UI library you trust and a simple starter you know how to restyle for each project. You should not have to rebuild an ordinary button every time an interview task arrives, whether you are working in Figma or asking a coding tool to help.

The same goes for low-fidelity work. A wireframe kit can help you assemble a flow quickly. Nobody is evaluating how fast you can draw a grey rectangle; they want to see whether the structure makes sense.

Adapt the kit to the brief and be clear about any provided assets when the instructions ask. You do not need to spend half the assignment inventing a design system if the problem is really about a user journey. On the other hand, if you are applying for a visual design role and the brief is testing visual craft, the styling and finish deserve much more of your time. Read the role and the evaluation criteria before deciding where to put your effort.

Real design work rarely comes with a perfect prompt. Ask a few focused questions if the brief leaves out information that would change your decisions: Who is the primary user? What problem is the team trying to solve? What platform or constraints matter? What does success look like?

You do not need to send a questionnaire. If the company cannot answer, write down your assumptions and move forward. A sentence such as “I assumed this is a desktop workflow used weekly by operations teams, where speed matters more than discovery” gives your reviewer the context needed to understand your choices.

Then choose a scope that fits the available time. For a product design exercise, a clear core flow with a few important states is usually stronger than twelve unrelated polished screens. Show the moment where the problem is solved, plus enough surrounding context to prove you thought about what happens before and after it. Include an error, empty, or loading state if it affects the decision you are making.

Again, follow the role. If the exercise explicitly asks for visual exploration, a brand direction, or a highly finished interface, make room for that. The point is to spend time on what the team is trying to assess.

I often see this go wrong in mentoring sessions. A task says “spend no more than three or four hours,” and a candidate puts in two full working days. I understand the impulse: you really want the job, so doing more feels like the safest way to show it. But that time could have gone into other applications, your portfolio, or simply getting some rest. And the extra work can actually hurt your chances.

If a team asks for a small exercise and receives a sprawling project, they may wonder whether you can work within a brief. An exceptional result might make them overlook that. Most of the time, though, you want to show that you can judge what is enough and stop there.

This does not mean you need to watch a timer obsessively. You may need longer to get into the problem, or you may step away after a few hours and return with fresh eyes tomorrow. The important thing is to avoid turning that extra time into extra scope.

Follow the stated deliverables. If they ask for a wireframe, a prototype, and a rationale, give them those three things in a form they can inspect easily. If the format or scope is vague, use your judgment about what communicates the answer best. You do not need to add a slide deck just to make the work look substantial. A presentation may be useful when you are in the room to talk through the work; on its own, it is often a worse handover than a clear Figma file or working prototype.

The final file should make it easy to see what you understood, what you assumed, and why you chose this direction. Name a trade-off or two. Perhaps you simplified the first session and left advanced controls for later. Perhaps you prioritised accessibility over a more unusual interaction.

Add a short “What I would validate next” section. You might want to speak to users, check existing data, test whether a label is understood, or work with engineering on feasibility. A short take-home cannot replace those steps, and acknowledging that makes your thinking more credible.

When you present the work, keep the story simple: the problem as you understood it, your assumptions, the key decisions, and what you would test next. Rehearse it out loud once. If you cannot explain a screen without walking through every pixel, the story probably needs another pass.

The best submission is not always the one with the most screens. It is the one that helps the team imagine how you would approach a real problem with them: asking useful questions, using the tools you are allowed to use, making considered decisions, and knowing what still needs to be learned.

💵 LET AI WORK FOR YOU

The next wave of millionaires will be people who figured out how to make AI work for them.

The window to get ahead is still open. But not for long.

Here are 200+ proven ways to make money with AI in 2026.

Sign up for Superhuman AI, the free daily newsletter read by 1M+ professionals, and get instant access to all 200+ ways to profit from AI this year.

Claim your free list

Ambika is a Seattle-based product designer with a deep background in research, including experience at Google and TikTok.

She brings more professional experience than many designers featured in this series, and her portfolio shows it. Complex projects become easy to follow, with descriptive headings, purposeful visuals, and enough context to understand the decisions behind the work.

There is plenty to borrow from her storytelling, including how she presents a confidential project. Let’s look at what she does well and where a few improvements could help the portfolio go further.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video portfolio review? Look no more. I do offer these as an async service you can book directly with me here.

Keep kicking doors open and see you next week!
- Florian