How I set my UX work up for approval success
UX writing is an art. And like art, it’s subjective. So it’s often not what you say, but why you said it.
Take this treadmill for example. It was one of the many objects showcased for Ai Weiwei’s In search of humanity exhibition which I saw in Rotterdam.
If I didn’t attach any meaning to the picture of the treadmill, it’ll be very easy for you to dismiss it.
What I mean to demonstrate is, when it comes to presenting UX work, it’s not about just about showing the work itself. Substantial meaning needs to be attached to the work so that others can understand it.
In a way, us UX folks need to sell our work — especially when we’re trying to get stakeholders to approve it. I’m not a sweet talker and don’t have the gift of the gab. But I approach my writing very logically, so I play that up when I present my work. I explain the logic behind why I made certain UX decisions, and make sure my audience understands my perspective.
Using the 5W1H journalism framework to prepare my work for sharing
Before sharing out any of my work, I make sure that it answers these basic questions: what, why, where, who, when, and how.
What problem are we trying to solve?
Why do we need to solve this problem?
Where does this sit in the user journey?
Who owns this work?
When was this created and when is it expected to go live?
How did we arrive at this solution?
Key elements in my presentation
I prefer to present my work in a deck. While most of our UX work is done on Figma, not everyone is familiar with the tool. I’ve yet to meet a colleague who doesn’t know how slides work though. A figma file for a big project can be overwhelming for someone unfamiliar with the different user journeys. With slides, only 1 page is displayed at a time, so viewers can focus better. This restriction also helps me to sharpen my message by communicating a few key points at a time.
My share-out deck generally follows a problem-solution-rationale approach, and this is how I divide it into 3 main sections:
Project details
Date
UX owners
Teams involved
High-level project timeline
This encourages stakeholders to adhere to given deadines as any UX delays will have a snowball effect.
2. Problem and solution description
Problem
Try to highlight the significance of this problem. Why are we choosing to solve this problem and not the other 283 issues in the backlog?
If possible, I’ll justify its priority with research and data. After describing the problem, I’ll always ask myself: “so what?”. For example, instead of just saying, “When a payment takes longer than 3 seconds to process, we don’t display any differentiated messaging.”, I’ll add on the “so what?” element too: “This causes users to either prematurely close the window or make double payments. When this happens, we have to direct operational resources away from critical issues to help users.”.
Solution
A brief description of the high-level UX approach preps my audience for what they’re about to see in detail next. This is also a great opportunity for me to educate stakeholders on UX’s role in solving business problems.
3. UX solution and rationale
Screenshots
If there are many elements on the screen, I’ll highlight clearly what stakeholders should be looking at. If not, we might get stakeholders commenting on components which are not part of this new task.
If I’m presenting just a slice of the experience, I make sure to explain where it sits within the user journey too. Adding a couple of screens that come before and after help stakeholders to imagine a bigger picture while looking at my work.
Rationale
Just like how I step into the users’ shoes when I’m writing for a product that they use, I step into my stakeholders’ shoes when I’m preparing a presentation for them. I try to anticipate their questions and answer them in my copy rationale. Common questions stakeholders tend to ask include:How does the user arrive here? Where’s the entry point to this flow?
What comes before and after this?
Why have you chosen this term/phrase? Would the user understand it?
Is this how we describe <topic> across the product?
What happens if the user does <action>?
To answer these questions, I tend to bring in materials that have informed my writing decisions. This includes links to past research, user feedback, brand narratives, copy guidelines, and industry best practices.
Sometimes, the most effective rationale for writing things a certain way is because it’s been recommended or cleared by a subject matter expert within the company. I’m a fan of name dropping for cases like that, as people tend to approve work that’s already been approved by someone they know or trust. A simple line like “cleared with <name> from <department>” would give stakeholders the confidence to sign off on my work quickly.Options
If I have the luxury of providing more than 1 option, I’ll highlight the key difference between the options upfront, indicate my recommended option, and the reason behind my choice.
Takeaways
When preparing UX work for review, try to anticipate and answer questions that stakeholders might ask.
A solid presentation answers the 5W1H questions of journalism: what, why where, who, when, and how?
Each piece of work should be accompanied by a solid rationale writeup, which includes materials that have informed the UX decisions.
