It keeps happening. Someone asks: What do you use to present [insert deliverable here]. People chime in with various tools they use for creating that deliverable to make it easier for the people receiving the deliverables to understand.

But here's the thing. The issue isn't the deliverable (unless it's a spreadsheet). And it's not necessarily the presentation. The issue is that the people who are on the receiving end of the deliverable don't have context for the deliverable.

You and your team spent a lot of time – hours or even weeks – digging into the research and inventories and applied some strategy, information architecture, and design principles to come up with the deliverable at hand. And then you present it to a group of stakeholders and expect them to understand and make decisions within the hour you have with them.

It's no wonder you're having a hard time getting buy-in or answers or helpful feedback. It's no wonder that later in the project someone changes their mind even though they signed off previously. They didn't know what they were deciding.

A previous post addressed how to get buy-in for new design tools, which is basically the same advice I give to people presenting a site map or a model or wireframes or any other deliverable. Go on and read, that, this will wait.

I'll add two things here.

Tip #1: You have to have participation along the way. Call it participatory or collaborative design and make it sound fancy and cutting edge. Involve the right stakeholders at the right time. Do some sketching with them in meetings. Work through part of a problem on your own and then talk through the outcome with them to see if you're on the right track. This will all give them context for the deliverable that they must approve.

Tip #2: Be prepared with questions ahead of time. Do not ask questions like, "What do you think?" or "Is this okay?" Nothing about the work you do is about opinions. Here are some of the questions I had for a client on a sketch/wireframe recently:

About a list of links: Are there other things customers typically do in the Support Portal? I wanted to make sure we got the list correct according to things users actually do, not what the client wants people to do.
About an element: Do you want to drive traffic to this area? I asked this because I knew that the area in question was underutilized by users and not entirely supported by the client (yet!). The answer was no, for now.
About a heading: Is this the right label? I hadn't done user research so wasn't sure if this was what their customers had in mind when they arrived on this page. It wasn't; so we changed it to something more appropriate.
About an attribute in the display list: Is there value in listing the date? Again, I wasn't sure. There wasn't, so we left it off.

These questions allowed us to have a discussion about whether we were addressing the users' needs with the way we were presenting the information.

I'm not the only one talking about software and tools not solving what are really people problems. For a much bigger treatise on how software isn't the problem, Deane Barker has us covered.

For more in-depth advice on asking better questions for better feedback, Dan Brown is one of the best around.

Tanzen helps team with people problems disguised as technology or tool problems. Get in touch to see how we can help your team.