Onboarding new designers to your product team

Two paths to design for design success

First impressions are important in any human interaction. For a new employee, the onboarding experience at a new job can set the tone for months or years to come.

But employee onboarding can be an after thought. More of a set of boxes to check, rather than an experience to design. Designers, being the observant ilk that we are, notice and take note of how our employers bring us on board.

But this isn’t an article about that.

Welcome to our Product

Companies are complex environments with sometimes (always) weird social dynamics. Products — in this case software products — are also complex things. They have legacy, history, baggage, drama, anxieties, insecurities, ignorances, inconsistencies, delusions, and potential for either self-destruction or greatness. (If you identify with these words, keep reading).

There’s no playbook for onboarding a new product designer into (onto?) a product. Why?

It depends.

It depends on a lot. Your product, its complexity, how well that complexity is documented, your users or customers, to what extent the company understand them and their reasons for using the product, your roadmap, your management, your processes in place, alignment across departments, collaboration, culture, diversity, your… ok take a breath.

The point is, it depends on your specific company context. Better yet, your complex product context. And, onboarding a new design hire onto your product should be designed based on that context.

Two Approaches

Here are two approaches that touch two opposite ends of the spectrum. I’ve experienced both, and present the pros and cons of each as an offering to you.

#1 Understand All the Things

This approach is what it sounds like. It entails sitting down with people for lots of exhausting yet enlightening conversations. It means pouring over product documentation to see how the predecessors turned abstract technical concepts into words and diagrams. It means not only listening to people, but internalizing product concepts. But when is this the right approach?

• Pros — Your designer knows your product, enabling them to live out their potential as a pantascopic designer. Their value reaches new heights. Better still if they can convey product complexity in a clear, succinct ways to teammates. They answer questions, discuss new things, weigh in on strategy, and have a perspective that can fuel innovation.
• Cons — The up side can also lead to a down side. Starting with instruction can lead to adopting company norms around a products narrative. If something is said to be impossible, this approach can squash fresh ideas from coming to the table. Even subconsciously. It can also create a dynamic where innovation is forfeited in favor of correct understanding. In other words, the designer learns facts, instead of breaking moulds.
• Takeaway — What’s the state of your product, and what will your designer will be delivering? If the product is still finding its legs, a bit insecure, and without proper documentation or aligned understanding across the team, this may be an approach that’d work. Things are up for grabs to some extent, but the product is in need of love. And after all, to know is to love. Amiright?

#2 Know Nothing & Embrace It

The opposite end of the spectrum is nothingness. A blank slate that is both ignorant and full of possibility.

• Pros — Beginner’s mind is generally something we want as designers. Well, there’s no better opportunity for this than in new employees. They don’t need to put on their beginner’s hat because they are true beginners. Competent, professional designer beginners, but beginners nonetheless. The insights, confusions, and logic that comes out of this approach may not be all gold, but they are valuable. Like bitcoin, they are fun to watch, not beholden to any lords or masters, and might even make you a lot of money.
• Cons — One of the big cons here is that its success is dependent on the designer’s ability to control this approach. It is easy(ish) to listen and digest information. It’s hard to look at something, develop ideas and opinions, and bring these ideas to the table for discussion. Or simply bring them to life in an unfamiliar environment. Unless the team is bought in, it will likely fail and make everyone miserable.
• Takeaway — Again, ask yourself where your product is, and where it needs to be. What are its big challenges? Do you not understand your users and need to invest in research? Have this designer be your first test case and document their insights. It’s likely what they bring up wont be all news to you. Or, they might bring a new framework of thinking that will alter your products future. But without internal buy in, it may flop hard. The uncertainty here makes the bitcoin analogy stick real good.

In Closing

Whatever approach you take, tailor it to the state of your product and the strengths of your designer. In the end, what the business wants to achieve through product design should always be clear as day.

I’d love to get your thoughts on this. How have you experienced product onboarding? How have you designed for it? What’s worked, what’s failed? Please share in graphic/excruciating detail.

Claps are free 👏 spread the love 💖