Hire UI and UX Designers: Rates, Vetting, and Red Flags

What a UI and UX designer actually does, and where hiring goes wrong

A founder we worked with hired a designer off a portfolio full of gorgeous dark mode dashboard shots. Six weeks and $9,000 later he had a Figma file with 64 frames, zero auto layout, spacing values of 13px and 27px sitting next to each other, and text styles that existed only in the designer's head. The engineers gave up on Dev Mode and rebuilt from screenshots, guessing at padding. Worse: nobody had designed what the screen shows when the identity verification check fails, when the transaction list is empty, when the API takes four seconds, or when a merchant name is 80 characters long. Those four states were about 60 percent of the actual build. The pretty frames were the easy 40 percent.

Everything that goes wrong with this hire is somewhere in that paragraph. UX is the part that decides what screens exist at all: the flows, the information architecture, what a user is trying to accomplish, what happens on the unhappy path. UI is the part that decides what those screens look like and, critically, how they are constructed: components with variants, tokens for color and spacing and type, responsive behavior at real breakpoints, states for hover and focus and disabled and error and loading and empty.

Most job posts say "UI/UX designer" and expect one person to do both. That person exists but is not common, and the ratio is usually lopsided. A visual designer who calls themselves UX will hand you beautiful screens built on a flow nobody validated. A researcher who calls themselves UI will hand you a correct flow that looks like a 2011 admin panel. Figure out which half you actually need before you write the post, because the vetting is completely different.

The second failure mode is treating design output as pictures instead of a build spec. If the Figma file is not structured, your engineers become designers by accident. They will invent spacing, invent grays, invent error copy, and you will pay for that in design QA rounds forever.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Right when design is a continuous input: you ship weekly, you have a roadmap that keeps generating new surfaces, and someone needs to own the design system, sit in standups, and push back on the product manager. Wrong when you have one project. A full-time designer with no queue starts redesigning things that were fine.

Freelancer. Cheapest per hour and fastest to start. Genuinely good for a bounded piece of work: a marketing site, a mobile app's first 15 screens, a design system audit. The honest trade-off is continuity and accountability. A solo freelancer disappears for a week when a bigger client calls, has nobody reviewing their work, and rarely stays around for the two weeks of design QA that happens after engineering starts building. If you go this route, budget for the QA time explicitly and put it in the contract.

Design studio or agency. You buy a process and a team: research, IA, UI, prototyping, sometimes front end. Right for a rebrand, a zero to one product, or a genuinely hard UX problem where you need someone to tell you the flow is wrong. The trade-offs are price, a slower start, and the classic bait and switch where the senior who pitched you is not the person in your Figma file. Ask who is doing the work, by name, in the proposal.

Staff augmentation. A dedicated designer embedded in your team, billed monthly, backed by a company that replaces them if it does not work out. Right for most funded startups and mid sized product teams: you get seniority and a safety net without the salary, benefits, and hiring risk. The trade-off is that you still have to manage them. Nobody else knows your product. If you cannot give a designer clear problems and 30 minutes a week of feedback, no engagement model saves you.

What it actually costs

These are the bands we bill and see in Digital Heroes delivery. Rates move a lot with region and seniority, and a "senior" title means different things in different markets, so treat these as ranges, not quotes.

• South Asia and Southeast Asia: roughly $25 to $60 per hour for a genuinely senior product designer. Below about $20 you are usually buying screen decoration, not design thinking.
• Eastern Europe and Latin America: roughly $45 to $85 per hour, with strong overlap in timezone for European and US East Coast teams.
• US, UK, Western Europe, Australia: roughly $90 to $160 per hour for an independent senior product designer. Design studios bill $120 to $250 per hour, and brand led studios go higher.
• Fixed scope engagements: a focused product design project covering 12 to 20 screens with a starter component library, tokens, and dev handoff typically runs $6,000 to $20,000 depending on region and how much research is involved. A design system for an existing product with real component coverage is its own project, usually $15,000 and up.

The in-house math is where founders get surprised. A base salary is not the cost. Benefits, payroll taxes, insurance, equipment, software, and desk or remote stipend push the real number well above base. When a client asks us to compare a hire against a contract rate, we model 1.25 to 1.4 times base, and higher in markets with heavy employer contributions. Then add recruiting. Every client we have watched run this search either paid a contingency recruiter a fifth to a quarter of first year base, or paid in time instead, usually 8 to 12 weeks from post to signed offer for a product designer worth having. Then add ramp. A designer is not net productive on your product in week one. Four to eight weeks is normal before their work stops needing heavy correction. Add the Figma seats and any research tooling. A $120,000 designer is realistically a $175,000 to $190,000 first year decision, and you own that decision for at least a year.

How to vet a UI and UX designer

Do not review a portfolio. Review a Figma file. Ask for edit or view access to a real working file from a shipped product, not a case study page. If they cannot share anything due to an NDA, that is fair, but a serious designer has something they can show, even redacted. Here is what to look at.

