or
"Let's not do the full UCD process",
"Two hours with users is a bit excessive, isn't it?",
"We will define the workflow and they [the users] will confirm it".
"We are building something new so we do not need to talk to them [the users]"
These are some delightful comments that were directed my way from, not clients, but team members when I dared suggest that we need to observe and talk to users of a back-end system to understand their motivations, goals, and behaviours. The excuse was that we had done enough business analysis to understand the workflows and that further exposure to users was unnecessary.
If nothing else, these comments reveal a fundamental lack of understanding of how UCD works and the value it adds to projects. Business analysis while concerned with workflows, business rules, and systems, it fails to identify people's motivations and needs when it comes to exercising those workflows. BA, while immensely valuable in getting any system properly working, is user agnostic in a sense, as users feature only as actors. UCD on the other hand, focuses on the human side of the system, concerning itself with the needs, motivations, and current behaviours of those who in one ay or another interact with the system.
So, what do you do when faced with such opposition? You gently ignore those comments, begin a UCD process and in the process educate the team. Well, that is what I am planning to do...
Comments