UI UX Design Services: 12 Things to Check Before You Hire a Designer

Buying UI UX design services looks simple from the outside: you pay a designer, and your screens get better. However, once you open a proposal, you find research, wireframes, prototypes, usability testing and developer handoff listed as separate items, each with its own price and its own risks. Personally, I have sat on both sides of that table since 2012. So this guide walks you through the 12 checks I would run before signing.

What are UI UX design services, and what should you check before hiring?

UI UX design services are a professional process that researches what users need, structures content and flows, designs the visual interface and then tests and hands the result to developers. Before hiring, you should get the scope, deliverables, ownership of files, testing, accessibility and handoff in writing.

UX (user experience) asks one question: what does the user want to do on this screen, and how easy is it? UI (user interface) answers with colour, type, components and layout. In practice, the two are different skills. Still, when they drift apart on a project, you end up with a screen that looks great but confuses people, or one that works but does not earn trust.

Also, this is not a list of common UX mistakes. If you want that angle, read my piece on SEO and UX page experience factors or the guide on how to balance UX and SEO. Here, the focus is the buyer: which questions you should bring to the first meeting.

Who is this checklist for?

I wrote it for businesses that buy design work from outside. For example, a manufacturer rebuilding its corporate site, a SaaS startup designing a customer dashboard, or an online shop simplifying its checkout all face the same risks. Specifically, they get a vague proposal, surprise extra fees and files the developers cannot use.

The questions stay the same whether you hire an agency or a freelancer. What changes is where the answers live. First, agencies usually bring a standard services agreement. With freelancers, on the other hand, scope often sits in an email thread. That is why I suggest you treat this list as a proposal comparison template. Write every supplier's answers in the same rows, and the reason behind each price gap becomes obvious.

One more note: nothing here replaces legal advice. In the ownership and contract sections I describe the general frame. For a large or cross-border project, have a lawyer read the final agreement.

In practice, the easiest way to use the list is to turn each check into a row and send the same questions to every supplier. Some answers will then come back blank. Those blanks tell you as much as the answers do. In my experience, most expensive mistakes come from thin proposals rather than from bad design.

Check 1: Which deliverables does the scope actually list?

The first question is always the same: what exactly do you receive for the money? After all, "website design" is not a deliverable. Ask for each item to appear on its own line, with quantities. Here are the deliverables I see most often in a UI UX project:

• Discovery and research outputs: stakeholder notes, user interviews, competitor review, personas or journey maps.
• Information architecture: sitemap, navigation and a list of page templates.
• Wireframes: low fidelity, greyscale page skeletons.
• UI design: full visual screens for desktop and mobile breakpoints.
• UI kit or design system: colours, type, components and states.
• Clickable prototype: an interactive file that walks through key journeys.
• Usability testing and report: findings and priorities.
• Developer handoff: specs, exported assets and interaction notes.

Not every project needs all of these. Still, seeing what is in and what is out stops the classic "testing was never part of this price" argument. Also pin down the number of screens. Instead of "around 10 pages", list the templates by name.

Check 2: Will the designer really talk to your users?

Many proposals include a line called "UX audit". When you look closer, it often means the designer browses your site for an hour and takes notes. That still has value. However, it is not the same as user research. So ask a plain question: which users, how many sessions and which method?

Even on a tight budget, I recommend you insist on three sources of input:

1. The objections your sales and support teams hear every week.
2. Analytics from your current site, for instance the pages where people leave or the form step where they drop out.
3. A handful of short interviews with real customers.

If you already have an audience profile, share it with the designer. Otherwise, my guide on target audience analysis is a good place to start. That way the designer builds on what you know instead of starting from zero. Also ask for the research as a written document. You will reuse it in the next campaign, too.

Keep in mind that research often changes the scope itself. Sometimes you discover a page you never planned; sometimes a section you loved turns out to be dead weight.

Check 3: When do you sign off wireframes and the prototype?

A wireframe shows the skeleton of a page without colour or imagery. A prototype links screens together so you can click through a real user journey. Both stages are also cheap. In other words, fixing a wrong decision here costs far less time than changing a finished design or a coded page.

So ask whether the process has a skeleton sign-off step. The flow I prefer looks like this:

1. You approve the sitemap and page list, with a written purpose for each page.
2. The designer presents wireframes for the main templates, and you agree on content priorities.
3. Next, the designer builds a clickable prototype for critical flows such as the quote form or checkout.
4. Finally, the visual design goes on top of the approved skeleton.

Also clarify what "prototype included" means. Sometimes it covers only one click from the home page to an inner page. The real value, though, sits in the flows where conversion happens. For the rules that make forms work, see my article on booking, quote and demo form design.

Check 4: Do you get a UI kit or design system?

A UI kit collects the repeating parts of an interface in one library: buttons, fields, cards, alerts and menus. A design system, however, goes a step further. It adds usage rules, spacing and states. For example, the designer draws a button in its default, hover, pressed, disabled and loading states.

Why does this matter? Because your site is a living product. For instance, six months from now you will want a new campaign page. Without a UI kit, every new screen looks slightly different and the brand slowly erodes. Developers then write a new component each time, and maintenance costs grow.