File construction. Open the layers panel. Are frames built with auto layout, or are things absolutely positioned? Are there components with variants, or 14 copies of a button? Count the detached instances. Check whether color, spacing, and type live as Figma variables and styles or as raw hex values typed per layer. Check whether the variables are organised into modes, so light and dark are one set of tokens rather than two parallel files. A file with 40 unnamed grays and no text styles tells you the designer has never had an engineer complain at them, which means they have never shipped anything hard.

State coverage. Pick one screen with data in it and ask: show me empty, loading, error, permission denied, and the version with the longest realistic string. If they only have the happy path, they are a shot maker. This single question filters more candidates than anything else on this list.

Handoff literacy. Ask what happens after the file is done. Good answers mention Dev Mode, marking components ready for dev, annotated specs, a walkthrough call with the engineers, a shared Storybook or component inventory, and a design QA pass on staging before launch. If the answer is "I export the assets", you are buying a JPEG.

Systems thinking, against your actual stack. Do not ask about design systems in the abstract. Name the one you run. If you are on Tailwind and shadcn/ui, ask which spacing steps they design on and what they do when a Radix primitive does not have the behavior the mock implies. If you are on Material 3, ask how they handle dynamic color and elevation tokens rather than painting shadows by hand. If you are on Apple's Human Interface Guidelines, ask what they change when the same flow has to work on iOS and iPadOS. A senior designer relaxes when you name the library: the constraints are set, the spacing scale is decided, and they can spend their effort on the product. A junior tries to override the library with custom components, which is how you get a codebase where nothing matches.

Accessibility. Ask them to explain the contrast ratio on a screen from their own portfolio. WCAG 2.2 AA wants 4.5:1 for body text and 3:1 for large text and UI components. Ask about focus states and keyboard order, and about what the focus ring looks like on your brand color. Most designers have never thought about focus rings. The ones who have are the ones who have shipped to an enterprise buyer or a regulated market.

The research half. If you are hiring for UX and not just UI, ask about the last time research changed their mind. Good answers are specific: a card sort in Optimal Workshop that killed a nav structure, five Maze or usability sessions that showed people never scrolled to the pricing toggle, a Hotjar or FullStory session replay that revealed a rage click on a non button. Bad answers are personas and journey maps with no decision attached.

The paid exercise. Do not ask for a free redesign of your homepage. Pay for four to six hours and give them a real, small, ugly problem from your product: "here is our current subscription cancel flow, here is what support hears, here is our component library, improve it." Hand over the actual library file, not a screenshot. What you are grading is not the visual. You are grading whether they asked questions before starting, whether they pulled your existing components in rather than drawing new ones, whether they covered the error and confirmation states, and whether they can explain in five minutes why each change exists. A designer who can defend decisions in plain language will work well with engineers. One who says "it feels more modern" will not.

Red flags

• A portfolio that is only Dribbble style shots. Centered hero, three cards, a gradient, no real data, no states. Ask instead: "walk me through the least attractive screen you have shipped and why it looks like that." Real product work has ugly compromises in it, and the ability to explain the compromise is the skill.
• No auto layout, no components, no variables. This is the tell that they design pictures, not products, and your engineers will pay for it in every sprint. Ask instead: "how do you keep spacing consistent across 40 screens?" You want to hear about a 4pt or 8pt scale and tokens, not "I eyeball it."
• They want to redesign everything before understanding anything. A designer who proposes a full visual overhaul in the first week has not read your analytics and does not know which screens make you money. Ask instead: "what are the three screens you would not touch, and why?"
• Motion and prototypes that cannot be built. After Effects reels and elaborate Figma prototypes that assume physics your stack does not have. Ask instead: "what would this animation be in code, Lottie, Rive, CSS, or a Framer Motion spring, and roughly how long does it take an engineer?"
• Vanishing at handoff. A designer whose contract ends the day the file is delivered. Ask instead: "are you available for design QA on staging two to three weeks after handoff, and is that in your quote?" The gap between the Figma file and the shipped screen is where quality is won or lost.

When you should hire someone else instead

If your product already has a design system and you mostly need screens assembled from existing components, you do not need a product designer. You need a strong front end developer who has taste, and you will get to production faster and cheaper. If the real problem is that nobody knows what to build, a product manager or a founder doing five customer calls a week solves more than any designer will. If you need a logo, brand palette, and marketing site, that is a brand designer, and it is a different person from the one who will design your settings page. If you are pre revenue with no users, do not hire a UX researcher. Ship something and get real behavior to research.

Hire a UI and UX designer when you have users, a flow that is measurably losing them, and an engineering team fast enough to keep a designer busy. That is when this hire pays for itself.

At Digital Heroes we staff this two ways. For bounded work we run a fixed scope engagement: a discovery call, a flow and IA pass, screens with full state coverage, tokens and components in Figma, a handoff session with your engineers, and a design QA pass after your build. For ongoing work we embed a dedicated senior product designer with your team monthly, with a design lead reviewing their output so you are not relying on one person's judgment alone. Both start with your existing stack, whether that is Tailwind and shadcn/ui, Material 3, or a system you already own, because the fastest design work is the work that fits what you already have. If it is not a fit, we will tell you which of the roles above you should be hiring instead.