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:

1Actor A is an old man
2Weather event should cause poor conditions
3Actor D should disable power
4Actor D should steal embryos
5Dinosaur embryos should be contained in vials
6Actor B is a palentologist
7Actor C is a palentologist
8Ensure 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.

Justin Davis稿源:Justin Davis (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 创业投资 » How to Onboard a Product Designer

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录