I was reading over the ever wise Matt Zimmerman and his blog post about Listening to Users; in it he argues that user involvement is a nuanced subject and which approach the developer takes can be highly dependant on the timing, cycle and context of the developing project. Providing examples and some interesting comment.
I basically agree with these ideas, but I wanted to add something more to the economic thought.
I talk about user involvement here; I never mean users who are programmers, users who help support other users or users who turn into developers by their continued project involvement. For that subject see User to Developer evolution.
What developers want from users is fine communication on what the challenges and needs they are facing. They would like as much depth into the issues with as much detail on the specifics which cause issues. This communication is not actually in effort to help the user, but is instead a way to help the developer’s project. The user can see the bug or interaction as a way to get their immediate issue resolved, but the developer will be focused on collecting and filtering the relevant information and making tasks to push the project forwards.
Of course the user will still benefit in due course; but the user’s direct support needs are instead not met by bug reports, but by support type people who may or may not know the aims of the project. The goal for support people is to give the user instructions so that they can mitigate their issue and it isn’t about helping the developer. A wily support person will be able to turn a successful support request into a successful bug report which the developer can process and turn into a permanent solution; on the other hand a user or support person who is used to mitigation strategy, but not used to developer interaction will fail to tie the loose end of why the user needed support in the first place.
This can lead to the dreaded ‘toxic workaround’ which Tim Cole has given a talk about. This is a workaround which becomes so well documented and so ingrained in the culture of the users of a product that they fail to actually tell a developer to fix it. So the problem always remains causing issue for anyone new and causing users to go through extra steps to get usable systems. A good example of this is in Ubuntu support channels when people are asked to and expected to compile anything instead of the code being added to a PPA.
In order the listen to users, I think a developer must know the difference between supporting the user, and supporting upstream development; which may place conflicting demand on the developer’s time. The user for their part, if they get frustrated with reporting bugs that never get to be solved, can lash out at developers, ordering and demanding action should be taken and issues resolved.
Of course, if the user isn’t paying the developer to fix their issues, then the user has no right to ask any developer to work on their issue. The user’s only real power is that they can be of use to the developer’s aims in their project’s future refinement. This is because the developer is the one that holds the majority of the economic power. When a developer talks with a user, it’s clearly with an effort to solve the issues the user has brought up; but I think the developer is always thinking about what fixes will benefit the project the most and which users are the most useful to communicate with to achieve those goals.
What are your thoughts?