Hi Georg, if I understand correctly, you’re after some diagrams, comics or articles that help explain why talking to the user directly is more helpful than generating a requirements document internally?
The Dilbert comic referenced in one of the links is one I often have pinned up when working onsite with a client.
Others that might be useful:
In terms of how I do it myself, I then also use a mix of the following:
- Start the project with some anecdotes about why user-centred approach is important for the project
- Start individual conversations with people about any questions they have about user-centred approaches
- Be as transparent as I can about what I’m hearing from users - get stakeholders to spend some time watching recordings or remote video feeds of me interviewing or testing with users, summary documents immediately after tests. The idea being that helping them get closer to the user without overthinking things lets them see for themselves
- Setting up the project to be based on user stories or job stories (even if the business isn’t) helps bring the user needs naturally to the surface (as referenced in Alan Klement’s article)
If it’s about explaining the importance of user-centred design, or UX in general, and people aren’t easily agreeing, then it’s not always going to be a quick fix - you’ll need to let it take time. Don’t think about it too hard - overdoing it can make it more difficult to communicate. But keep the conversations open.
And just a quick response to the usablebtyes.com article: Users are not always customers, and although the term ‘users’ is a bit de-humanising, it still covers parts of the business process that are either not customer-facing, and/or people outside the process that are not the primary audience but have a significant influence somehow regarding purchase decisions or product use. Being aware of the language used to describe things is important.
