Start by thinking about the needs of the people you’ll be presenting to. For a UX presentation, those people are often from the development team (mostly engineers who will change code, but maybe also content designers and other UX people) or from the executive team (mostly people who will make decisions about the direction of this work or other related work).
Typically, the development team and the executive team have different interests.
A development team may want to know:
- Which areas of our work are relevant to your UX work?
- Do these changes affect mostly content or mostly front-end development?
- Do these changes have an impact the back-end or technical architecture?
An executive team may want to know:
- Is this likely to deliver on the business case we’ve agreed on?
- Will it be ready for the launch date so we can safely align with our marketing plan?
- Are you asking for anything to happen elsewhere in the organisation?
Both teams probably want to know the following:
- What do you want me to do on the basis of this presentation?
- When do I have to do it?
- How would that benefit the organisation?
People working in different roles look for different levels of evidence, depending whether they agree or disagree with your findings or what you’re asking them to do.
But the actions that a development team might take – such as building some software, making some changes to existing software, or planning the activities for the next sprint – are rather different from the ones that the executive team might take – such as agreeing to a future plan, providing funding, or deciding to accept or cancel a proposal.
It can help a lot to be really explicit. Decide ahead of time about the “asks” – what you are asking people who hear the presentation to do, and when. Consider also discussing any major asks with the people involved, so that the presentation itself is a record of decisions already made rather than a (possibly nasty) surprise.
I’ve also found that people working in different roles look for different levels of evidence, depending whether they agree or disagree with your findings or what you’re asking them to do. If they’re in agreement with you and what you’re asking them to do aligns with what they’ve already planned, your message is essentially, “Good news, nothing to worry about,” so they might not look at your evidence very critically – especially if your colleagues are busy. But if you’re challenging their current plans or assumptions, you’ve probably got a lot more work to do. At least some of that work needs to happen before you create the presentation. Otherwise, they might see a challenge as bad news and, if you deliver it in a negative way in your presentation, they might resist what you want to do.