Hey Dean! Great job with those ten points - I like that you’ve taken the approach to focus on principles when explaining, rather than jumping to a new process.
I agree with ASHM that the language could be tightened - being bold about what you mean instills more confidence, and is also likely to buy you some extra consideration. Like her, in my experience explaining, justifying and especially advancing the UCD culture in an organisation often relies on this.
There are a couple of other snappy things to point to that you might consider, if they work for you:
[LIST]
[]We look for the sweet spot at the intersection of business and user needs
[]Make each iteration good enough, and no better than it must be
[]Our team works collaboratively to make the most of our experiences (or something that expands #6 into the team too)
[]We set concrete, measurable goals at the beginning of the project so we know when we succeed
[]We favour clear communication over lengthy design specifications
[]We give the development team visibility on the project before they need to build it, so we get their involvement earlier in the process
[]We value solving real user problems over implementing ‘cool’ features
[]We apply the most appropriate tools rather than simply following a rigid project plan
[/LIST] I’d be really interested to hear how the explanation of the UCD process is received by the directors. Keep us posted!
