How to Onboard a Product Designer

If you’re launching a new product, and you’re not a product designer yourself, there’s a fair chance that at some point, you’ll need or want to engage a designer to help you think through how to deliver the best experience possible to your users. UX designers and product designers (I’m using these terms interchangeably in this post) can help you shape a vision of a product into a concrete set of screens and experiences, ensuring that the product makes sense, and successfully delivers the value you’re envisioning.

So, easy enough right? Hire a designer (or grab the one from the internal UX department), sit them down, spit out some requirements, and they’re good to go, right?

Not so much. There’s a right way, and a wrong way, to onboard a product designer. The BRD-driven approach is the wrong way, the narrative approach is the right way. Let’s look at each in turn.

The BRD Approach

I’ve seen this a lot. Company X hires a designer, or gets someone internal to help, and the initial meeting is a 90-page deck of requirements dropped into the middle of the table. “There ya go, that’s what you need to design”. While it’s understandable that, for the stakeholders, this approach appears to be comprehensive, it’s fundamentally flawed. To illustrate this, let’s look at how we might create a BRD (Business Requirements Document) of a movie that needs to be made:

ID Requirement
1 Actor A is an old man
2 Weather event should cause poor conditions
3 Actor D should disable power
4 Actor D should steal embryos
5 Dinosaur embryos should be contained in vials
6 Actor B is a palentologist
7 Actor C is a palentologist
8 Ensure that fences to dinosaur cages are controlled by power

You get the idea. It’s easy enough to see that this is a BRD for Jurassic Park, but the problem is, it doesn’t tell the story. Sure, we see the facts, but we’re not sure how they come together to form the narrative and experience.

Let’s try a different approach: narrative.

The Narrative Approach

Now, instead of our BRD, we sit down with the movie designers, and we tell them a story:

An old, wealthy man purchases an island, and starts a dinosaur theme park on it. He invites two palentologists out to the island to get their blessing. While on the island, a storm approaches. During the storm, a rogue employee steals embryos to sell to someone off the island, disabling the power during the storm, which disables the fences. Dinosaurs begin escaping, putting everyone in danger, and the plan to open the island is scrapped.

Now, sure, I missed some details, but we’ll get there. The big difference is, I’ve painted a much more clear picture of what the experience of the movie should be, highlighting areas of tension and excitement, and giving a much more full understanding of the kind of experience we’re after.

Your product is no different.

Why Narrative Beats Requirements

Requirements have their place. Requirements are a great way to double-check to ensure you’ve got full feature coverage. They’re a great way to structure development tasks. What they’re not good at is painting the idea about the product experience. Because requirements aren’t sequential, showing how an experience unfolds over time, they require a heavy amount of interpretation and synthesis to assemble them into a cohesive narrative. Looking at a disparate list of requirements is akin to getting individual sentences of a story, and trying to piece them together in the right order to make sense of it. There’s a fair chance you’ll get it wrong, or misunderstand how the parts come together.

With a narrative, that leap of synthesis is eliminated. The story tells us about the experience, and we can map parts of that story back to requirements in order to provide more context (“A rogue employee steals embryos (see Requirement 4 and 5)”). These two artifacts can work together to tell the story and provide the details, but without the narrative, the strict list of requirements lacks the context that a product designer needs to fully understand how the experience should unfold.

This Is About Knowledge Transfer

Why is this important? Because when we design something, we have to transfer knowledge from someone’s head to another person’s head, in order to give a clear enough level of understanding for that second person - the designer - to effectively help craft the experience. For millenia, we’ve told stories to transfer knowledge, and this is exactly the same situation. When you need to clearly get a concept across, start with the story, not the list of requirements. You’ll get to shared understanding in a fraction of the time.

By the way, this goes for other business functions as well. Want marketing to do a better job with your campaigns? Instead of a feature list, tell them a story about how the product is used. Same goes for sales, same goes for leadership, etc. Stories always win, start there.

Related Posts

Default Yes vs. Default No

Are you and your team members default yes, or default no? One is good for startups, the other not so much.

Check Your Echo Chamber

The people you surround yourself with create your reality. Choose carefully.

Don't Forget the Goal

There's only one thing that matters when you're building software.

How To Get a Job Offer

Want to get a job in the field you love easily? This is how.

Required Reading for All Couples

If you're married, about to get married, or just committed to someone for a long period of time, these three books are absolutely required reading.

I Launched a New Podcast, and I Want You to Call In

I just launched a new podcast called Design By Committee, dedicated to answering your questions about UX, product design, content, strategy and anything else tech.

Shitty Sales Have Made Product Development Harder

Shitty, one-sided sales processes have made product development much more difficult for early stage startups.

Why I'm Cold Emailing You

You might have gotten a cold email from me. Tasteless? Some people think so. Here's why I'm doing it.

How I Found Your Email

I've been cold emailing a lot of people, and many folks are surprised that I found their email. Here's where I dug it up.

Sales is User Research, Undercover