"UX Designer" is one of the most overloaded titles on the remote market — in some listings it means running user research, in others pushing pixels in Figma, and in a third owning a full product area end-to-end. Those are fundamentally different jobs with very different compensation, and confusing them is the single biggest reason UX candidates end up in roles that don't match what they thought they signed up for.
Four jobs are hiding in the same keyword
Most skill pages split the title into three archetypes. UX design splits into four, because the research side is genuinely distinct from the design side — and intentional companies hire for them separately.
UX researcher. Owns user research end-to-end: interviews, usability studies, synthesis, and presenting findings in a way that actually changes what the team builds. Day to day: planning studies, recruiting participants, moderating sessions, writing up insights, and sitting in design review to make sure the research lands. Narrow craft, deep focus, high impact when taken seriously.
Interaction designer. Owns the interaction layer — flows, states, transitions, microinteractions, the detail work that makes an interface feel right. Day to day: prototyping, interaction specification, coordinating with engineering on the hard-to-describe parts. More focused than a full product designer, more craft-oriented.
Product designer. Owns a feature or product area end-to-end: research, flows, interface, handoff, and measurement. Day to day: a mix of research, sketching, design, review, and the cross-functional meetings that keep the product moving. The broadest role, and the one most likely to carry real product accountability.
Content designer. Owns the language of the interface — microcopy, empty states, error messages, onboarding flows, documentation. Day to day: writing and revising the words that appear in the product, collaborating with designers on flows, and often running small content tests. A growing category, especially at product-led companies.
Four employer types cover most of the market
UX roles cluster by how seriously the company takes research and craft, not by company size.
Research-mature product companies. Companies with a dedicated research team, a research ops function, and a real intake process from product and design. Usually hiring researchers and senior product designers separately. Strong pay, real scope, and the best environment for specialists.
Product-design-led SaaS. Mid-stage product companies where a small team of product designers owns research, design, and some of the interaction detail together. Scope is broad, trade-offs happen daily, and the best designers here grow into design leadership.
Design-tool and design-system companies. A smaller market — Figma, Framer, Webflow, Notion, and the rest. Users are other designers, which makes the bar on craft unusually high. Competitive to get into.
Enterprise incumbents adopting modern UX. Larger non-tech companies — finance, healthcare, logistics — catching up to contemporary product design practice. The process is slower and more meeting-heavy, but the problems are real and the scope is large. Good entry point for designers who want to work on serious systems without the startup tempo.
What the craft actually looks like
Very few listings spell out the full toolkit a remote UX designer needs day to day. What "UX Designer" usually implies in practice: fluency in Figma for design and prototyping; a research toolkit (often a mix of a research platform like Dovetail or Maze and plain video calls); an understanding of the design system the team uses; a basic grasp of accessibility standards; and — on senior roles — experience running studies, writing design docs, and defending decisions in writing to a distributed team.
Six things worth checking before you apply
These hold up better than any bullet list of tools, and they don't go stale when the research platform of the month changes.
- Which part of the UX discipline the role actually owns. Research, interaction, full product, or content. A good listing tells you. A weaker one just says "UX Designer wanted" and leaves you guessing — usually because the team hasn't separated the work yet.
- Whether the team has a research story at all. Mentions of a research cadence, a research repository, or named researchers on the team are all good signs. "We talk to users sometimes" is not research, and teams that treat it that way will ask you to invent the function on day one.
- How design decisions are actually made. Specific mentions of design reviews, design docs, or a regular cross-functional sync suggest a healthy process. Their absence usually means design decisions happen in Slack and nobody knows who has final say.
- Remote-work maturity. Good remote teams put their async habits in writing: how decisions are documented, how review travels across timezones, how onboarding runs without a full-team call. Design teams are often uneven here — the good ones stand out.
- Product scope you can say out loud. If you can't describe in one sentence what product area you'd be working on, the team probably hasn't agreed on it either. Vague UX scope on the way in becomes infinite revision cycles once you're inside.
- How the hiring process itself reads. A portfolio review, a paid design exercise with a real problem, or a structured critique — these come from teams that value your time. Unpaid multi-day projects that look a lot like real work are usually a sign the team doesn't.
The bottleneck is different at every level
Remote UX hiring is crowded at the junior end and very competitive at senior.
Junior is crowded because the entry point looks welcoming — bootcamps, tutorials, a portfolio of tutorial redesigns. What thins the field is evidence you've shipped a real feature inside a real team: a project where you scoped the problem, made hard trade-offs, and saw the result in production. Tutorial redesigns don't tell anyone anything they need to know about whether you can do the job.
At mid and senior, the craft bar barely moves. What changes is product judgement: knowing when research is worth doing and when to just ship and measure, when to push back on a brief, when a simple existing pattern beats a new one. That kind of thinking rarely turns up on a CV. It shows up in how someone describes the last hard call they made and what, in hindsight, they'd do differently.
What the hiring process usually looks like
Length varies — from two weeks at a smaller team to two months at a larger product company. The stages themselves don't move much: (1) application — portfolio, short intro, a tailored note about why this role; (2) screen — portfolio walkthrough, usually 30–45 minutes; (3) design exercise — a take-home or paired design session, ideally paid if it's more than a few hours; (4) final round — critique, team fit, often a whiteboard-style problem-solving session; (5) offer — comp, references, start date.
Red flags and green flags
Red flags — step carefully or pass:
- A listing that asks for "UX Designer" and then describes research, UI, and product design as if they were the same job.
- Companies claiming to "be user-centred" with no named researchers or public case studies.
- Unpaid design exercises longer than a few hours, particularly ones that would produce something shippable.
- Portfolio requirements that demand fifteen case studies or NDAs waived in the first round.
- Salary bands missing entirely, or a range so wide it carries no information.
Green flags — strong signal of a healthy team:
- A specific description of the product area, the research cadence, and how design and engineering work together.
- Public design writing — case studies, a design blog, a named design lead with their own work linked.
- A hiring process laid out step by step with time estimates at each stage.
- Paid design exercises, or exercises short enough that unpaid is reasonable.
- Transparent compensation and location policy, ideally linked from a public handbook.
Gateway to current listings
RemNavi doesn't post jobs. We pull them in from public sources and link straight through to the employer's own listing, so you always apply at the source.
Frequently asked questions
What's the real difference between a UX designer, a product designer, and a UX researcher? A UX researcher studies users and turns what they learn into evidence the team can act on. A product designer owns a feature or area end-to-end — research, interaction, interface, handoff. A UX designer, as a title, sits somewhere in the middle and means different things at different companies. Read the listing for what the role actually owns, not what it's called.
How much research am I expected to do as a remote UX designer? It depends entirely on whether the team has a separate research function. If it does, you're doing design work and consuming research findings. If it doesn't, you're doing both — and the listing should tell you that clearly. Teams that expect you to run research without naming it are almost always under-resourced.
Do I need to know how to code to be hired as a remote UX designer? No, but understanding how your design will translate to code makes handoff easier and gives you credibility in engineering conversations. You don't need to write production code. You do need to be able to read a component tree and have an opinion on responsive behaviour.
Why is remote UX hiring so uneven in quality? Because the discipline isn't standardised. Companies that are intentional about UX hire specialists and pay them well. Companies that aren't intentional bundle research, design, and UI execution under one title and pay less. Reading the listing carefully is the single most important thing you can do before applying.
RemNavi pulls listings from company career pages and a handful of remote job boards, then sends you straight to the employer to apply. We don't host the listings ourselves, and we don't stand between you and the hiring team.
Related resources
- Remote Figma Designer Jobs — Tool-first framing of the same design work
- Remote Product Designer Jobs — The broadest product design discipline
- Remote React Developer Jobs — Engineering partner for UX work
- Remote Product Manager Jobs — Strategy and direction partner
- Remote DevOps Engineer Jobs — Infrastructure and platform design