Die, deliverables, die

The longest report I’ve created was 120+ pages of text heavy detail that was probably never read outside the project room.

The only purpose of reports like these is to make the client feel like they’re getting value for money. They don’t help the organisation move on or change anything, and despite the quibbling over phrasing during the approval process that might almost make you think this shit really matters, most of them will get put in a drawer and forgotten about.

Can you tell, I don’t like reports. I don’t even like the good ones that are really succinct and insightful and visually appealing. Unless I can see what the report is for — what purpose it has beyond simply documenting the project — you can count me out.

The same thing goes for any deliverable that is created for the sake of ticking a box based on what the client thinks they need. Journey maps, personas, blueprints, storyboards. They can all be useful but if you’re creating them because they were in the brief, and not because there’s a pressing and urgent need for them, then they’re a waste of everyone’s time.

Oh I know sometimes you’ve got to bite the bullet and make an artefact. But the most impactful projects I’ve been involved in haven’t had any kind of “thing” as a deliverable. My favourite is an organisation we worked with recently where the deliverables were 13 mini pilots in progress, and not a report or journey map in sight.

Fundamentally we need to rethink what the outputs of our work as designers could look like. Here’s some ways you can do that.

Set expectations up front.

Be clear that you’ll create USEFUL things not just things the client thinks they want because they saw someone else had one and it was cool. That means you probably won’t know at the start what the deliverables are going to look like; that will emerge through the process.

I’m aware not everyone’s going to be okay with that uncertainty. Pick your clients, and use stories of how things ended up different-good to sell the possibilities. And if you have to commit up front to a journey map and a set of personas (ugh), sow the seed in your proposal and your kick-off session that maybe we’ll find something that will work even better.

This works best with clients who already have a design mindset, or clients who know how you work. Repeat clients make this easy and fun.

Be clear on intent.

Be really clear about WHY you’re creating whatever deliverable it is. Make sure you know why people want it, how it will be used, and the outcome you expect from putting this thing in the world. You’re then halfway to creating something useful.

For example, we had a client who wanted a toolkit and a training program to address their capability gap. Of course it turned out that the problem wasn’t capability; it was culture. That’s an over-simplification, there were a lot of different problems. But none of them were things that could be addressed by a toolkit and a training program. Once we’d identified what the actual problems were, we could start exploring what things might address them.

Explore your options.

Don’t just jump to the obvious solution or thing that you could create, instead explore your options. Take into account the intent and think about how best you can achieve that; maybe it could be a visual, a checklist, a pilot, a process flow, a spreadsheet, a conversation, a video, a board game, a way of working, or something else.

Test your deliverables the same way you’d test your ideas during the project. If you’re thinking about creating a video, make sure you try the concept out with your target audience and find out where and when they watch videos (if they even do), what length will be most effective, the style or format that works for them, and so on.

If all else fails…

After all this if you really, really have to write a report, apply the same principles. Make sure you’re clear on the intent, tailor it to the audience, and make it as useful and practical as possible.