How to Describe User Needs


#1

Hi guys,

I´ve an interesting challenge and want to ask you how you resolve that:

Issues, Bugs and Change requests are always described as “Technical solutions”.
this causes diverse problems because … well … solutions created by people who do not know the whole complexity of requirements are mostly not the best ones.

So I did some research and found the topic in a funny way described here:
http://bits.usablebytes.com/good-things-cannot-be-sold-they-can-only-be-bought/

Now … how should you describe those Issues?
I tried it based on those two articles which included some nice graphics:


http://alanklement.blogspot.co.at/2013/09/replacing-user-story-with-job-story.html

Do you´ve any interesting sources or links which could help me in to communicate it in a right, easy understandable way?

Would be cool if somebody has some ideas in here :slight_smile:

Best regards
Georg


#2

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.


#3

Hi Lukcha, Thx for your detailed description, I think you realy hit the point and showed some good examples helpful for such kind of discussiond or presentations. I also know that there is more than just user needs when we describe the process and I agree that it’s important to keep this in mind in discussions. It’s the same with developers or business guys, we all need to see and respect that there are other requirements than our core topics. I want to share a link to a link regarding this topic, maybe you like it: http://www.helloerik.com/treatise-on-user-experience-design-part-1 I think the first image is quite good and reusable for presentations I sometimes get in the situations that people perceive us UX guys as people making their life more complicated (why do I need to consider users, why do I need to follow user centered principles, why cant I follow just fast developable developer solutions which fulfil functional specifications?). It’s an everyday conversational work to change the perception to ux as being a problem solver. That’s the way I try to do that currently Thx once more, best regards Georg