Look for these details in the proposal: HEX values for the palette, a type scale, grid and spacing rules, component states and an icon set. Even a simple helper like the HTML color codes tool keeps colour values tidy. If your brand identity is not ready for screens yet, fix that first with brand identity work. As a result, the interface design moves much faster.

Check 5: How many people will test the design, and how?

In a usability test, real or representative users try the design with specific tasks while the designer watches where they get stuck. For instance, you give the task "request a quote on this site" and observe whether the participant finds the form.

In his well known article on testing with five users, Jakob Nielsen of Nielsen Norman Group wrote in 2000 that a test with five people uncovers about 85 percent of the usability problems in a design. His real advice, though, is to run several small tests instead of one big one: test, fix and test again.

Look for answers to these questions in the proposal:

• Does testing happen at prototype stage or after the design is final?
• Who recruits participants, and does the price include incentives?
• Is the session moderated, or remote and unmoderated?
• Do you receive a findings report, and which revision round covers the fixes?

Above all, the last point is easy to miss. If fixes after testing eat your revision rounds, testing turns into a penalty for you.

Check 6: Which WCAG level will the design target?

Accessibility means people with visual, hearing, motor or cognitive impairments can use your site too. The international reference is the W3C's WCAG 2.2. Specifically, it rests on four principles: perceivable, operable, understandable and robust. It also defines three conformance levels, A, AA and AAA. In practice, most teams aim for AA.

Also, this is not a theoretical issue. WebAIM scans one million home pages every year. According to the 2026 edition of the WebAIM Million report, 95.9 percent of home pages had automatically detectable WCAG failures. The most common one, low contrast text, appeared on 83.9 percent of pages. Many of these errors start in design files, long before any code exists.

If you sell in the European Union, there is also a legal angle. The European Accessibility Act (Directive 2019/882) applies to certain digital products and services from 28 June 2025. So ask the designer: which level do you target, and how do you check contrast and keyboard focus? At WCAG 2.2 level AA, normal text needs a contrast ratio of at least 4.5:1. A designer who cannot answer with a concrete method probably leaves the whole topic to developers.

Check 7: Who owns the source files and the rights?

This is the check that causes the most disputes. Paying for design does not automatically hand you the source files or the rights. By source files I mean the editable working file in Figma, Sketch or Adobe XD. So a PDF or PNG export does not count.

In the United States, work by an independent contractor usually does not count as "work made for hire" by default. The US Copyright Office explains in its circular on works made for hire that commissioned work qualifies only in specific categories and with a signed written agreement. Therefore a written assignment clause is the safer route. Other countries have their own rules, so check your local law.

Look for answers to these questions in the contract:

• Will you receive the editable source files, and in whose account will they live?
• Does the assignment carry any time or territory limits?
• Who holds the licences for stock photos, icons and fonts?
• May the designer show the work in a portfolio?

A Figma file that lives in the designer's personal account is a problem I see often. If the relationship ends badly, your access ends too. That is why I recommend you create the workspace in your company account from day one and invite the designer as an editor.

Check 8: How many revision rounds do you get, and what counts as a revision?

"Unlimited revisions" sounds generous. In practice, it either lowers quality or leads the designer to stall the project at some point. Instead, the healthier approach is a fixed number of rounds per stage, plus a written line between a revision and a change of scope.

For example, changing a button colour or reordering two sections is a revision. By contrast, adding a new page template to approved wireframes or switching the target audience is a scope change, and it carries its own price. If that line is not written down, both sides enter an argument they each believe they will win.

The easiest way to make revisions efficient is to collect feedback through one person. When five colleagues comment separately, the designer receives conflicting requests. Instead, name one decision maker who merges comments and returns a clear answer each round: approved, or change these items. Also set a deadline for each round. For instance, commit to sending feedback within five working days.

Check 9: How will the UI UX design services end in a clean developer handoff?

A design has to be buildable, not just beautiful. Handoff is the bridge between UI UX design services and engineering, and it is where most value leaks. When a developer does not know how a screen behaves on mobile, where an error message appears or what an empty list looks like, the developer makes those decisions alone.

Here is what I want to see in a handoff package:

• Separate screens or responsive notes for desktop, tablet and mobile.
• Empty, loading, error and success states.
• Exported icons and images, as SVG plus raster files in the right sizes.
• Animation and transition notes.
• Time the designer reserves to answer questions during development.

Pay special attention to the last item. Many proposals, however, end the moment the file ships. Yet questions always come up during the build. So add a support window and a design review step, where the designer checks the coded pages against the design. I explain why mobile should come first in my article on mobile first design.

Check 10: Which pricing model fits your UI UX design services project?

Price depends as much on the pricing model as on the scope. When two suppliers quote the same job with different models, comparing totals directly is misleading. The table below sums up four common models from the buyer's point of view:

Whichever model you choose, tie payments to milestones: discovery sign-off, wireframe sign-off, UI delivery and handoff. That way every payment matches something concrete in your hands. If you want design and build from one person, you can see how I work on the web design service page.

Check 11: How should you read a portfolio?

