To be honest, the words “religious about” above don’t necessarily need to be crossed out. As a user experience professional, you sometimes feel like you’re preaching a kind of gospel because you keep repeating the same words over and over to a succession of project teams:
“Involve your end users.”
“Get feedback from the end user.”
“Talk to real end users.”
And, in a similar, mantra-like fashion, you get answers such as:
“I know exactly which users we’re doing this for.”
“I’ve worked on this topic for x years. I know what the users want.”
“I visited customer abc and talked to their IT people, and they should know.”
It’s almost like this is some kind of mandatory ritual. Get it over and done with if necessary, but don’t stop there. Exactly at this point the religious-like zeal of a user experience professional should kick in, which is:
Get input from the only source of truth – the end user.
Here are a few arguments that may help put a stop to an inanely entrenched situation (“I do know the user needs!” – “Oh no you don’t!” – “Oh yes I do!” etc.):
- Mantra 1: “I know exactly which users we’re doing this for.”
Every team member who says this indeed has an exact picture of the end user in mind. The problem is that these pictures do not necessarily match the end users that the other team members have in mind.
Experience has shown that the mere fact that a team plans to engage with real end users (be it through upfront user research, or by getting end user feedback on use cases or design prototypes) goes a long way to clarify for the team who they are designing for. This is simply because they are forced to agree and align on their perspectives in order to be able to identify the right end users for their research.
Say, for example, the target end user for a planned stock market app is a private investor. But is it a conservative user who carefully invests for the long term? Or is it one who is keen on trading shares a couple of times a day? These are two entirely different types of users with different activities and interaction goals. The product manager envisages the former, developers think it’s the latter – the perfect breeding ground for misunderstanding in the team and a product that won’t hit the mark for either user.
- Mantra 2: “I’ve worked on this topic for x years. I know what the users want.”
Having worked on a topic area might make someone a topic expert, but it doesn’t make them an expert in the end users’ work, life or motivational contexts. It is a bit like thinking you know everything about professional golfers because you used to play some golf yourself and watch it a lot on television. Your idea would be an approximation at best.
And adding “for x years” doesn’t strengthen an intrinsically weak argument, either. A quote ascribed by some to the late British Prime Minister, Harold Wilson, claims that “A week is a long time in politics”. If a week was a long time in 1960’s politics, how long is a week, a month, a year in technology in this day and age? What might have come and gone during this time? Technology changes with ever increasing speed, and so do the goals, tasks, needs, expectations and motivations of the users. Even if someone knew a user’s needs a couple of years ago, can this knowledge still be valid today when several different generations of technology users are simultaneously working in the same jobs?
- Mantra 3: “I’ve visited customer abc and talked to their IT people, and they should know.”
When developing business software it is important and indispensable to talk to IT or business customer contacts. What you want to learn from them is their take on technology and architecture aspects, and on the overall business process design.
If you talk to them to get end user requirements however, you are running the risk of adding a possibly contorting layer of IT or business-centered needs to your findings. IT or business experts may have to consider certain business indicators or company policies, for example, to cut down on IT products and features, or to focus on a certain technology. When you talk to them about the end users’ requirements – which they may indeed have collected from their end users – be aware that this information is still filtered by other people’s thinking, focus and constraints. End user input it is not.
This truth really is simple: End user needs and requirements can only be obtained from end users.