How to prepare a design take-home assignment in the AI era

A design take home assignment should make your judgment visible. AI can help produce a plausible flow quickly, but a reviewer still needs to understand why you chose that flow, which alternatives you rejected, and what you would check before shipping. Submit a clear solution with a short decision note. The note connects the screens to the problem they are supposed to solve.

That changes how you prepare. Spending the whole evening polishing screens leaves little time to explain their purpose. Set aside time for the reasoning while the work is still in progress. You will have a better account of your decisions than if you reconstruct a convincing story after the mockups are finished.

Start with the assignment, including its limits

Read the actual instructions before opening a design tool. Identify the requested deliverable, the time limit, the intended audience, and any rules about AI use. If something essential is unclear, ask a focused question. When clarification is unavailable, write down your assumption and explain how a different answer would change the work.

Then choose the user problem you can address within those limits. “Improve onboarding” is too broad to guide a short exercise. “Help a first-time customer understand what information they need before starting an application” gives you a specific moment to examine. It also lets you explain why you have left other parts of onboarding alone.

Keep three categories separate in your notes: what the brief tells you, what you are assuming, and what you would need to learn. A generated persona does not become research because it sounds plausible. If the assignment contains no interviews or analytics, your proposal remains a hypothesis. Being clear about that boundary gives the reviewer something concrete to discuss.

Choose one decision you can defend

Imagine a fictional application flow where customers encounter a request for supporting documents halfway through. You could add an introductory checklist, let people save and return, or delay the request. These are different responses to different possible problems. Before drawing any of them, decide which problem your proposal addresses and explain why you have selected it.

Suppose you choose the checklist because your working assumption is that people start without knowing what they need. Your decision note might say: “Show the document requirements before the application begins, so customers can decide whether they are ready. I would first check whether they understand the requirements and can identify their next step.” That is a testable explanation without fabricated conversion targets.

Include the strongest alternative you rejected. Saving progress may be useful, but it would not tell customers what they need before starting. Conversely, if people understand the requirements and are interrupted later, saving progress could be the better choice. The comparison shows where your reasoning holds and what evidence would change it. The guide to what design interviews test gives you a frame for discussing those decisions.

Make the screens carry the argument

Build enough of the flow to show how your decision works. For the checklist example, that could mean the entry point, the requirements, and the next action. Include a relevant difficult state if it changes the proposal, such as a customer who does not have a required document. Avoid adding unrelated screens just to make the submission feel larger.

Visual craft still matters. Labels must be understandable, the next action must be visible, and the layout must support the task. Your rationale cannot rescue a confusing interface. Use the explanation to point to specific choices in the design, then check whether the screens actually do what you claim. If they do not, revise either the design or the claim.

Try the structure on a sample design brief before your next interview. Write the decision first, sketch the smallest flow that demonstrates it, and compare the result with your original explanation. This exposes an easy mistake: producing an attractive answer to a different problem from the one you chose.

Add a decision note the reviewer can scan

Keep the note proportionate to the assignment. A short exercise rarely needs a separate research report and a long presentation. A concise page can explain the reasoning alongside the flow. Follow any submission format the employer specifies, and make each section answer a practical question rather than describe a stage of your process.

• Problem: which user, task, and moment are you addressing?
• Evidence and assumptions: what came from the brief, and what remains unverified?
• Decision: what did you change, and how should that help?
• Alternative: what else did you consider, and why did you leave it out?
• Next check: what would you investigate first, and what result would make you reconsider?

Use the structure in how to write a design rationale when a decision is difficult to explain. Pair each important claim with the relevant screen or detail. The UX case study examples can also help you organize the story. Scale the presentation to the exercise instead of imitating the length of a full project case study.

Propose a check you can actually explain

Start with the uncertainty that could invalidate your proposal. In the fictional checklist example, that is whether customers understand the requirements and know what to do next. You could describe a task-based usability session: ask someone to prepare to begin an application, observe how they interpret the checklist, and note where they hesitate or misunderstand a requirement.

Do not report that proposed session as completed research. State who you would recruit, what task you would give them, and what you would observe. Explain how the findings could change the design. If customers understand the list but cannot obtain a document, the next decision may concern support or saving progress rather than the checklist layout.

If you also propose measuring behavior after launch, name a relevant measure and its limitations. Application starts alone would not show whether people complete the task successfully. You would need a baseline and information about traffic before choosing an experiment duration or claiming a detectable improvement. Write those as dependencies. A take-home does not require invented numbers to make its reasoning concrete.

Use AI within the boundaries you set

Follow the employer's rules on AI and disclose its contribution where required. When its use is allowed, give it the problem, the known constraints, and the assumptions you want challenged. Ask for alternatives or a critique of a specific choice. The product designer AI workflow provides a structure for keeping that work connected to your design process.

Keep a brief record of what you accepted, changed, and rejected. For example, the model might suggest collecting all documents immediately, while your proposal lets customers inspect the requirements first. Explain why you chose your approach. Practice writing an explicit prompt so the request includes the task and limits, then inspect the output yourself. You remain responsible for the submission's claims and behavior.

DiagramCopy

Rehearse the handoff in sixty minutes

Use a 60-minute practice session to rehearse the whole handoff. Spend ten minutes reading and framing the problem, ten comparing alternatives, twenty sketching the flow, and fifteen writing the decision note. Use the final five to review the submission. These are practice limits, not a claim about how long a real employer's assignment should take.

Read the work as if you were seeing it for the first time. Can you locate the problem, follow the flow, and explain the main trade-off without a spoken presentation? Ask a peer to name the assumption they would challenge first. If they have to guess what you intended, make that part clearer before adding more visual detail.

Start with the sample brief and produce one flow with one defensible decision. End by stating what you would check next. The skill you are rehearsing is the ability to connect a design choice to a user problem, acknowledge its limits, and explain how you would learn whether it helps.

Review my design take home assignment as a product design interviewer. The brief is [brief]. The time limit and AI rules are [constraints]. My chosen problem is [problem]. My proposal is [decision]. The evidence supplied is [evidence], and my assumptions are [assumptions]. My rejected alternative is [alternative and reason]. First identify any unsupported claims or gaps between the problem and the proposal. Then ask three focused questions about the trade-off. Suggest one practical way to investigate the most important unknown, including what I should observe and what finding would make me reconsider. Do not invent user research, performance figures, or employer requirements. Keep the review concise and distinguish facts, assumptions, and proposed checks.