UX Designer Cover Letter Examples
For a designer the portfolio is the application. A hiring manager will open it, spend a couple of minutes, and form a view — so the highest-value thing a letter can do is tell them which case study to open first and what to look at inside it.
That is not what most design letters do. The example below is written by a product designer on a B2B logistics platform. Every name, employer and figure in it is invented.
The second job is attribution. Product metrics are team outcomes, and a designer who claims one outright is making a claim any experienced reader will silently discount.
UX designer cover letter example
A B2B product designer directing a reviewer to one specific case study. Fictional throughout.
Casimir Oyelaran-Whitfield
UX Designer · Research and Design Systems
Denver, CO · (555) 288-1174 · [email protected] · portfolio.example.com
Greeting
Dear Ms. Rasmussen-Adigun,
Letter
I am writing about the product designer role on your fulfilment team. If you open one thing in my portfolio, make it the shipment booking case study — it is the closest match to the work you have described, and the interesting part is the research rather than the final screens.
The short version: drop-off at the booking address step was 34%, and five usability sessions showed autofill and manual entry were fighting each other on mobile in a way none of us had predicted from the analytics. After we redesigned that interaction, drop-off went to 19%. I should be clear that the engineering team also fixed a validation bug in the same release, so the 15 points are not all mine. What is mine is the research that identified the cause; we had been about to redesign the wrong screen.
I also built and maintain our Figma design system — 90 components with variants and tokens, now used by three squads — and I introduced a WCAG 2.2 AA checklist into design review covering keyboard traversal and a screen reader pass before handoff.
The thing I would most like to ask about is how research is resourced here. I have worked with five-participant rounds I recruited myself, which is enough to find interaction problems and not enough to size them, and I would want to know what is realistic before I promise anything.
The metric is shared with engineering explicitly, and the applicant claims only the research — see below.
The portfolio is the application — the letter is the reading guide
A design hiring manager reviewing a stack of applications will open portfolios and skim. Which case study they land on is frequently arbitrary, which means a strong applicant can be assessed on their weakest work.
The letter fixes that for the price of one sentence. Naming the single case study most relevant to this role, and saying what to look at inside it, converts a random sample into a directed one.
Say what is interesting about it too. The example points at the research rather than the visual design, which both sets the reviewer’s expectation correctly and signals what kind of designer is applying.
This is also the argument against a generic portfolio link with no commentary. The work does not speak for itself in two minutes; a paragraph of direction is worth more than another case study.
B2B and consumer design are different constraint sets
In consumer products users are numerous, untrained and easy to test with, and traffic supports experimentation. In B2B the users are trained, the buyer is not the user, the workflows are deep, and there are often too few users to run a meaningful test.
Those constraints produce different practices. B2B research leans on contextual enquiry and small qualitative rounds; consumer work leans on experimentation and behavioural data at volume.
Say which you have worked in, and where you are crossing over, say what transfers. Interaction craft and systems thinking travel; assumptions about testing volume and about who decides do not.
Naming the domain complexity is worth doing too. Designing a shipment booking flow requires learning how freight actually works, and a designer who says they enjoyed that is describing a tolerance the role genuinely requires.
Research, interaction, visual, systems: say which you are
The title covers dedicated researchers, interaction designers, visual and brand-adjacent designers, design systems specialists and generalists who do all of it in a small team. A posting is usually written for one.
State your centre of gravity and your range. "Research and design systems" is a position; "end-to-end UX" is a phrase that describes almost every applicant and distinguishes none of them.
Say what you are weakest at, if the team is large enough to have specialists. A designer who says their visual craft is competent rather than exceptional, in a team with a strong visual lead, is describing a fit rather than a deficiency.
In a small team the opposite is true and breadth is the point — but say so explicitly, because a team of one needs someone who will write copy, build the prototype and argue with the founder about scope.
Attribute the metric honestly, and claim the part that was yours
Conversion improvements, retention changes and task-completion gains are team outputs. Engineering shipped it, product prioritised it, and something else usually changed in the same release.
A designer who claims the whole number is making a claim every experienced reader discounts. A designer who splits it — as the example does, naming a validation fix that landed in the same release — is making a smaller claim that survives scrutiny.
Then claim your part precisely. "What is mine is the research that identified the cause; we had been about to redesign the wrong screen" is a strong and specific contribution, and it is more impressive than the percentage it sits next to.
This matters more in design than in most fields, because design impact is genuinely hard to isolate and everybody in the hiring chain knows it. Honesty about attribution is therefore a competence signal rather than a modesty one.
A design system is an organisational contribution — give adoption
Building components is design work. Getting other teams to use them is organisational work, and it is the harder and rarer half.
Give the adoption figure alongside the component count. Ninety components used by three squads describes something that took hold; ninety components with no adoption number invites the suspicion that it is a personal library.
Say how adoption happened. Documentation, office hours, migrating an existing screen for another team, or getting the system into the engineering component library are the mechanisms, and naming one shows you understand the difference between building and shipping a system.
Maintenance deserves a mention as well. A system is a product with users, and a designer who has handled contribution requests and deprecations has done the part that outlasts the launch.
Accessibility: name criteria, not awareness
A large majority of design applications claim to care about accessibility. Very few can name a success criterion, describe a keyboard traversal problem, or say what they check with a screen reader.
Naming the standard and the practice is therefore an unusually cheap differentiator. A checklist applied at design review, covering keyboard order and a screen reader pass before handoff, is concrete and repeatable.
Colour contrast alone is not enough to claim. It is the one criterion every design tool now checks automatically, which makes it the weakest possible evidence of accessibility practice.
Where you have worked to a legal requirement — a public sector procurement, an accessibility conformance report, a remediation programme — say so. That is a different level of exposure and employers with the same obligation will recognise it immediately.
Handoff quality is what engineers actually judge you on
Engineers form a view of a designer quickly, and it is based almost entirely on what arrives at handoff: whether states exist, whether components are real components, whether edge cases and error conditions were considered, and how many questions the build generates.
This is rarely in a design letter and it should be. Handing off components with states rather than flat frames is a specific, verifiable practice, and quoting the engineering team’s own assessment of it is stronger than describing yourself as collaborative.
Name the edge cases you design for as a matter of course — empty states, loading, error, long content, permission variations. Every experienced engineer has been handed a design that covered only the happy path.
It is also the right register for the whole letter. Design roles are frequently sold on vision, and the day-to-day is specification. A letter that takes the specification seriously reads as someone who has shipped.
Practical points for a design application
- Name one case study to open first and say what to look at inside it.
- Make sure the portfolio link works without a password, or supply the password in the letter.
- State whether you are a researcher, interaction designer, systems specialist or generalist.
- Split any product metric you quote, and name the part that was yours.
- Give design system adoption, not just component counts.
- Keep it to one page; the portfolio carries the depth.
Frequently asked questions
A pointer to the single most relevant case study and what to look at in it, your centre of gravity within the discipline, a product metric with honest attribution, design system adoption figures, and specific accessibility practice.
No — it should direct attention within it. A reviewer skims for a couple of minutes and may land on your weakest work, so naming the case study to open first and what is interesting inside it is the highest-value sentence available.
Claim your part of it. Product metrics are team outputs and something else usually shipped in the same release, so splitting the credit and naming your specific contribution survives scrutiny in a way the whole number does not.
Name the standard and the repeatable practice — keyboard traversal and a screen reader pass at design review, for instance. Colour contrast alone is checked automatically by every design tool, so it is the weakest available evidence.