If Your Brief Includes a UX Design Skills List, I Already Know How This Project Ends

It was a referral. Good sign, usually.

The brief was four pages. Also usually a good sign – someone had put in effort, thought things through, written it all down.

Then I got to page two.

"Required UX design skills for this engagement:"

What followed was fourteen bullet points. User research. Information architecture. Interaction design. Visual design. Prototyping. Usability testing. Design systems. Accessibility. Motion design. Copywriting. Data analysis. Workshop facilitation. Figma. "And general creative problem-solving."

(The last one is doing a lot of heavy lifting there.)

I've seen versions of this brief maybe thirty times. The UX design skills list that reads like someone copy-pasted a job aggregator into a Word doc and called it a scope of work. The list that tells me, before a single call, exactly how this project is going to go.

I didn't take it. Here's why.

A UX design skills list this long isn't a brief. It's a confession.

It's telling you the client doesn't know what they actually need. They've Googled "what does a UX designer do," found seventeen different answers, and decided they need all of it. Immediately. From one person. For a three-month engagement.

What they're describing isn't a designer. It's four people with different specialisations who've been compressed into a single contractor to save budget.

The translation is usually one of three things:

They've never worked with a designer before

So they're describing the entire field rather than the specific problem they need solved. They know the outputs they want (a better product, more users, fewer complaints) but have no idea which parts of the UX design skills spectrum actually produce those outputs.

This isn't stupidity. It's just inexperience. The problem is they don't know that yet, which means the engagement will involve a lot of re-explaining what design actually is before any design gets done.

They've worked with designers before and it went badly

So now they're covering themselves. If they list every possible UX design skill upfront, nobody can say they weren't thorough. The list is defensive documentation dressed as a brief. It's also a sign that the last project failed for reasons that weren't the designer's fault – which never gets mentioned, but shapes the whole dynamic.

They want one person to do a team's job

The full UX design skills list – research, systems, visual, motion, copy, data – represents about three different specialisms. Listing all of them means someone has done the headcount math and decided one senior contractor is cheaper than three people. Probably correct. Also a sign that the project will be chronically under-resourced and you'll spend six months explaining why you can't do everything simultaneously.

About two years ago I took a project with a brief exactly like this. Fintech startup, Series A, needed "full-stack UX" – their phrase, not mine – for a product redesign.

The UX design skills list in their brief had eleven items. I told myself they just didn't know how to write briefs. That once we got into the work it would focus down. That I'd help them figure out what they actually needed.

Month one: three research sprints, two of which got cancelled because stakeholders kept changing the questions they wanted answered.

Month two: design system work got deprioritised because the CEO had seen a competitor's marketing site and wanted to "refresh the visual direction first."

Month three: I was writing onboarding copy, doing customer interviews, redesigning the dashboard, fixing accessibility issues in a component library I hadn't built, and sitting in weekly "alignment calls" where nobody aligned on anything.

Month four: they asked if I could also "take a look at" the mobile app.

I had been hired to do eleven things. I was doing sixteen. None of them properly.

The product shipped eight months later. It was fine. Not good – fine. Because no individual piece of it had gotten enough focus to be good. The UX design skills list had guaranteed that outcome from the start.

Look, I understand why this happens.

Hiring designers is genuinely confusing if you haven't done it before. The UX/UI design field has a terminology problem – every designer describes their work differently, every job post uses different titles, and the actual skill overlap between "UX researcher" and "product designer" and "UI designer" is never explained clearly.

So clients do what any rational person does when confused: they gather all available information and list everything. Better to ask for too much than miss something critical.

The issue is that a UX design skills list written this way doesn't describe a project. It describes anxiety. And anxiety isn't a brief.

There's also a budget component. If you're a startup that needs serious product design but can't afford a full team, the all-skills-included brief is a way of trying to get team-level output from a single hire. Which is understandable. Which also doesn't work.

Not a UX design skills list. A problem statement.

"Our activation rate drops 60% between sign-up and first meaningful action. We need to understand why and fix it."

That's it. That's a brief. It tells me what's broken, what success looks like, and implicitly what skills the project actually needs – which turns out to be research, analysis, and interaction design. Not fourteen things.

The clients I work with now – the ones who end up in my process – come with problems, not skill inventories. They've usually tried to fix something themselves, hit a wall, and need specific expertise to get unstuck. They know what hurts. They don't necessarily know which part of the UX design or product design spectrum addresses it, and that's fine – that's my job to diagnose.

Same reason I ask on every discovery call: "What's the most expensive user behaviour on your product right now?" Not "which UX design skills do you need?" They don't know. I do.

When a brief does arrive with a UX design skills list, I don't immediately decline. I ask one question:

"If you could only fix one thing in the product this quarter, what would it be?"

The answer tells me whether there's a real project here.

If they answer quickly and specifically – "our checkout abandonment is at 73% and we think it's the address form" – there's a real project. The list was just inexperience. We can work with that.

If they can't answer, or the answer is "well, all of it really," the list wasn't inexperience. It was a preview of every conversation we'd have for the next six months. Too many stakeholders, too many opinions, no one willing to commit to a priority.

I don't take those anymore.

Here's the thing: clients who write UX design skills lists aren't bad clients. They're usually trying hard. They've done research, they've thought about the project, they're taking it seriously.

The list is just a symptom. It means the project hasn't been thought through clearly enough yet to know what it actually needs. And that's fixable – if the client is willing to do that thinking before the engagement starts, not during it.

If they're not? That's what the list is really telling you.

I can spot a redesign avoiding a real problem from the brief. I can spot scope creep before the contract is signed. And I can spot a project that's going to require sixteen different UX design skills from a person hired to do one job.

I've learned to read the brief.

(The fourteen-item list is the brief reading itself.)