Read the job description before sending your portfolio

Reading the job description carefully is a small action with a practical benefit: it helps you decide which evidence to show and whether the role is worth pursuing. It cannot guarantee an interview, and it does not solve every problem in a difficult hiring market. It does give you a better starting point than sending the same portfolio story everywhere.

I wrote about this because designers can spend a great deal of time polishing work for other designers while leaving the employer's actual need unexplained. A hiring manager should not have to infer why your strongest project is relevant to the problem they are trying to solve.

The aim is not to repeat the advertisement's keywords. It is to understand the work, test the match, and make your contribution easier to see.

Read for responsibilities before software names

Job descriptions often mix responsibilities, experience requirements, tools, and company language. Separate those elements before you decide how to respond. A named tool may matter, but it may also be a shorthand for a broader capability.

Look first at what the person will be expected to do. Will they discover problems, design solutions, support implementation, maintain a system, or help other designers improve their work? Which decisions will they own, and where will they collaborate?

Then look for context. An early product team, an established platform, and a company redesigning a legacy workflow can require very different examples from the same candidate. If the description does not give enough context, record that as a question rather than filling the gap with an assumption.

Turn the description into a short brief

Write a few sentences in your own words: the company appears to need this kind of contribution, under these conditions, with these uncertainties. If you cannot summarize the role without copying its language, you may not understand it yet.

Distinguish explicit requirements from your interpretation. “Work closely with engineering” is stated. “The company probably needs someone who can prototype in code” may be your hypothesis. Keep those separate so you do not tailor an entire application around a guess.

You should also note practical conditions that affect the match: location, working hours, employment arrangement, and compensation where provided. An exciting design problem does not erase a condition that makes the job unworkable for you. Resolve essential uncertainties early enough to save both sides time.

Match each important requirement to evidence

Choose a small number of requirements that seem central and identify where your work demonstrates them. You do not need a different website for every application. You need a clear path from the role's problem to a relevant example.

For each example, record the situation, your responsibility, a decision you made, and what happened next. If the outcome was not measured, say what you observed rather than inventing a metric. If the work was a team effort, distinguish your contribution from the group's achievement.

A candidate who can explain that connection gives the hiring manager something concrete to assess. A list of skills may be accurate, but it asks the reader to supply the link between the words and the work.

Choose the first project deliberately

Your most visually impressive project is not automatically the best introduction for every role. If the company needs someone to simplify a complex workflow, an example with clear reasoning about structure and interaction may deserve to appear before a more decorative piece.

Consider the order of the case studies you send, the link in your introduction, and the first example you discuss in an interview. Make the relevant work easy to reach. Check that the link opens, that access instructions are clear, and that the reader can identify your role without searching.

Where confidentiality limits what you can share, explain that boundary and offer an appropriate alternative. Do not imply that you can reveal private work just to remove friction from the application. A concise, permitted explanation of the problem and your responsibility can still be useful.

Write an introduction that earns its space

A useful introduction says why this role interests you and points to evidence connected to it. It does not need to retell your entire career or praise the company in broad terms. Specificity does more work than enthusiasm alone.

For example, you can connect a responsibility in the role to a relevant project and explain the part you owned. Treat that as a structure, not a script to fill with exaggerated claims. If the connection is weak, either choose better evidence or acknowledge that it is an area you want to develop.

Avoid claiming experience you do not have because the wording seems close. An application creates the first expectations for the interview. It is better to explain a transferable skill honestly than spend the conversation defending a misleading phrase.

Use a final application checklist

Before sending, check the basics:

• Can I explain what this company needs the designer to do?
• Have I separated stated requirements from my assumptions?
• Does the first project I share connect to an important responsibility?
• Is my own contribution clear?
• Do the links work, including any password or access instructions?
• Have I identified practical constraints and questions that matter?
• Would the introduction still make sense if I replaced this company's name with another? If so, is it too generic?

This should be a short review, not an excuse to endlessly rewrite an application. The purpose is to improve relevance and remove avoidable friction, then send it.

Treat the description as a starting point

A job description may be incomplete or outdated. Use the interview to test your understanding and update it. Ask what the team most needs from the person in the first months, what has changed since the advertisement was written, and how success will be assessed.

Reading carefully gives you better questions as well as a better application. It helps you identify a genuine match, explain the evidence you have, and notice when the role is different from the one you thought you were pursuing.