Most junior designers I've read about don't stall because the work is too hard. They stall because the portfolio still describes the work they did two years ago.
The tasks get bigger. The way they're shown stays small. That gap, between what you can do and what you can prove, is the whole problem this roadmap is built to close.
TL;DR: Mid-level is a scope change, not a skill upgrade: you scope problems instead of receiving them, and you can prove it with case studies. Sourced 2026 US data puts junior at $77,000-$121,000 and mid-level at $89,000-$137,000. The plan below covers roughly 18 months in three stages, with an artifact to ship at each one.
What Actually Separates Junior From Mid-Level Work?
Junior work is scoped by someone else: here's the screen, here's the spec, execute it well. Mid-level work means you do the scoping. You decide which problem is worth solving first, push back on a stakeholder's assumption, and own a flow from entry point to exit rather than one screen in isolation.
The cleanest test is whether you can explain a trade-off. "I chose a modal over a full page because the task tolerated interruption and people needed to keep their place in the list" is a mid-level sentence. "I designed the modal per the spec" isn't, even if the modal is beautiful. Nobody can verify how any one company grades this, so treat it as my working definition, not an industry standard.
Four things tend to change at once:
- Scope: from a screen to a flow, then to a flow plus its edge cases and states.
- Decisions: from "which option looks right" to "which option survives the constraint."
- Collaboration: from receiving feedback to negotiating it with engineers and product.
- Evidence: from screenshots to outcomes you can honestly claim.
How Long Does the Jump Take?
Honest answer: nobody has a sourced number for promotion speed, and I'd distrust any article that gives you one. What exists is salary banding. The UX Design Institute, working from Glassdoor data, defines junior as 1-3 years of experience and mid-level as 4-6 years (UX Design Institute, 2026).
Those are bands of total experience, not a countdown to a title change. A company can promote at month 20 or month 50. The 18-month plan below is something else: a schedule for building evidence. Finish it, and your portfolio reads as mid-level whenever the title catches up.
Variety beats tenure, in my opinion. Two years of onboarding flows teaches less than one year that includes a dashboard, a checkout, and a settings screen with nasty permissions logic.
The 18-Month Milestone Roadmap
Each stage has a scope you should be working at, an artifact you should have in your portfolio by the end, and the evidence a reviewer can check. Months are a pacing guide. If a stage takes you nine months, that's fine.
| Stage | Scope of work | Portfolio artifact | Evidence a reviewer can check |
|---|---|---|---|
| Months 0-6 | Full screens and small flows inside an existing system. Take specs, ask sharp questions, ship cleanly. | One polished case study of a small flow, plus a one-page before/after of a screen you improved | Real states (empty, loading, error), consistent spacing, specs an engineer didn't need to ask about |
| Months 6-12 | A whole flow you scope yourself. Run or join at least one usability test. Start documenting reusable patterns. | A flow case study with a written problem statement, plus a short pattern doc | A named constraint, a rejected alternative, a test finding that changed the design |
| Months 12-18 | A cross-screen problem with a stakeholder who disagrees with you. Touch system-level decisions: tokens, component states, naming. | A full-arc case study and one system contribution | A decision defended with data, a trade-off stated plainly, a result you can honestly claim |
Months 0-6: Make the Basics Undeniable
Your job here is reliability. Design every state of every component you touch, not just the happy path. Match the system's spacing and type scale exactly. Hand off with annotations so nobody has to ping you on Slack to learn what happens on error.
Pick one small flow and document it properly. Our designer-developer handoff guide covers what engineers actually need from a spec. Then take a screen that was already live and redesign one weakness, with a before and after. It's small, but it proves you can see a problem unprompted.
Months 6-12: Own a Flow
Ask for a flow, not a screen. Signup, an invite journey, a billing change, anything with more than three connected views and at least one awkward constraint. Write the problem statement before you open Figma: who's stuck, where, and how you'd know it's fixed.
Run a test. It doesn't need a lab. Five people clicking through a prototype will surface the loudest problems, and our guide to usability testing on a budget shows a setup that costs almost nothing. Watching a test yourself changes how you design; reading a report doesn't do the same thing.
Start a pattern doc too. When you solve the same problem twice, write the solution down once.
Months 12-18: Defend a Decision
This stage is uncomfortable on purpose. Pick a problem where a stakeholder wants something different from what you'd recommend, and bring evidence: a test result, an analytics screenshot, a competitor teardown, an accessibility finding. Then record what happened, including the parts where you lost.
Add one system-level contribution. It might be a token proposal, a documented component with all its states, or an audit that found twelve spacing values where the scale allows six. If your team has no design system, our guide to building a design system in Figma shows how to start small without a mandate.
Skills Checklist
Use this as a self-audit. Be strict: "I've seen someone else do it" doesn't count as a tick.
Craft
- Build components with variants, auto layout, and every state, including disabled, error, and loading.
- Hold a spacing scale and a type scale without eyeballing.
- Check text contrast against the WCAG 2.2 AA minimum of 4.5:1 for normal text, and make interactive targets at least 24 by 24 CSS pixels (W3C WCAG 2.2).
Research and thinking
- Write a problem statement before designing.
- Run a five-person usability test and summarize findings in one page.
- Say what you'd measure to know a design worked.
Collaboration
- Explain a design to an engineer in under two minutes, constraints included.
- Take feedback without defending the pixels, and push back with evidence when it's wrong.
- Write annotations that answer questions before they're asked.
Systems
- Reuse existing components before inventing new ones.
- Propose a token or pattern with a reason, not just a preference.
- Audit a screen for inconsistencies and list them.
If you can't tick at least two items in each group, that's your next three months of work. Spending the same time on a fresh visual style won't move you closer.
How Do You Know You're Ready? A Quarterly Self-Review
Don't wait for an annual review to find out. Every three months, sit down for an hour and answer five questions in writing. Nobody else needs to read the answers, which is exactly why they'll be honest.
- What did I scope myself this quarter, rather than receive?
- Which decision did I defend, and what evidence did I bring?
- What did I learn from a test or from data that changed a design?
- Which pattern did I write down so the next person doesn't redo it?
- Which case study in my portfolio is now weaker than my current work?
Question five is the one people skip. If the answer is "the newest one," you're fine. If it's "all of them," you have a documentation backlog, and that's a better problem than a skills backlog because it's fixable in a weekend.
Keep the answers in a running document. After two quarters you'll have raw material for a promotion case or a job application, written while the details were fresh. Memory is a terrible archivist: a flow you shipped fourteen months ago will have lost its constraints, its numbers, and the argument you won. The notes keep them.
One practical habit helps more than it should. When a project ends, spend twenty minutes writing the five-line case-study skeleton from the template above before you move on. It's rough, and half the results will be thin. Still, it turns a vague memory into a draft you can edit in an afternoon later, and it shows you early which projects never produced a claimable result.
How Do You Rewrite a Case Study to Prove Ownership?
Most junior case studies are chronological diaries: research, wireframes, mockups, "and then we launched." A reviewer skims it and learns nothing about your judgment. Restructure around decisions instead.
Use this template for each case study, in this order:
- Problem: one or two sentences. Who was stuck, where, and how did anyone know?
- Constraint: the thing that made it hard. A legacy component, a launch date, an API that returned data in an awkward shape.
- Decision: what you chose, in a sentence a stranger could repeat.
- Trade-off: what that decision cost, and what you gave up on purpose.
- Result you can honestly claim: the outcome, with its source.
That last line is where juniors panic, because they didn't run the experiment or never saw the numbers. Don't invent a lift. Claim what you can verify: "usability test, 4 of 5 participants completed the flow without help," or "engineering shipped it without clarification requests," or "the pattern was reused in two later features." A small true result beats a large vague one every time.
Here's the difference in practice. Weak: "I redesigned the invite flow to improve the experience." Stronger: "Invites failed silently when an email was already registered (problem). The backend couldn't reveal that for privacy reasons (constraint). I showed a neutral confirmation plus a resend link (decision). That meant users can't tell a typo from a duplicate, so I added an inline email-format check (trade-off). In a five-person test, nobody got stuck on the confirmation screen (result)." The second version is longer, and every sentence of it carries information.
If you're rebuilding your portfolio around this, our portfolio-building guide shows how much process detail to include before outcomes get buried.
Mid-level isn't a bigger portfolio. It's a portfolio where every case study proves you owned a decision, not just executed one.
What Salary Should You Expect?
Figures vary a lot by market, so start with the national bands. The UX Design Institute analysed Glassdoor data for US UX designers and published these bands for 2026 (UX Design Institute, 2026):
| Level | Experience | National salary range |
|---|---|---|
| Junior | 1-3 years | $77,000-$121,000 |
| Mid-level | 4-6 years | $89,000-$137,000 |
Now my own arithmetic, not a sourced claim. The midpoints are $99,000 for junior and $113,000 for mid-level, a gap of $14,000 or roughly 14%. Compare the bottoms of the bands and you get about 16%; compare the tops and it's about 13%. So a mid-level move is worth a low double-digit raise on paper, not a doubling.
Notice the overlap, too. A junior at the top of the band ($121,000) out-earns a mid-level designer at the bottom ($89,000). Location and company size explain more of that spread than the title does. The same source lists San Francisco juniors at $95,000-$151,000, which starts above the national mid-level floor, while its Austin junior band runs $76,000-$121,000.
I'd treat these as negotiation context rather than targets. They're survey ranges from a salary site, they mix employers and cities, and the page itself isn't perfectly consistent in how it states averages. If you're weighing freelance instead of waiting for an internal title bump, our freelance rate guide shows what mid-level skill commands by the hour, which is a quick way to test your market value.
What Mistakes Keep Junior Designers Stuck?
The biggest one: waiting for permission to think bigger. Nobody hands you mid-level scope. You take a sliver of it, do it well, and ask for more.
The second is a portfolio that lags your real work. If your best project is from your first six months, a reviewer assumes that's your ceiling. Revisit your case studies every quarter, not only when a job search starts.
A third, quieter mistake is staying in one lane because it's comfortable. Two years of only onboarding flows leads a reader to assume you can't handle a dashboard or a checkout redesign. Range matters more than depth in one slice, at least until you've chosen a specialty on purpose.
Is your portfolio behind your real skill? Run the checklist above and find out. Then ask your manager for the messy, underscoped ticket nobody wants, because unclear requirements are exactly where ownership gets demonstrated.
