Last week in my company we guested few Clients to show them some UX works done.
It was the first time I've seen the Client. it sounds strange, but this is Agency work sometimes: work flows and processes are a bit "adjusted"!
The UX deliverable to present was an Axure prototype, and it was pretty simple to be honest with you.
Sometimes , especially if the Client is not so sure about the scope or the product goal, putting them in front of something could be a discussione trigger and you can start gather some requirements.
It happened a lot of time in my carrier.
Anyway, because I didn't know the stakeholders and I did a bit of preparation, and these are my essential bullet points for that.
You can find them a bit cheesy and basic, but they help me when I'm a bit too confident in the work done and I tend to talk too much.
1. Share the work before presenting it
Stepping into a meeting with a "strictly-reserved" piece of work is never a good idea. First, because it could be always an opportunity way to have user feedback. Second, because as long as you're not a UX guru and nobody dare to speak to you, everybody has an opinion about the UX work.
And it's better to answer to these questions in the team, rather than in front of the Client. And also, in some case, your colleagues can have good ideas (again, the power of collaboration).
"Can you give me a productive opinion on this?" is a nice way to gather impressions.
2. Get a right slot in the agenda
It could be stupid to say but it quite crucial. Sometimes the Project Managers can structure the agenda to make fit time slots for other topic, adjusting yours. You have to check if the time for presenting is correct. Not too short, not too long.
3. Explain the demo nature
For several clients an interactive demo like an Axure prototype is a website itself. Sometimes they start panicking, especially when they see no colours and no visual elements.
So before showing it, it's relevant to specify:
- It's a demo, so it's not the final product. It means to be grey and maybe visually boring.
- It's a demo, so it can be imperfect and buggy
- It's a demo, so it can be partial (you can explain the difference between a vertical and horizontal mockup)
- It's a demo, so it can be change without too much effort (but we're not changing it because you were a fan of Tetris and you 're good at changing element combination).
4. Explain the structure
We're getting into the main part here. Showing the structure, the navigation and the sitemap can be a trigger of discussion on the Information architecture itself. So be prepared to spend a bit of time on this point.
5. Show the basic elements
Like the menu, the footer, the search. These are the elements the user will interaction more with so there must be an agreement on that.
6. Show the Homepage
This will trigger discussion about the business goal and the strategy in every sense. Be prepared to spend some time on this too, as you can gather additional requirements on the priorities, too.
7. Show the rest of the demo
If the client is silent is probably thinking or he's very confused. Adjust your speed of presenting to your stakeholders. It's not a marathon, and even if you don't show them the contact page or the error page, it's not a big deal.
Steal a bit of time from these part in favour of the crucial elements mentioned.
Ask them comments or opinions if you realise they're just asserting without agreeing. Make them speak. Silence is not a good sign.
Excitement is a good sign.
9. Show the demo functionalities
I love Axure. It's such a powerful tool, but you need to educate the Client to make them use it properly . The Client will give some feedback in the meeting, but mostly of them will follow after they will analyse in their office, page per page.
Show them how to find hidden interactions, how to comments, how to take screenshots and comments, how to visualise the responsive versions.
If necessary, send them by email a recap of all these functionalities.
And don't forget to include and repeat all the list in point 3.