Product Designer
From first principles to hired, then on to senior, staff and design leadership, on free resources only.
- Lessons
- 99 lessons
- Time
- Job-ready in about 5 months at 10 h a week
- Creators
- 48 creators on YouTube
- Learners saving progress
- 1 learners
Curated by SageLords
Explorer to Expert
13 stages. Job-ready in about 5 months. The track keeps going for 2 levels past the hire line, learned alongside your job, so they aren't counted.
Levels describe what you can do in this career. They aren't job titles and don't match any company's levels.
Who it's for
For people who want to design software and are willing to be judged on artifacts rather than certificates: career changers from adjacent fields (marketing, support, teaching, front-end, graphic design), and working designers who have plateaued at mid-level and want a map of what senior, staff and leadership actually demand. You need patience for research and rewriting, and a tolerance for having your work critiqued in public; critique is the job, not a hazing ritual. It is not for you if you want purely visual work with no user contact (that is closer to graphic or brand design), if you want a role where output is specified for you, or if you are hoping to avoid writing. Product designers write constantly, and senior ones write more than they draw.
Where this takes you
By the hire line you hold a portfolio with two end-to-end case studies (one built from a written spec, one you scoped yourself), each showing research, rejected options, an accessible high-fidelity Figma prototype on a small design system, evidence from moderated usability tests and a stated measure of success, and you have rehearsed the four interview exercises: portfolio walkthrough, whiteboard, app critique and take-home. Beyond it you hold the evidence of senior and leadership work: an outcome review of a feature you shipped and measured, ownership of a design-system area or research programme with adoption you can show, a running log of design decision records, critiques and workshops you facilitated, a mentoring or design-ops change with a before-and-after, and a written design strategy that changed what an organisation chose to build.
Syllabus
Every lesson is open. The order is a recommendation, not a lock.
Explorer, three levels below the hire line
1 stage · about 6 hours
1
Orientation
You can decide, with evidence rather than vibes, whether product design is a career worth the roughly 22 weeks of focused work (at ten hours a week) it takes to reach the hire line, and you know what the ladder above that line asks of you.
Learn6 lessons · about 6 hours- 1
What product designers actually do all weekfemke.designStart here - 2
Telling UX, UI, product and graphic design apartBear Liu - 3
Reading the product design career ladderfemke.design - 4
The 2026 hiring reality for junior designersInès Mir - 5Reading real job posts as a requirements listUX Jobs Board
- 6Milestone: make the call
- 1
Novice, two levels below the hire line
1 stage · about 3 weeks
2
Design foundations
You can look at an interface and explain, in specific terms, why it reads clearly or badly, and rebuild it in Figma.
Learn10 lessons · about 3 weeksGuided build- 7
Visual hierarchy: making the eye go where you wantDesign Pilot - 8
Typography for interfacesDesignSpo - 9
Colour for interfacesJesse Showalter - 10
Gestalt principles and the psychology of groupingRohan Mishra - 11
Spacing systems, grids and layoutJesse Showalter - 12
Nielsen's usability heuristics as a working toolAI Design Professor | Nehmat Gereige - 13
Platform conventions: iOS, Android and the webFigma - 14
Figma essentialsfreeCodeCamp.org - 15
Auto layoutFigma - 16Guided build: rebuild three real screensFigma
Prove it: Guided build
Three screens from real products, rebuilt pixel-close in Figma from a screenshot, plus a one-paragraph annotation on each naming the type scale, spacing scale and hierarchy decisions the original made. Good when a stranger comparing your rebuild to the screenshot cannot quickly spot a difference, your layers are named and grouped sensibly, and your annotation identifies the underlying system rather than describing what is visible. This is practice, not portfolio material; do not publish it as a case study.
- 7
Advanced beginner, one level below the hire line
2 stages · about 6 weeks
3
Core skills: the UX process
You can take a vague problem statement through research, synthesis, structure and a tested prototype, following a process you can name.
Learn10 lessons · about 3 weeksGuided build- 17
The design process and the double diamondfemke.design - 18
Choosing a research methodJusteen15 - 19
Running a user interviewUX in the Head - 20
Synthesis: from raw notes to personas and jobsUX in the Head - 21
Journey mappingNNgroup - 22
Information architecture and navigationGleanUX - 23
Wireframing and sketchingGleanUX - 24
Components, variants and propertiesDesignWithArash - 25
Prototyping in FigmaTD Sunshine - 26
Moderated usability testingSamuel Fabayo
Prove it: Guided build
A small end-to-end practice run on a narrow problem someone hands you: three user interviews, an affinity map, one journey map, a sitemap, wireframes, a clickable Figma prototype, and two moderated usability sessions with notes. Good when your synthesis produces at least one finding that surprised you and visibly changed the design, and when your test notes record what participants did rather than what they said they liked.
- 17
4
First build
You can take a written brief you did not create and deliver a researched, tested, high-fidelity design without following a tutorial.
Build5 lessons · about 3 weeksIndependent project- 27
Framing a design problemDesign Sprint Academy - 28Project: design an app from a written specGeorge Frigo
- 29
Moderating your first real test sessionNNgroup - 30Iterating on evidence rather than tasteNielsen Norman Group
- 31Milestone: ship it
Prove it: Independent project
A complete design for the brief below: problem framing, three user interviews, a flow, wireframes, a high-fidelity Figma prototype, two moderated usability sessions, and a documented iteration that names what changed and why. Good when someone reading only your write-up can state what problem you solved, what you learned that you did not expect, and what you would do next, and when at least one design decision visibly changed because of test evidence rather than taste.
- 27
Job-ready after this level
Competent, the hire line
2 stages · about 8 weeks
5
Professional practice
You can work the way a design team works: inside a system, accessibly, with engineers and a PM, against metrics, and under critique.
Practice9 lessons · about 3 weeksGuided build- 32
Working within a design system: tokens, components and documentationUI Collective - 33
Variables, modes and themingAdi Purdila - 34
Accessibility: WCAG in practiceVeera Srivastava - 35
Interaction and motion basicsMark Nguyen | AI, taught well. - 36
Handoff and working with engineersJesse Showalter - 37
Working with product managers inside a delivery processfemke.design - 38
Product thinking and metricsDesign Pilot - 39
Giving and receiving critiqueAlicja Suska - 40
AI in the design workflow, honestlyAliena Cai
Prove it: Guided build
A small but real design system built from your first-build project: colour and type variables with a light and dark mode, a spacing scale, and six to eight documented components with their states. Plus one screen annotated for engineering handoff and one written critique of another designer's work. Good when switching mode changes every screen correctly without manual fixes, when every text and colour value on your screens is bound to a variable rather than hard-coded, and when your contrast checks pass at WCAG AA.
- 32
6
Portfolio piece
You can scope, run and publish a design project nobody assigned you, and defend every decision in it.
Build5 lessons · about 5 weeksPortfolio piece- 41
Choosing a problem worth a case studyNNgroup - 42Project: an end-to-end product design caseNielsen Norman Group
- 43
Writing the case studyAliena Cai - 44
Building and curating the portfolio siteAliena Cai - 45Milestone: publish and get it torn apart
Prove it: Portfolio piece
One end-to-end case study of a problem you scoped yourself, published at a public URL, plus your first-build project as a second, shorter piece. Good when: the problem is real and you can say how you know; the case study shows at least one decision you reversed and why; there is evidence from real users at two points, not just at the end; the final design is accessible to WCAG AA and built on your own components and variables; you state a success measure honestly, including where you could not measure; and you can present the whole thing in 20 minutes and then defend it under questioning for 20 more.
- 41
Landing the job
2 stages · about 4 weeks
7
Interview prep
You can handle every stage of a product design loop: portfolio walkthrough, whiteboard, app critique, take-home and cross-functional round.
Career6 lessons · about 3 weeks8
Get hired
You can run a job search as a process, negotiate an offer, and be useful in your first 90 days.
Career6 lessons · about 2 weeks
Proficient, one level above the hire line
3 stages · learned alongside your job
9
Senior product design: owning outcomes
You can own a shipped feature from framing to measured outcome: choosing what to cut, defining success before you design, getting it built to standard, and reporting honestly on whether it worked.
Build10 lessons · about 5 weeksProduction ownership- 58
Operating at senior scope: ambiguity, priority and judgementfemke.design - 59
Connecting design work to product strategyRoman Pichler - 60
Choosing UX success metrics with HEART and goals–signals–metricsNNgroup - 61
Reading analytics and measuring design impact after launchbeyond tellerrand - 62
Scoping under fixed time: appetite, cuts and trade-offsRyan Singer - 63
Experimentation: hypotheses, A/B tests and when not to run themLenny's Podcast - 64
Managing stakeholders and earning trust in design decisionsfemke.design - 65
Design QA and shipping to production qualityfemke.design - 66Project: own a shipped feature's outcome end to endKerry Rodden, Hilary Hutchinson and Xin Fu (Google, CHI 2010)
- 67Milestone: present the outcome review
Prove it: Production ownership
An outcome review (3 to 5 pages) of one feature you led that is live with real users: the problem and why it was prioritised; the success metric and guardrails you wrote down *before* designing; what you cut and why; the design and the key trade-offs; how you QA'd the build; and what the data and follow-up research showed after launch, including what did not work. Judge it on four tests: (1) the metric plan is dated before the design work and names a baseline; (2) at least one significant scope cut is explained in terms of the goal, not the deadline alone; (3) the result is reported honestly (a flat or negative result with a clear diagnosis passes, an unmeasured 'users loved it' fails); (4) a PM or engineer who worked on it would sign off the account as accurate. If you cannot yet own a live feature, the phase is not complete; say so rather than substituting a concept project.
- 58
10
Systems and research depth
You can own a piece of shared infrastructure (a design-system area or a research programme) that other designers depend on, and run research beyond interviews and usability tests.
Practice10 lessons · about 7 weeksProduction ownership- 68
Planning research from decisions, not curiosityNNgroup - 69
Surveys and quantitative research without fooling yourselfSarah Doody - 70
Jobs-to-be-done interviews and switch analysisLenny's Podcast - 71Scaling research: repositories, democratisation and ResearchOpsNielsen Norman Group
- 72
Owning a design system: governance, contribution and adoptionFigma - 73
Token architecture: primitives, semantics, components and modesUI Collective - 74
Auditing accessibility across a product and a systemUI Collective - 75
Content design: designing with wordsWANDR - 76
Service design and blueprinting beyond the screenNNgroup - 77Project: own a design-system area or a research programmeNielsen Norman Group
Prove it: Production ownership
Ownership of one piece of shared design infrastructure for at least eight weeks, with a written account of it. Either (a) a design-system area (a component family, the token architecture, or the contribution process) with its documentation, a decision log, and adoption evidence (how many teams or screens use it, what changed after); or (b) a research programme: a research plan tied to upcoming product decisions, at least two studies of different methods (one quantitative or survey-based), a findings repository others actually use, and a record of decisions the research changed. Judge it on: other people depend on it and you can name them; the documentation lets a newcomer use or contribute without asking you; there is evidence of use, not just of existence; and you can point to at least one product decision it changed or one inconsistency it removed.
- 68
11
Design rationale, critique and decision records
You can make design reasoning durable and shared: explain a decision so it holds under challenge, record it so it can be found a year later, and run the critiques and workshops where a team's decisions get made.
Practice8 lessons · about 5 weeksProduction ownership- 78
Articulating design decisions to stakeholdersUXLx - User Experience Lisbon - 79
Writing design rationale and design documentsfemke.design - 80Keeping design decision recordsADR GitHub organization
- 81Writing design principles that settle argumentsNielsen Norman Group
- 82
Presenting design work to executivesImpekable - 83
Facilitating design critique for a teamUX Tigers (by Jakob Nielsen) - 84
Designing and facilitating cross-functional workshopsAJ&Smart - 85Project: a twelve-week decision and facilitation logMicrosoft
Prove it: Production ownership
A twelve-week practice log from real work: at least eight design decision records written for live decisions, one set of product or team design principles adopted by your team, at least four critiques you facilitated (with your agenda and the decisions each produced), and one workshop you designed and ran with cross-functional participants (agenda, outputs, and what happened afterwards). Judge it on: each decision record states the context, the options considered, the decision, its consequences and its owner, and a teammate who was not in the room can understand it; at least one record was later consulted to settle or reopen a question; critiques end with written decisions rather than a list of opinions; and the workshop produced an output the team acted on within a month. Records written after the fact to fill the log do not count; date them as you go.
- 78
Expert, two levels above the hire line
2 stages · learned alongside your job
12
Design leadership
You can multiply other designers' impact through influence on what gets built, mentoring, raising the hiring bar and improving how the design team operates, whether you lead as a staff IC or a manager.
Practice7 lessons · about 5 weeksOrg impact- 86
Operating as a staff or principal designerDive Club 🤿 - 87
Influencing the product roadmap you do not ownfemke.design - 88
Mentoring designersCarla Harris - 89
Calibrating the bar: reviewing portfolios and interviewing designersOptionalOpen Design Docs - 90
Design operations: making the design team run wellFBTB - 91
Design leadership as organisational designNNgroup - 92Project: multiply other designers' impactAtlassian
Prove it: Org impact
Evidence of impact beyond your own work over at least a quarter: (1) a roadmap or prioritisation change you influenced, with the argument you made and the before/after plan; (2) a mentoring relationship of at least eight weeks with written goals set by the mentee and their own account of what changed; (3) one design-operations or team-ritual change you led (critique format, intake process, tooling, onboarding, hiring loop) with a measure taken before and after. Judge it on: the change would not have happened without you, and someone else can confirm that; the mentee's account names specific skills or outcomes rather than 'it was helpful'; the ops change has a number or a clear observable difference attached, and it outlasted your direct involvement. If none of these is possible in your current role, the phase is not complete yet; that is an honest signal about scope, not a failure.
- 86
13
Strategy and organisational impact
You can set design direction for an organisation: diagnose its design maturity, write a design strategy and vision that change what it chooses to build, and hold a quality bar across teams you do not run.
Build7 lessons · about 6 weeksOrg impact- 93
Design strategy: from diagnosis to betsMelbourne School of Design - 94
Creating an experience vision teams can build towardGoogle Design - 95
Diagnosing and raising an organisation's UX maturityNNgroup - 96
Setting a quality bar across an organisationFigma - 97
Pitching strategic bets to executivesFigma - 98Capstone: a design strategy that changes what gets builtNielsen Norman Group
- 99Milestone: the org-impact review
Prove it: Org impact
A design strategy document for a real organisation or product line, plus evidence of what it changed. The document covers: a diagnosis (UX maturity assessment, quality audit, where design is involved and where it is not), a vision artifact (a narrative, prototype or set of concept screens describing the experience two to three years out), three to five strategic bets with rationale and costs, and how progress will be measured. The evidence is what happened: decisions, investments or roadmap changes that followed, confirmed by someone in leadership. Judge it on: the diagnosis is evidenced rather than asserted; the bets each exclude something the organisation could otherwise do; the vision is concrete enough that a team could start building toward it; and at least one bet was funded, staffed or put on the roadmap. A strategy that was admired and not acted on does not meet the bar.
- 93
About this track
Product design (often advertised as UX design, UI/UX design or product design; the titles overlap more than the job ads admit) is the practice of deciding what a product should do for a person and then shaping the interface that does it. The work is roughly half thinking and half craft: framing a problem, talking to users, mapping flows, and then making screens that are legible, accessible and buildable.
**Hiring is portfolio-driven, not credential-driven.** Almost no employer will ask where you studied; every one of them will open your portfolio, looking for *reasoning*: the problem you chose, what you learned that changed your mind, the options you rejected, and what happened when real people used it. The first eight phases take you to the hire line (Competent) and through the interview loop: able to plan an approach to a problem nobody has written a spec for, execute it in Figma to a professional standard, and defend your decisions out loud. Most free curricula stop there. This one keeps going, because the skills that decide a design career after the first job are almost never taught: owning the outcome of something you shipped rather than the screens, choosing metrics and running experiments, owning a design system or a research programme, writing design rationale and decision records people can find a year later, facilitating critiques and workshops, influencing a roadmap you do not control, mentoring, design operations, and setting strategy at staff, principal or leadership level. Those phases (Proficient and Expert) cannot be completed in a weekend, and their evidence has to come from real work with real stakes (usually a job, sometimes a serious open-source, non-profit or side project). One honest caveat: design has a thinner free-resource layer than engineering, and it thins further the more senior the topic. The best free material is excellent (Nielsen Norman Group for method, Figma's own channel and Config talks for tooling and systems, conference talks and long-form interviews for leadership) but it is scattered, and some senior topics (decision records, mentoring, hiring) have no good free video at all. Where that is the case the topic says so and points to the best written source instead. Every resource here was chosen individually and URL-verified. On time: the week estimate counts focused study and project hours at about ten hours a week (roughly 22 weeks to the hire line and interview-ready, and about 28 more for the senior and leadership phases). The second figure is the deliberate-practice time only. The evidence for those phases has to be produced in a real role over months, so in calendar terms the path from first job to expert-level impact is measured in years, and nobody should read the number as a promise otherwise.