Onboarding a new colleague can be tricky. Acronyms, processes, and company-specific best practices can leave a new person’s head spinning for the first few weeks. A new design colleague is no different. They need to learn the ropes and understand how they can contribute in an impactful way, and they can’t do this alone.
Your role as the person onboarding this designer is to lay a roadmap for your new colleague to follow. You should be leading them to become as proficient as you in their ability to solve the problems your company or clients face.
One of the biggest issues that can come with new designers joining your team is the consistency of design output. You and your existing colleagues may already know the general design style of the company, but the new designer is completely fresh.
Thankfully, if you have an existing design system, then you can alleviate this slightly. Your tokens and components act as a guard rail for your colleague. Deciding on colors, typefaces and font sizing in advance, for example, leaves little room for error when your new colleague attempts a design. Including fully-built components makes your design system even more foolproof, both for new hires and seasoned teammates.
So let’s begin. Here are my recommendations in a step-by-step guide which should help your new colleague hit the ground running.
Onboarding tends to be a multiple-phase process, not something that you complete in one meeting. You want the designer to feel comfortable navigating, using, and updating the design system, so tackle this in stages.
The designer needs to be able to access the design system. Which platform is it hosted in? Do they have credentials to log into it? Does their machine support the tool underpinning the design system? These are all questions you should know the answer to before beginning.
Once the designer is in, you should begin giving them a tour of the design system. Typically, the structure you might have is:
If the design system is easy to navigate, the time spent going through these sections should be sufficient enough to enable the designer to know where to find the key areas (e.g. components, tokens etc.) in the future and explore further.
You should, however, spend longer on the components section. A component is likely comprised of multiple design rules, tokens and other components. This complex combination can take a while to get used to—especially if the designer has not used a design system before. Make sure you spend enough time explaining the components, how they work, and what updating them impacts. You don’t need to go through every component, spending a decent amount of time on a few rather than a short period on a lot of them will be more beneficial.
Once your designer is capable of accessing and referencing the design system, you should give them a small task to help them hit the ground running.
The task doesn’t need to be mission-critical; it’s better for it to be simple and have minimal impact on other projects. For example, is there an outdated component that you haven’t gotten around to updating? You could even adapt an existing component to have a few artificial faults which the designer has to fix.
The goal is to help the designer understand the design system and know how to reference it to rectify any problems.Once they’ve had an adequate amount of time to complete the task, you should review their changes together. Be positive: remember, this is their first attempt. Things might still be a little awry. But also remember to give meaningful and helpful feedback similar to what you’d give an existing colleague. You want the designer to understand the expectation you have for them and the level they’re required to perform at.
When you’ve completed the review, it might be time for another short iteration and a second review, or you could work on tweaking the design together.
A design system is never finished; it’s a living piece of documentation which is vital for the continued success of your product. Therefore, you will need to update it regularly and improve it to stay in line with the current industry and company best practices.
Once your new designer is comfortable working with the design system, it’s time for them to start contributing to it themselves.
For example, you could have the designer audit the design system for accessibility defects. They might look at color, interaction, or typeface choices and come to the conclusion that they could improve them. Your designer should present these ideas and then go about improving the design system with the alterations. They will begin to feel a sense of ownership over the design system while also adding value to your design team.
Finally, you want your designer to be able to produce assets that take advantage of your design system without constant reliance on everything being prepared for them already.
Set a challenge for your designer to create an interface which in part uses components and tokens from your design system, but also relies on them combining those elements with their own custom work. Their own work should match the brand identity and design system aesthetic for consistency.
What you’re looking for here is deviations from the expectation. Does it feel like two completely separate designs have been combined into one? Or has the designer successfully understood the design system, the brand identity, and has proven they can build on that?
You could review the interfaces with the new designer after they have completed the task. If their own ideas are of good quality then they could add their own components to the design system for future use across the design team. Again, this will build confidence and ensure the design system is providing full value.
The best way to learn is to teach. Once you’re satisfied that the new designer is capable of navigating, using, and maintaining the design system, you should give them the chance to upskill other members of the team. Let them educate others in the company across departments about why you use a design system, its benefits, and who can get involved. Check your colleague’s understanding by analyzing how they present the design system—it’s the ultimate test of how they understand your design system philosophy.