30-60-90 day plan for UX designers
On this page
- What makes a designer's ramp different
- The 30-60-90 day plan
- The heuristic audit as a first assignment
- What "on track" looks like at each checkpoint
- A filled example
- Critique and handoff: where designers win or lose trust
- What the hiring manager owes the new designer
- Mistakes that stall a new UX designer
- Adapting the plan
- Questions people ask
A UX designer's work is easy to judge on how it looks and hard to judge on whether it worked. A new hire can produce polished screens in their first two weeks, and a manager can mistake that for a fast ramp. A 30-60-90 day plan for a UX designer should instead test the full loop: understand the users and the product, design something through the team's real critique and handoff process, test it with people, ship it with engineering, and find out whether it changed anything.
This page is for the design manager, head of product or founder writing the plan for a product or UX designer joining an existing team. For the general version, see the 30-60-90 day plan template for new hires.
What makes a designer's ramp different
Designers sit between product, engineering, research and often marketing, and their output only reaches users through other people. That means a large share of a designer's ramp is learning how decisions get made: who has to agree to a design, what engineering considers buildable in a sprint, how the design system is governed and how research findings are stored and trusted.
It also means the most common failure is invisible at first. A designer who produces beautiful work that engineering has to rebuild, or that ignores existing components, slows the whole team down without anyone saying so until month three. The plan below gets that friction into the open by making handoff and engineering feedback part of every phase.
The 30-60-90 day plan
30-60-90 day plan — [Name], UX / Product Designer, [product area]
Manager: [name] Start date: [date] PM: [name] Eng lead: [name]
Tools: [Figma / other] Research repository: [tool or folder]
Design system: [name, link] Critique: [day and time]
DAYS 1-30 — Learn the users, the product and how design ships
Goals:
- Use the product end to end as each main user type would
- Read the last [6-12] months of research for the area; list what
is known, what is assumed and what nobody has tested
- Watch [5+] session recordings or sit in on [3+] support or
sales calls
- Learn the design system: components, tokens, contribution rules
- Take one small change (copy, empty state, error message) through
critique, handoff and release
Deliverables by day 30:
- A heuristic audit of the area: top problems, with screenshots,
severity and evidence
- One small shipped change
Check-in: day 30, with manager and PM
DAYS 31-60 — Design a feature through the full process
Goals:
- Own the design of one feature with the PM, from problem framing
to handoff
- Present work at critique at least [3] times, at different fidelity
- Run usability testing on a prototype with [5-6] target users;
write up findings before changing the design
- Pair with an engineer on feasibility before final designs
Deliverables by day 60:
- Final designs with specs, states, edge cases and accessibility notes
- A usability test summary that the PM and eng lead have read
Check-in: day 60
DAYS 61-90 — Ship, measure and contribute
Goals:
- Support the build: answer questions, review implementation
against designs, decide on tradeoffs quickly
- Report the result of the feature against its agreed measure
- Propose one design system improvement with evidence
- Plan the next quarter's design work for the area with the PM
Deliverables by day 90:
- Shipped feature and an honest result write-up
- A design plan for the next quarter
Check-in: day 90 — full review against this planThe heuristic audit as a first assignment
The day-30 audit does two jobs. It forces the designer to learn the product deeply, and it shows the manager how they prioritize. A good audit is not a list of everything that could look better. It ranks problems by how much they hurt users and the business, and it backs each one with evidence: a support ticket theme, a session recording, a past research finding or a step where analytics show people dropping out.
Ask for a short format: the problem, where it occurs, who it affects, the evidence, a severity rating and whether it is a quick fix or a larger piece of work. Then use the audit at the day-30 check-in to agree with the PM which problem becomes the day-60 feature, so the designer's first real project comes from their own findings.
What "on track" looks like at each checkpoint
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | The audit ranks problems with evidence; a small change has shipped; the designer uses existing components without being reminded | The audit is a visual redesign proposal; the designer has not spoken to support, sales or any users |
| Day 60 | Critique feedback is visibly reflected in later versions; usability findings are written up before the design changes; engineers say specs are clear | The designer brings only final, polished screens to critique; testing was skipped or run with colleagues |
| Day 90 | The feature shipped close to the design; the designer reviewed the build; the result is reported against the agreed measure | The designer moved on after handoff and the shipped version differs a lot from the design without explanation |
A filled example
Designer: Tomas Lindqvist (invented), joining as the second product designer at a company that sells scheduling software to clinics.
Day 30: His audit of the appointment booking flow ranked a confusing time-zone selector first, backed by a recurring support ticket theme and three session recordings where users booked the wrong time. Shipped a rewritten error message for double-booked slots through critique and the normal release.
Day 60: Designed a new time selection step with the PM. Brought low-fidelity sketches to critique first, then two prototype rounds. Tested with six clinic front-desk staff; four of six still missed the time-zone label in the first version, which led to a redesign before handoff.
Day 90: The redesigned step shipped. Over the first four weeks, support tickets about wrong-time bookings fell compared with the prior four weeks; he noted that a seasonal dip in bookings could account for part of the change. Proposed adding a time-zone pattern to the design system, with examples from two other product areas.
Critique and handoff: where designers win or lose trust
Two habits predict how well a new designer fits into a team. The first is bringing rough work to critique early. Designers who only show finished screens get less useful feedback and more defensive conversations. Set the expectation explicitly: at least one critique per feature should happen before anything is high fidelity.
The second is handoff quality. Engineers need every state, not just the happy path: empty, loading, error, permissions, long text, small screens and keyboard and screen reader behavior. Ask the eng lead at the day-60 check-in whether the designer's specs answered their questions or generated them. Pairing this plan with the 30-60-90 day plan for software engineers on the same team makes the shared expectations visible on both sides.
What the hiring manager owes the new designer
- Access in week one to the design files, the research repository, analytics, session recording tools and the support ticket system.
- A working relationship with the PM. The 30-60-90 day plan for product managers expects PMs and designers to do discovery together; make that explicit for both.
- A way to recruit test participants, such as a customer panel, an agreement with customer success, or a budget for a recruiting service.
- Clear rules for the design system: who approves changes and how a new component gets proposed.
Mistakes that stall a new UX designer
| Mistake | What it looks like | Fix |
|---|---|---|
| Redesign in month one | A full visual overhaul of the area, unrequested and unbuildable | Make the first deliverable an audit with evidence, not a redesign |
| Testing with colleagues | Usability "tests" run with people from sales or engineering | Budget time and access to recruit real target users |
| Handoff and walk away | The shipped feature looks different and nobody knows why | Make build review part of the day-90 goals |
| Ignoring the system | New one-off components in every file | Review component use in the first critique and every handoff |
| No measure agreed | Success is judged by whether people like the screens | Agree the measure with the PM before the build starts |
Adapting the plan
- UX researchers: replace the feature design with a research study from question to findings, and judge day 90 on whether the findings changed a roadmap decision.
- First designer at a startup: there is no system or critique to join, so day 60 includes setting up a basic component library and a regular review with the founder and engineers.
- Senior or lead designers: keep the phases, but add mentoring another designer and improving one team process, such as how research is shared.
If you are still hiring, the UX designer phone screen questions test the same habits this plan measures: evidence-based problem framing and working with engineers and PMs rather than around them.
Questions people ask
What should a new UX designer produce in the first 30 days?
A written audit of the product area they will own, built from using it, reading past research and watching real users or session recordings, plus one small design change taken through the team's critique and handoff process. That shows the manager how the designer thinks and teaches the designer how work actually gets shipped.
Should a new UX designer contribute to the design system early?
They should learn it and use it first. Proposing changes to shared components in month one, before they know why the components look the way they do, tends to create friction with the people who maintain the system. A small, well-argued contribution by day 90 is a better goal.
How many usability test sessions should a new designer run by day 60?
Enough to see repeated problems, which for a single focused task is often five or six sessions with people from the target audience. The exact number matters less than recruiting the right participants and writing down what was observed before deciding what to change.
How do I measure a UX designer's first shipped work?
Agree before launch what should change, such as task completion, time on a step, support tickets about that flow or a conversion rate, and how it will be measured. Then report it honestly at day 90, including when the effect is too small or too early to see.