How do you choose a UX agency?

In short

The right UX agency is the side that offers the model that fits your problem, and puts it in writing. A big team doesn't always deliver the better result. A single person isn't always cheaper either.

I wrote this page from the buyer's point of view. But I sell services in this market myself, and I'll say so up front. The questions below should be asked of my own offers too.

First write down what you want, and only then choose the model. When the quotes come in, put them side by side with the list in the middle of the page.

Before you search

Before the first call with an agency, write a three-line note. Which flow is the problem, how do you know, and what should have changed at the end? Give everyone the same note, and the quotes can be compared with each other too.

“We want to redo our app” describes a feeling. “Half of new sign-ups drop out at the second onboarding step” describes a problem. Whoever hears the second can suggest a real method.

If you're not sure where the problem is, a UX audit up front makes the work cheaper. The audit tells you what's broken and what should stay. A design quote without that knowledge is a guess.

Know the rough budget too. Even if you don't want to give a number, give a range. Someone who knows no range proposes either the biggest or the smallest package, and neither may fit.

Also decide in the company who owns this work. However good the agency is, if nobody decides once a week, the work slows down.

Four models: agency, freelancer, design subscription, one-person studio

When you search for a “UX agency”, you meet four different ways of working. All sell design, but put responsibility in different places.

Agency

In an agency, research, design, project management and sometimes development are separate people. For big projects running in parallel, that's an advantage. If several product teams need support at the same time, an agency makes sense.

What to watch for: the person who sells and the person who does the work can be different. Some knowledge gets lost with every handoff. Ask the quote to name who is on the team.

Freelance designer

You work directly with the person doing the work, and communication is quick. It fits when you want a clearly bounded screen or flow designed.

The risk is capacity. If the designer gets sick or moves to another project, there's no replacement. Your own team often has to take on research and code.

Design subscription

For a fixed monthly fee you open a request queue. For teams with constant small design tasks, that's a predictable cost.

A subscription usually designs what you ask for. Questioning what you should ask for isn't part of it. If you don't know your problem, you pay every month and produce the wrong thing quickly.

One-person studio

The same experienced person does research, design and sometimes code. Because there's no handoff in between, a problem found in the audit doesn't get lost in the code. The price is usually fixed up front as a package.

That's how I work myself, so I use myself as the example. I deliver the UX Audit for one flow for $79 within 48 hours. The Design & Ship Sprint costs $999 for one week or $1,949 for two.

In the sprint I always work on one request at a time. All the numbers are public on the pricing page.

The limit of this model is clear too: capacity is limited to one person. If three teams need design in parallel at the same time, a one-person studio doesn't fit.

Model	Strong at	The first question
Agency	Big, parallel projects.	Who does the work, by name?
Freelancer	One clearly bounded flow.	Who takes on research and code?
Design subscription	Constant small requests.	Who decides what we design?
One-person studio	Finding and fixing the problem in one pair of hands.	What happens if capacity isn't enough?

How to read a portfolio

The screens in a portfolio show the designer's taste. You see the method in the case study's text. Look for the problem first: does it say who got stuck where, on which task?

Then look at the decision points. Which idea was tried and why was it dropped? A case study that doesn't tell this may be the neatly redrawn version of a design the client brought ready-made.

Finally, the result. If it says “The client was very happy”, ask whether a rate or the number of complaints changed. If there's no number, ask why.

Industry experience helps but isn't a requirement. A bank's transfer flow and the payment screen in a city's app share most of their problems. In regulated areas such as payments or health, though, finding someone who knows the rules saves time.

12 questions to ask

Ask these questions in the first call. How clearly the answer comes says as much as the answer itself.

1. Who does the work, and can I talk to that person now? If the person in the sales call doesn't do the work, talk to the one who does.

2. How did you solve a similar problem? Don't ask to see the final screen, but the process: what was the problem, and which idea was dropped and why?

3. Do you start with research or with screens? The Design Council's Double Diamond describes the design process in four phases: discover, define, develop, deliver. If the quote starts straight at “develop”, ask why.

4. If you do an expert review, how many people look at it? NN/g recommends that, ideally, three to five people evaluate the same interface independently in a heuristic evaluation. If only one person looks, ask how they close the gap. I describe the method in the guide to heuristic evaluation.

5. Do you test with users, and how many? NN/g writes in the same article that heuristic evaluations are not a replacement for user research. According to Jakob Nielsen, a first study with five participants finds 85% of usability problems.

6. What exactly is delivered? A design file, a clickable prototype, a findings report or working code. “UI/UX design” on its own isn't a deliverable.