A portfolio is a shop window, and a window never shows the whole store. For example, polished screenshots prove UI skill. To judge UX skill, however, you need case studies that explain the process.

A good case study answers a few questions. What was the problem? Who did the team talk to? Which alternatives did they try, and why did they drop them? What changed in the end? If a portfolio holds only glossy final mockups, ask the designer to walk you through one project from start to finish. One question works especially well: which decision changed after testing? The answer quickly shows whether the process really happened.

Other signals I look for:

• Does the portfolio include your industry or projects of similar complexity?
• Do live projects still look like the designs, or did they drift a lot?
• Does it show mobile screens, or only desktop?
• Can you have a short call with a reference client?

Browsing live projects yourself is the cheapest and most honest test. You can also see finished work on my references page.

Check 12: Which clauses must the contract include?

All eleven checks above only become safe once they sit in the contract. Verbal agreements cause no trouble while a project goes well. Then the first delay arrives, and everyone remembers something different. So make sure the contract or its statement of work covers at least these points:

1. Scope and deliverables: number of screens, breakpoints, inclusions and exclusions.
2. Timeline and dependencies, including your own dates for content and feedback.
3. Revision rounds and a change request procedure.
4. Assignment of rights and delivery of source files.
5. Payment schedule and milestone acceptance criteria.
6. Confidentiality and personal data, for example where you keep research recordings.
7. Termination: what happens to work in progress if the project stops.
8. Post handoff support period.

The personal data clause is the one most businesses forget. If the designer records user interviews or works with real customer data, the contract should say how the designer protects that data and when they delete it. Likewise, the termination clause matters just as much. If a project stops halfway, getting the files for the stages you paid for is far cheaper than starting from scratch with a new supplier.

What extra questions should you ask when collecting proposals?

The twelve checks form the skeleton of a proposal. When you choose between two suppliers, though, these extra questions often decide it:

• Who will actually do the work? The senior designer from the sales call, or someone else on the team?
• How many projects do you run at once, and how much time per week goes to ours?
• Who owns the content, meaning copy and images? Will you design with placeholder text?
• How will we measure success, and which metric should improve after launch?
• Who handles SEO? How will heading structure, URLs and content hierarchy show up in the design?

Above all, the content question matters most. A design built without real copy tends to break when the copy arrives: headlines overflow and cards grow uneven. Therefore I suggest you draft content for the key pages before design starts.

Also, do not skip the SEO question. If you are redesigning an existing site, design decisions can hit your rankings directly. My guide on protecting SEO during a website redesign covers that risk step by step.

Which red flags should make you walk away?

Some answers mean you should stop, however attractive the price. These are the red flags I see most often in the field:

• The supplier sent a proposal without talking to you or looking at your site.
• The answer to the source file question was "we don't hand those over", with no alternative.
• The accessibility question got the reply "that's the developer's job".
• Questions about portfolio projects got no concrete story about the process.
• The supplier wants the full fee up front, with no milestone approvals.

One flag alone is not a verdict. For example, a small freelancer may reasonably ask for a deposit. Still, when two or three flags show up together, they usually predict problems later. So add this list as a column to your comparison sheet before you decide.

What should you measure after UI UX design services go live?

A design project faces its real exam when the new design meets users, not when the files ship. That is why I recommend you note the metrics you will track, and their current values, before the project starts. Otherwise you can only answer "did the redesign work?" with a feeling.

In practice, the right metrics depend on the project. On a corporate site, form submissions and quote requests matter most. On an online shop, add to cart rate and checkout drop off come first. In a SaaS dashboard, you look at task completion time and support tickets. To choose the right goal, use my guide on setting website conversion goals.

One warning: do not judge the change by its first week alone. Because seasonality, ad spend and campaigns all blur results, patience pays. Compare similar periods instead, and use several weeks of data when you can.

How do you connect the design brief to a business goal?

Many businesses buy design with one goal: look more modern. That is not a bad goal. However, it is simply not measurable on its own. When you brief a designer, add a business goal next to the visual expectation.

For example, "visitors should reach the quote form from service pages more easily" or "fewer mobile users should abandon checkout" gives the designer a direction. As a result, feedback moves from "I don't like this colour" to "does this change serve the goal?" You will find more on this approach in my article on conversion focused web design.

Once the goal is clear, ask the designer to write down the primary purpose of each key screen. This small habit is the most practical way to cut sections nobody needs and to keep screens simple.

What should you settle before you decide?

In short, buying good UI UX design services depends as much on asking the right questions as on finding the right designer. Get the scope written as a deliverables list. Make research and testing concrete. Agree on an accessibility level. Put source files and rights in the contract, and do not forget support after handoff.

When you compare proposals on the same template, you will often see that the lowest price reflects the narrowest scope. That said, it does not mean the expensive offer is always right. It does mean you can see, line by line, what your money buys.

One last tip: do not decide on the design team's pitch alone. Read the proposal with the person who will manage the project day to day and with your development lead. That way you see early whether the deliverables are usable and how much work lands on your side. Put simply, a solid brief and a clear contract matter as much as the choice of designer.

If you want to review your project against these 12 checks together, get in touch. In the first call we look at your current site and goals, and we sort out which deliverables you really need.