Hi Bojhan Your story sounds very familiar - I work on an agile open source development project in the scientific software world. To respond to William's point, designing a phone interface that needs minimal training is a realistic goal, designing collaborative imaging management and analysis software for molecular cell biologists that needs minimal training is impossible. Sometimes users are simply engaged in using software to achieve highly complex goals, it's the activity not the software itself that demands 'learning curve software'. And of course in the agile OSS world the idea of a user being a tester is normal - it's the business model; release and get the users to work out the bugs.
For us usability testing isn't just about 'finding the bugs' - it's a vital part of our design and user research. The analogy is with those traditional academic psychology papers that spend several pages going through the usually hugely inconclusive formal experiment details and then end with the usually really fascinating 'however anecdotal observations during the experiment suggest that...' paragraph. Usability sessions of any kind are first and foremost 'an encounter with users' and we treat them as user research opportunities in the widest sense. We do in fact use training sessions as informal usability observations and ethnographic fieldwork opportunities (partly because like in a lot of agile OSS projects there is no money for training consultants so the 'usability guys' do it). Whether on a group or one to one basis we treat them as an opportunity to gain valuable feedback. Depending on the session and people involved we will audio record , video and/or note take, write these up, take to the next developer meeting and use to generate tickets (requirements) for the dev team. Handled in the right way there is no need to interfere with the training element. Most of our users are only too happy to know that we are interested in their observations/thoughts and that their contribution will be fed into future releases. Even simply spending 10 minutes at the end over coffee having a chat with the users will usually yield something useful. Won't work in every situation but in highly complex domains and where the project is agile/OSS/has no money it can be a cheap and cheerful way to wring value out of every user encounter. And whilst educating devs is vital (though many of the devs I have met have great design instinct and user sensitivity) - they simply don't have the time to be gathering user and design insight, that's our job. As distribution of labour schemes go it works pretty well! Catriona Macaulay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=34208 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
