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

Everyone Is Self Employed

The idea that you're not self-employed if you work fulltime somewhere is wrong. EVERYONE is self-employed.

The Real Reason to Learn to Code

Not everyone needs to be a programmer, but learning a little bit of coding can help in a lot of different areas.

Review: Keto Diet

I recently gave the Keto (Ketogenic) Diet a try. Suffice to works.

You Don't Need to Get it All Correct Immediately

Too many people wait on shit to be perfect. Get it close, leave out some stuff, and set yourself up to quickly iterate.

Using Foundation 6 in Angular 4 (or 2)

How to use Foundation for Sites 6 in Angular 4 (or any version 2+)

Great Products Need Great DevOps

In the quest for shipping great products, DevOps is often overlooked, and that's a mistake

How I Increased my Water Intake by 500%

We all need to drink more water, but it's hard to get in the habit. Here's a simple trick I used to get a 5x improvement on my intake.

Three Secrets That Made Cutting The Cord Easy

After decades of being attached at the hip to cable, I finally cut the cord, and it's been amazing. Here are three secrets that helped me get the most of it.

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.