A frustrating pattern in design job hunting: candidates with genuinely strong skills self-reject from job postings because they've never held a job with "UX" or "UI" in the title, and assume that means they lack "UI/UX experience." Meanwhile someone with a mediocre six-month internship gets an interview because their resume uses the right words. The mismatch usually isn't about skill — it's about not knowing what hiring managers are actually screening for when they write that phrase into a job post.
Two candidates apply for the same junior role. Candidate A has a two-year title as "UX/UI Intern" at a mid-size company, but their portfolio shows three projects with a single final screen each and a one-line caption. Candidate B has never held a design job, but their portfolio includes one project — a redesign of a local clinic's appointment booking page — with a documented problem statement, three tested alternatives, a short usability test with five people, and an honest note about what didn't work in the first version. In most hiring processes, Candidate B advances further, because the artifact that actually predicts on-the-job performance — visible reasoning — is present, while the job title alone isn't.
"UI/UX experience" on a job listing is rarely a literal request for prior employment with that exact title. It's shorthand for evidence that you've gone through a real design process at least once: identified a problem, explored more than one solution, tested it against real users or real constraints, and arrived at something shipped or shippable. A bootcamp capstone project that shows this loop can outweigh a job title that didn't.
The exception is senior and lead roles, where "experience" does mean what it says — a track record of shipping products at scale, managing stakeholders, and mentoring other designers. For junior and mid-level roles, the bar is closer to "can you demonstrate the process" than "have you billed hours under this title."
A handful of activities feel like design experience but rarely register as such to a hiring manager: watching design tutorials, completing bootcamp exercises with no real stakeholder, or redesigning an app "for fun" with no documented reasoning behind the choices. These aren't worthless — they build skill — but they're practice, not experience, and presenting them as the latter in an interview tends to unravel quickly under a single follow-up question like "what did you learn from testing this?" if there was no testing at all.
Career-changers frequently already have relevant experience and don't recognize it as such. Someone who spent years as a teacher has direct experience simplifying complex information for a specific audience and iterating based on feedback — that's user research and content design, just not labeled that way. The skill of translating adjacent experience into design-relevant language, honestly and without overselling it, often matters more than the raw project count on a resume.
A recruiter or hiring manager typically spends well under a minute on a portfolio during the first pass. Ten shallow projects, each with a few final screens and no visible reasoning, read as "output" rather than "process" — and process is what's being evaluated. Three projects with an honest account of the problem, the options considered, what was tested, and what changed as a result are far more convincing, even if the final visuals are less polished than a portfolio full of dribbble-style shots.
| Level | What's Actually Being Evaluated |
|---|---|
| Junior / entry | Can you complete the design process end to end, even on a small project |
| Mid-level | Have you shipped work that survived contact with real users and real technical constraints |
| Senior / lead | Track record across multiple products, ability to set direction and defend decisions to stakeholders |
A few habits quietly undercut candidates who otherwise have a decent story to tell. Describing a project only in terms of the final screens, with no mention of what was tried and rejected, makes the work look accidental rather than reasoned. Listing tools ("Figma, Sketch, Adobe XD") as if fluency with software were the experience itself, rather than a means to it, signals junior-level thinking regardless of actual seniority. And claiming ownership of outcomes that were mostly a team effort — "increased signups by 40%" with no explanation of your specific contribution — tends to trigger skepticism rather than admiration in an interview, since experienced interviewers know a solo designer rarely drives a metric that large alone.
Beyond teaching, several other backgrounds carry design-relevant experience that's easy to overlook. Customer support roles build a detailed, first-hand map of exactly where users get confused — arguably more concentrated user research than most junior designers ever get access to. Architecture and interior design backgrounds bring genuine spatial reasoning and an instinct for how people move through and use a structured space, which maps surprisingly directly onto information architecture. Even retail or hospitality experience — reading a customer's confusion in real time and adjusting — is a form of live usability testing, just not one anyone thought to label that way at the time.
The common thread across all of these: the goal isn't to pretend the past job was secretly a design job, but to extract the specific, honest skill (empathetic listening, spatial reasoning, live problem diagnosis) and connect it explicitly to what a hiring manager is actually screening for.
Yes, as long as they show a genuine process — a real problem, alternatives considered, and some form of testing or feedback. A polished final screen with no visible reasoning behind it tends to count for less than a rougher project with a clear, honest process.
There's no fixed number that applies everywhere — companies vary widely in how they define "mid-level." A stronger signal than years is whether you've owned a project from problem to shipped solution more than once, ideally with at least one instance of the initial idea being wrong and getting corrected through testing.
Yes, but be precise about what they were — label them as personal or volunteer projects rather than implying paid employment. Hiring managers generally respect honest framing far more than they penalize the lack of a paycheck attached to a project.