What Pixar's Rules Applied To The UX Designers?
Pixar's rules of storytelling applied to Ux designers
Stories to engineers to build an amazing product.
Stories to marketing to broadcast a captivating message to prospects.
Stories to customers to inspire them to achieve great things.
Stories to the executives and board to justify the ROI of our product investment, and the list goes on…
Being a good storyteller is why some product managers, marketers, and designers make the leap from Good to Great.
Let’s become great storytellers
Emma Coats tweeted a series of basic storytelling tips while she was at Pixar. She shared the valuable lessons of our generation, Pixar.
Here I’ve digested the relevant rules Emma presented and reinterpreted them as: Seven habits of great storytelling for product managers & UX designers — Inspired by Pixar
1. Without a purpose there is no story
When we create the story, paint a good picture of what happens as the users interact with a particular product functionality. However, we often prescribe what should be built or how to use it and neglect the underlying purpose.
Why must you tell THIS story? What's the belief burning within you that your story feeds off of?
3. A hero to root for Everyone wants a hero to root for. Give me a reason why I should care for the hero of our story to get her job done. Why should I root for her success? What happens if she can’t get her job done using our product?
You may have great templates to document user and buyer personas, even have their first names and the colour of their eyes! Unfortunately, that’s just a lame character in a boring story. If customer success is the end goal, what makes you care for this character as you read their persona?
What will the hero of the story lose if she is not able to overcome the obstacles to get her job done? Will they lose their job? Will the project fail and they will lose millions? Emma goes further and suggests we stack the odds against her as we author her story:
What are the stakes? Give us a reason to root for the character. What happens if they don’t succeed? Stack the odds against.
4. A credible storyline Each scene in the story needs to be credible. We’ve all heard stories that have an overwhelming amount of unbelievable nonsense, and we’ve stopped caring for the hero. We lose our audiences when our stories lack credibility — what the user’s objective is, what’s at stake, and how they can overcome obstacles. Instead of getting engineers to build out the acceptance criteria laid out for them, get them to root for the hero instead.
If you were your character, in this situation, how would you feel? Honesty lends credibility to unbelievable situations.
5. Impactful story structure Every story has a start, an iddle, and an ending. A good story delivers the middle in a well-defined structure. Similar to a good speech, telling the story of a product capability is more impactful with a Tell-Show-Tell structure: First you Tell them what’s about to unfold, tell them you understand your user and what the user needs and wants to get done. Then you Show them how it happens. And finally, to wrap up, you Tell them why they should care. What’s at stake if the job doesn’t get done middle,
?The tell-Show-Tell method is commonly used for pre-sales demonstrations. It’s also applicable in product management and UX design. To elevate this method to the Pixar level, we can apply Emma’s suggestion, which is Kenn Adam’s Story Spine structure.
What’s innovative about your story? Who wants to hear the same story told, yet again, by yet another software vendor? What’s different about yours? You may be solving for the same “happily ever after” ending, but how does your story unfold differently? Emma’s advice is to not be afraid of throwing the first however-many iterations out, and starting from scratch till you nail it:
Discount is the first thing that comes to mind. And the 2nd, 3rd, 4th, 5th — get the obvious out of the way. Surprise yourself.
Begin with the end in mind Rule #7 — Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front.
“Seriously. Endings are hard, get yours working up front.” It’s hard to know how to measure success after everything is set and done. The feature is built, shipped, and released… now what? What was YOUR Objective?
What are the expected Key Results? Begin with the end in mind.
This approach creates a sounding board for us to reassess the validity of our decisions as change appears and we are forced to iterate our story and adjust the scope.
Break away from the habit of writing user stories and bulleted lists of acceptance criteria. Stop demoing features and listing benefit statements. Tell a good story, and you’ll end up with a passionate team who works on products your customers Love.
