In the vein of stating the blindingly obvious:
designing useful and usable tools isn't just about good widgets. There can be great widgets that will let a person carry out a task.
But what if the person doesn't want to carry out that task?
For insance,
In the UK there's a requirement to make publicly funded research publicly available - many places are turning to repositories like Eprints that will enable this process to happen. But right now, getting papers into Eprints is a manual, tedious process: filling in fields and fields in forms.
The "pro bono" argument is that increased access to the data will enable better access to cutting edge research.
A slightly more self- interested benefit is that there is research to show that openly available papers are more than twice as likely to be sited than those that are not.
But that petition to self-interest to leverage future benefit to off-set current pain does not have an immediate, perceivable benefit for the person stuck with uploading papers. We've seen that people just don't do it.
As Alan Dix might put it, the perceived cost is higher than the perceived benefit. The What's in It for Me effect only works, it seems, when that benefit is immediately perceivable. For instance: take these steps now to upload these papers and you'll never have to add them to your cv again: they will automatically update; also, one line in a web page will let you publish all your papers formatted anyway you want.
So either the benefit must outweigh the cost or the cost must be reduced to the point where future benefit is sufficient to cost. Seems obvious, eh? But the idea does suggest that usability is about perceived usefulness as well as usable-ness.
about "what's in it for me - NOW" not just "what can i do with it"
This might also be seen as where affect meets effect. This again is not new in the design community: Dillon's proposed model for assessing applications, Process, Outcome, Affect, formalizes the role of affect - how the user feels about their experience in using a system: do they feel empowered. Ethnography has also always looked at what is the cultural context of the planned artefacts to be developed?
One thing that may be new, however, about using "what's in it for me" as a design query, is that it asks the question of affect before the system is developed - but i won't claim that for certain. What i will suggest is that putting design issues in terms of "what's in it for me" is an easy way to translate the iimportance of effective/affective design to non-hci specialists (ie, software engineers).
If your software cannot pass the test of what's in it for me? of the perceived cost being balanced by the perceived benefit, then it's time to rethink the design.
i was at a talk lately where an interesting tool was presented that all the people in the audience said "wow that looks really complicated to try to set up" - and these were rocket scientist type people. The challenge to the presenter was "would it perhaps not have been better to talk with your stakeholders about how they already do what they do and then design the tool to support that, rather than what seems to be the other way around: designing a tool and asking the community to adapt to it?"
The response was a gob-smacker: that if we had designed for one community, then we would have a custom tool not a general tool.
Perhaps having a tool that was useful and useable by one community would provide a path to a tool that was more generally useable - rather than a tool which now is general but that puts the fear of god into anyone who goes near it - where the what's in it for me - the perceived benefit - is (a) unknown and (b) not even approached because the perceived cost is far too obvious.
So, take away: start with finding a me to whom you can ask "what is in it for me" - and test the answers against the push back of cost. it'll likely end up being pro bono, too.
Posted by mc at November 9, 2005 02:56 PM