Rob Enslin's posterous

Rob Enslin's posterous

Rob Enslin  //  User Experience Designer, Product Design Manager, Head of UX by day and User Interaction Design Kingston University Masters student by night/weekend.

Dec 8 / 3:24pm

Knee-jerk reactions

"We must change the wording to...".

Sound familiar? If you're in the UX design field you will at some point hear those all familiar requests - demands even. It's happening a lot at the moment as my project gathers real momentum. The weeks of wireframing and sketching become a reality and exposed as a 'real' web page.

All through my career I've been exposed to demand requests in some form or another. So, I'm fairly comfortable dealing with it. And I think I have a good solution - well it works for me. I will always give my stakeholders/colleagues the chance to convey their views. Stay quiet and listen. Listen carefully. Be prepare to ask them to explain it in another way. Or better paraphrase their views, and then ask questions that articulates their view.

It's important to show you care and are genuinely interested to hear them out. In addition show that you are paying attention, by making notes that the stakeholder/colleague can see. Trust me, even if the requests are somewhat silly or unrealistic giving them the attention goes a long way in forging an understanding.

Just because you're paying attention does not mean you'll respond or act in a way they might expect. When you feel the request is inappropriate write sticky notes on the wall. Obviously where it's relevant add it to the existing backlog or list of To-Dos. Ensure you communicate what you plan to do with their request. Place your notes where people can see them and include their name against the request, on the note. You can then prioritise the requests in relation to all the others and against the agreed scope of development.

In summary:
1. Show interest
2. Listen whilst being spoken to
3. Ask for the issue to be asked in another if you can
4. Recite the issue from the requestors view and paraphrase if needed
5. Write it down (sketch too)
6. Post it so it's visible
7. Assign a name to the problem
8. Manage expectation - when and how it'll be dealt with
9. Discuss it with the rest of the team to agree a priority
10. Close it when it had been dealt with.