7. Who turns the design into code? The result suffers most from details lost between design and code. If the agency doesn't write code, ask how it hands the work over to your developers. Also ask whether the components are tied to a design system.

8. What level of accessibility? The W3C's WCAG 2.2 standard has three conformance levels: A, AA and AAA. If the quote has no target level, accessibility is very likely not included. For online stores and banking that sell to consumers in the EU, the European Accessibility Act comes on top.

9. What happens if the scope changes? The scope changes in every project. How a change is priced has to be set in writing before you sign.

10. How many revision rounds are included? “Unlimited revisions” sounds good, but often shows there's no decision process. The number of rounds and what each covers have to be in writing.

11. Who owns the files and the code? Once payment is complete, you have to have access to the source files and the repo. Have that written into the contract.

12. How do we measure success? Before the start, record today's number, such as the completion rate or the number of support requests. Without a measure, nobody can say whether the work had an effect.

Putting quotes side by side

Comparing two quotes only by price is misleading. They usually don't sell the same thing: one includes research, the other code. Align the scope first, then look at the price.

To do that, send all candidates the same brief and get the quote in writing. Ask for everything said in the call to be put in the quote. A promise that isn't written down is remembered by nobody in the middle of the project.

Fill in the list below for two quotes. Don't tick anything that isn't in the quote just because it was said in the call.

Compare quotes

Put both quotes side by side. Tick each criterion that is stated explicitly in the quote.

1. Scope. Which flows and screens are part of the work is listed one by one.

Quote AQuote B

2. Deliverables. Everything delivered is listed: design file, prototype, report or code.

Quote AQuote B

3. Who does the work. Whoever does the work is named, and you have talked to that person.

Quote AQuote B

4. Research. There is a research or audit step before the design.

Quote AQuote B

5. Timeline. Interim deliveries and the end date are set as days.

Quote AQuote B

6. Revisions. How many revision rounds are included, and what happens if the scope changes, is set.

Quote AQuote B

7. Price. The price is fixed or capped, and the payment plan is set.

Quote AQuote B

8. Ownership. Files and code pass to you on payment.

Quote AQuote B

Every criterion you can't tick is a question to put to that side in writing before you sign.

These eight criteria are my own checklist, not a published scale. After every tick the two result boxes and the summary below them change.

If the same criterion is missing in both quotes, the gap is usually in your brief. Add the point to the brief and ask both sides again.

How the price is built

Quotes usually come in three forms. With a fixed price the scope is set up front, and the vendor carries the risk. With hourly or daily rates you carry the risk, so ask for a cap.

With a monthly fee you buy continuity. Ask when and how you can stop. My offers have no monthly commitment; you can buy an audit and leave.

Warning signs

Seeing one of these isn't a reason to say no on its own. But each one needs a written answer.

• Giving a fixed date for a big project without having seen the product. Work with a fixed scope, such as an audit of one flow, is the exception.
• You aren't allowed to talk to the person who does the work.
• The portfolio has only finished screens. If problem, process and result aren't told, you don't know how much of it is this side's work.
• “We don't need user testing, we know this.” Experience is valuable but doesn't replace the user.
• A scope in one line. A quote saying “UI/UX design of the mobile app” doesn't say what's not included either.
• A guaranteed rise in conversion. Nobody can give you a percentage without having seen your product.
• The source files aren't handed over.
• Suggesting patterns that deceive users for conversion. Suggestions such as a hidden subscription or a hard cancellation, that is dark patterns, bring numbers in the short term and complaints in the long term.

Start with a small piece of work

Starting with a small, paid piece of work before a big contract is the cheapest way to try the collaboration. An audit or the redesign of a single flow is enough.

In that first piece of work, see whether the delivery arrives on the promised day. See too whether the findings are written in a language your team understands. What snags in the first piece of work snags in the big one too.

Watch the communication as well. How many days does an answer to a question take, and who answers? As the project grows, that time doesn't get shorter.

In my model too, I recommend the audit as the first step. Book a sprint within 30 days and I take the audit fee off the sprint price. That way the trial work isn't lost.

My note

Part of my work starts with a design bought elsewhere and never built. The screens are nice, but nobody described them precisely enough to turn them into code. That's why I consider questions 6 and 7 the most important.

Don't get hung up on the model's name when choosing. Ask yourself: how many handoffs lie between the person who finds the problem and the person who fixes it? The more handoffs, the more precise your brief has to be.

If you're still unsure, we can look at your product together in a 15-minute call. If I'm not the right fit for you, I'll say so too.