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

Review: Slicing Pie

Slicing Pie is a new way to think about company equity splits, and it blows away the old methods you've probably used.

When Troubleshooting, Follow the Process!

When you're trying to troubleshoot something - a car that won't start, or a business that isn't working - follow the right process.

The Art of Finding a Way

Being resourceful and relentless is one of the keys to being successful (and a great shipper). When in doubt, find a way.

Why I Have a Cocktail at 3:30 Every Day

Every day at 3:30, I stop what I'm doing and have a cocktail. It's become an incredibly important part of my daily routine.

Everyone In a Startup Should Have This Skill

You know you need technical skills to build the product, and sales skills to sell it, but does your team have this critical skill?

Doing Things Makes You Feel Better

If you're feeling down, depressed or just in a blah mood, do something. Anything. Make a thing, clean a room. Action makes you feel better.

Review: Auth0

Auth0 is a service that provides identity as a service, so you never have to build authentication again. Here, I lay out the good and the bad.

Why I Unfollowed Everyone on Twitter

I unfollowed everyone (~4,500 people) on Twitter. Here's why I'd do such an insane thing.

How to Turn Off Facebook Live Notifications

Facebook Live is cool, but the constant notifications about new videos aren't. Here's how to turn them off and get some peace.

If You Don't Have a Feedback System, It's Not Agile

Everyone loves to throw around the 'agile' word, when talking about how they approach development. But, who's actually doing it, and who's just pretending?