Rationale 101

One of the pitfalls of a design presentation is the assumption that your audience — your stakeholders, your peers, your boss or your customers — innately understands the customer and their relevant details, the problem, and the opportunity.

AND where you are in the process — the current fidelity of your work and the reasons for that.

AND the reasons you’re sharing the work — whether it’s for help, a decision or just to inform the team of what’s already been done.

They don’t. YOU do (unless you don’t — in which case you need to start doing your whole job).

Here are a few simple points you can use to develop and present design rationale. And set up your presentation, and your team, for success.

It’s not exhaustive, but this should get you through 80% of presentations: WHY, WHO, WHAT, HOW, WHAT NEXT?

WHY ARE WE HERE TODAY?

High level agenda. What does success look like? What decisions are you making? What help do you need?

Will we need the whole hour?! I sure hope not.

WHAT IS THIS WE’RE GOING TO SEE EXACTLY?

What is the problem we’re solving? What level of fidelity is the design work? Are we reviewing wireframes or visual design? Where are we in the process? What will come next? Is the copy placeholder or final? If you don’t answer these questions, you’ll be answering 1000 other questions later.

Yes, this seems basic — and you may believe it’s obvious. It is not. People who aren’t designers think your wireframes look AMAZING. They are ready to ship it as it is. And if there are words — they look final. Don’t treat your audience like idiots — but treat them like visitors from another country. With patience and a little over communication.

WHO IS THE USER/AUDIENCE?

Share your persona. Make sure that the details you provide are clearly addressed in the use case — and that details of the persona are directly reflected in the data used to illustrate and populate the experience. No more than you need, no less than just enough.

In a plumbing metaphor — your user and their data are the water. Your experience is the pipes.

Avoid a “target.” Avoid “all widget-users” or “all service-consumers.” These generic audiences do nothing to help you make decisions, and do even less to help to ground your stakeholders and evaluate your progress.

And if they disagree with your persona, stop there. Defining your customer is critical to designing solutions that serve them. Get this right first.

WHAT IS THE PRIMARY USE CASE/ACTION/OPPORTUNITY?

A single sentence can help the audience understand where we’re focused right now. And it poises us, as the customer, at the starting line.

Again — obvious to you. Not your audience. You are the expert — set everyone up for success. And focus on the behavior you expect and the emotions you’ll elicit. NOT the flow.

A HIGH-LEVEL PREVIEW/WALKTHROUGH

Walk through what the customer experience is now (especially if the current solution is painful). This is incredibly powerful: illustrate the pain you’re addressing. Add quotes from customers. Make the problem real.

Especially for experience design, a post-it-note-fidelity customer journey sets context of where the process starts and concludes. Include a clear and simple indicator of the moments of truth — the :15 seconds where your customers must believe you’re delivering MAGIC.

YOUR DEMO (working code — a prototype — a story board — etc.)

Demo the whole experience, not the flow.

SHARE ANY CUSTOMER FEEDBACK THAT HAS BEEN COLLECTED.

Avoid “[customers] liked it.” Focus on “He wished for…” “She was surprised by…” and “8 out of 10 understood the value proposition.” Focus on behaviors. And Surprises. Then reveal the whys underneath the whats.

Call out specifically what customers say and do. Where they smile and frown and recoil and lean in? Where do they read aloud and how does the inflection in their voice change as they stumble over phrases or pictures?

NEXT STEPS

What are your intentions and recommendations as a result of what you did, observed and discussed as a team? Have a POV. Don’t ask “Are we on the right track?” You know that WAY more than we do. Point to the qualitative data that gives you confidence, and describe where you’re curious to continue to dig, iterate and experiment. Always be learning — and make those intentions very clear. Your pace of learning is far more important than your development velocity.

WHERE SHOULD THE AUDIENCE FOCUS THEIR FEEDBACK?

Avoiding terms like “does this work” and “do we think customers will get it” or “Do you like it?” Focus instead on “What’s your confidence that we’re focused on the right customer and problem?”

When your audience gives you terrible feedback (and they will), dig under the specifics. When they ask “Did you try…?” respond with “What would we be trying to learn there?”

Your rationale should build confidence that you know your customer and have clearly identified and locked on their problem. Then as long as your solutions are pointed there, design is set up for success. And then you can start to figure out how you’ll weave a cohesive story with sales, with customer support and product development managers.

Again — not everything. But enough to set most designers up for success most of the time.

Show your support

Clapping shows how much you appreciated james helms’s story.