Onboarding New Designers to the Team: 30, 60, and 90 Days

How to design onboarding for a new designer: audit the documentation, assign a buddy, document unwritten norms, and measure progress at 30, 60, and 90 days.

info Quick Definition
Designer onboarding is the process through which a new person on a design team understands their role, the organization, and the team’s norms, until they can work without depending on someone for every decision. It is measured in milestones, not in the number of meetings.

What problem does it solve?

When someone joins a design team, they have to learn three things at once: how the company works, how this specific team works, and what is expected of their role. Most onboardings only cover the first. The other two are learned by accident, through corrections in design reviews, and that costs weeks.

Nielsen Norman Group (NN/g) describes onboarding as the process of getting new hires familiar with their roles and the organization, made up of shared documentation, events, training, and team building. For UX roles, it notes that onboarding helps people find their footing, make a good first impression, and build rapport with colleagues.

Why does this matter for a junior designer?

Because one day you will be the person receiving someone, or the one asking for a better onboarding. A junior who joins a team with no documentation learns faster if they know what to ask and whom. A junior who already works on a team can propose small improvements, such as a list of tools with access and a guide to how design reviews happen.

Onboarding is also a clear way to tell whether a team is well organized. If nobody can explain in an hour how the team works, the problem is not the newcomer. For the team-building side, see building a UX team and people management.

How do you design the onboarding plan?

NN/g proposes a seven-step plan that works as a guide:

  1. Audit the current experience. Review objectively what works and what does not in today’s onboarding.
  2. Identify gaps and pain points. Find where newcomers get frustrated and where new ideas would help.
  3. Create or update the documentation. Write guides that answer new hires’ biggest questions.
  4. Socialize the plan. Decide with UX leadership and management where the information will live and how it will be introduced.
  5. Introduce the documentation to new team members. Share the materials and onboarding events, formally or informally, depending on team size and culture.
  6. Check in frequently. Give the person a point of contact: according to NN/g, new hires do best when they have a person or group to rely on.
  7. Collect feedback. NN/g suggests doing it around the three-month mark, with a retrospective or a one-on-one.

For documentation, NN/g ranks the information to collect: first software and tool access, with guidance on when to use each tool; then where to find files and key information, such as the design system or research repository; then best practices for the role, team, and organization; and last, the key people to contact for specific questions. It can live in Confluence, Basecamp, or a living document, as long as it stays up to date. If onboarding is new to your organization, NN/g suggests starting with tools and access and building out the rest over time.

What should happen in the first week?

The first week is not for detailed project work. NN/g recommends using it to get to know the existing systems and tools, current design and research work, company culture, and the colleagues you will work with most. For day one, it proposes a welcome kit and an explanation of the company’s mission and how the team contributes. A junior who gets a project assignment on day one usually spends the week guessing.

NN/g also recommends assigning a mentor or buddy other than the manager: someone who answers candid questions and gives advice. Questions you would not ask your boss get asked of a trusted peer. For example, “is this really how we do it, or only what the document says?”

How do you document unwritten norms?

This is the point most often overlooked. Every team has norms that do not appear in the employee handbook: which channel is used for design feedback, when a review is requested, what each board label means. NN/g gives an example: the team typically uses Slack, not email, to get feedback on designs.

To document them, ask team members what they learned the hard way. Those answers are usually a good basis for the onboarding guide.

How do you measure the 30, 60, and 90 day milestones?

NN/g proposes milestones at 30, 60, and 90 days for moving from working close to the manager to working with minimal guidance:

  • At 30 days: comfortable with the core tasks of the role, working closely with the manager and others.
  • At 60 days: digs into the details of the role and starts taking on work independently.
  • At 90 days: performs tasks with minimal guidance and starts adapting the organization’s processes to their own way of working.

NN/g cautions that a new UX hire’s work will not fully align with the organization at first, so goals should be realistic. Turn each milestone into concrete team criteria, for example “delivers a screen with a single round of corrections”, and review them with the person halfway through. A rigid plan is of little use if the role is not yet defined.

When is a group onboarding NOT the right choice?

According to NN/g, collaborative sessions work for larger teams that hire several people at once, to explain workflows and answer questions together. On small teams, or when only one person joins, NN/g recommends pairing the newcomer with a designer or researcher to collaborate on a project or initiative.

Nor should an onboarding plan replace conversation. Documents help, but the first month is mostly learned by talking to people.

Example

Illustrative example: a team of four designers brings on a product designer.

  • Week 1: access to Figma, the task manager, and the component repository. A buddy explains how to request a review and what the board labels mean.
  • Weeks 2 and 3: she observes two design critique sessions and prepares a small screen for review with her buddy.
  • Day 30: the first formal review. The team notices she could not find the accessibility guide and adds it to the documentation.
  • Day 90: she carries a complete flow with autonomy and presents a decision to the team.

The change that paid off most was documenting the accessibility guide. It was not a problem with the new designer, but a gap in the team that onboarding made visible.

For how these reviews are given and received, the article on giving and receiving design feedback goes deeper.

Common mistakes

  • Filling the first week with project assignments before explaining the system.
  • Letting documentation go out of date and relying on the employee handbook.
  • Leaving out the team’s unwritten norms.
  • Using a rigid 90-day plan for a role that is not yet defined.
  • Assigning a buddy who has no time to do it.
  • Not asking the newcomer what was missing, at the end of the process.

Sources

Frequently asked questions

What is onboarding for a new designer?
It is the process by which a person who has just joined a design team learns their role, the organization, and the team’s norms, so they can work independently. Nielsen Norman Group describes it as the process of getting new hires familiar with their roles and the organization.
Who should support a new designer?
Besides the manager, assign a buddy or mentor who is not the manager, a trusted person for frank questions and advice. NN/g recommends this as part of the onboarding plan.
What should a new designer do in their first week?
Get to know the existing systems and tools, the current design and research work, the company culture, and the colleagues they will work with most. NN/g advises against jumping straight into detailed project work.
What is a 30, 60, and 90 day onboarding plan?
It is a set of three milestones for moving from working close to the manager to working with minimal guidance. NN/g suggests going from getting comfortable with core tasks (30 days) to taking on work independently (60) and performing with minimal guidance (90), with realistic goals.
How do you document a team's unwritten norms?
By capturing them alongside the rest of the onboarding documentation. NN/g gives the example that the team typically uses Slack, not email, to get feedback on designs. These norms are not in the employee handbook and are learned late if nobody writes them down.