Hi William Thanks for a thoughtful response. Let me pick up a few threads...
On 12 Oct 2008, at 12:39, William Brall wrote:
I have my own issues with agile, which I'm going to avoid getting into.
I think anyone who has ever worked in any capacity on an agile project has their issues with agile (include the gang of devs I work with) - but that's the environment we are working in.
I find it interesting that you claim your projects for scientists can't be well designed just because of the nature of the product, on that I disagree.
OK so I didn't make myself clear as I certainly did not mean to infer (let alone claim) that! What I am trying to say is that the goal of software that someone should be able to 'make sense' of with no training within their own domain regardless of how complex that domain is, or what the particular software goal is, is a very high one. There is nothing inherently wrong with designing a tool that requires training, practice and commitment from its users. The piano is a great example of just such a tool. No one would claim the piano was designed to be played without instruction and considerable practice. That doesn't make it a bad tool, just a complex tool for a complex job that has proven to be remarkably persistent - as Ivan Illich says, it's a very convival tool (if you have been trained!). There is something inherently wrong with designing a phone that requires that. It's all about the context. I am not claiming our project can't be well designed because of the nature of the project - I am proposing that the idea that a product or system is badly designed if users need training to use it is not always appropriate.
No software is going to be instantly understandable, which seems to be many people's goals. I hear it all the time at work, people create a comp and because they and the technosavy people around them say they get it, they deem it instantly understandable.
Absolutely agree - the case of Lucy Suchman and the photocopier green button is the great example of this. The myth around the 'birth' of design ethnography is that Suchman observed people wanted to make single copies of documents and then Xerox invented the green button (that story gets repeatedly endlessly much to her dismay). Her own version is that they already had the green button and she was intrigued by the company's desire to try and mask the complexity of their copiers.
I also find it interesting that you say you are mostly informed by users as to what is an issue with your product.
Nope didn't say that - what I did say is that we do a lot of user insight gathering, usability testing etc. That informs our project thinking, but that is just one amongst many activities the project teams engage in. Balancing user insight from 'what they tell us' and a great deal of field observation too (as you point out later listening to users only gets you so far!) with dev insight, market insight, expert analysis, etc. is what mostly informs us (and quite a lot of developer instinct alongside it).
They need to learn their own terminology and their own trade, but that should be the only requirement to be able to learn how to use the software.
The problem is that in the environment we are working there is something of a paradigm shift occurring - old models of scientific work are in the early stages of a a new paradign of 'collaborative open source science' - and like most big shifts in science it is bringing with new ways of working - the trade and the terminology is in flux.
If it were broken down into modes that meet the scientists mental models of the process, if they were presented in a clear and straight-forward way, and if any manipulation was done in a way that makes sense for the scientist, I think you could have easy to use software.
Nicely put and that's our goal - with the caveat that my point above raises; some of this is so new in science their is no pre-existing mental model. We need to help them acquire a new one, and part of that is something the software itself will contribute too (though we are not so foolsih as to think that will be the only part of that complex process - standards, science institutions, education systems, hardware firms are all part of that).
I designed software for NASA, I know how complicated some of these processes can be, it is just a matter of breaking them down.
It would be great if you had some case studies of this stuff you could share (though I guess working for NASA would have come with a hefty raft of NDAs)... Breaking down some of the processes we are dealing with has proven to be a very 'dirty problem'.
I know it seems like the right thing to do to talk to the users about what they want, but software companies have been doing this forever and still release crap software. You need to pass the right info through the right filter.
And once again no argument here from me. As an ethnographer I am as suspicious of 'talking with users' as the devs I work with are of agile methods :)
(I can't believe I got through that without busting on agile)
Congratulations :) Such a tempting target but a little like shooting ducks in a barrel !
________________________________________________________________ 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
