RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)
"For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?”
-- Larry replied:
Zero. And zero. (Ha, surprised you!)
-- Alain re-replies:
Oh and BTW, you DID surprise me... But I don't know if you really meant to be that extreme or if you were being facetious, because you later said:
This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.
And surely getting the UI architecture requires more than zero hours of work (although I am sure it can be done fairly rapidly).
Oh, I think I see... while developpers are working on the basic infrastructure, the UCD part of the team works out the basic UI architecture, is that right?
That brings up another question. I personally find that when I write the backend infrastructure in complete isolation from the front-end, I almost inevitably end up over-engineering the backend. How do you avoid this trap?
My way of avoiding it is to religiously follow the YAGNI (You Aint Gonna Need It) and BuildTheSimplestThingThatCouldPossiblyWork principles. But that assumes I have a basis for deciding what I am NOT going to need and what the simplest thing that COULD possible work is. And to do that, i need to build the front end at the same time (or at least have some understanding of what the front end is going to actually require from the backend).
Here is a typical example. A few years ago, I started working on a tool that would allow children to collaboratively create hypertext stories on the web. I decided that Ward Cunningham's Wiki was a good starting point. When I looked at the code I was shocked to see that it did not include any file locking mechanism. As a result, if two people try to edit the same page at the same time, the changes of the first person to save will be LOST! I thought this was pure madness and was highly tempted to go ahead and implement file locking. But having just been in XP training, I resisted the urge and worked on other features which I KNEW I needed (ex: translating all dialogs because the kids who were going to use it were French). Well, the bottom line is that Ward was right. For the vast majority of contexts where Wikis are used, file locking is not necessary and in fact it might cause more problem than it's worth (ex: page being left accidentally locked forever). I have installed my lock-less clone on twenty different sites, and concurrent editing has never been a problem.
As to what percent of the total budget goes into visual and interaction design, as you say, “It depends.” It depends on how complicated the UI is, what the objectives and needs of the project are in terms of usability, and how much time/money is allocated. It also depends on the development process model. If the entire UI design is developed completely incrementally, the designer(s) will have to be involved over the whole project, which as a practical matter may prove more expensive than if they had done their work up front and moved on to another assignment. It depends. :-)
My main concern about the U* gury turning into a pumpkin after the start of the project, is that at some point, the design of the UI may have to be changed because of say, time and budget constraints. If the U* guy is not available anymore to make decisions about how to change the design, what happens is that the developpers take matters into their own hands. And that's when UI butchering happens...
When you say that:
"functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs."
Is usability testing included in the word "tested"?
Also, do you find that by seeing the software running with such ad hocs UIs the UCD part of the team learns things that influence their design effort?
Finally, don't you run into situations where the customer thinks that the the adhoc UI is perfecltly fine and wants to ship the product with it (the dreaded throwaway prototype being shipped as a final product situation)?
No, usability testing is intended to find remaining usability problems in the UI as designed, not in a functional mockup or proof-of-concept prototype.
I would not say we never change our design based on running prototypes, but it is not the normal experience, in part because the UI of the POC prototype is, as to be expected, not very good. We are more likely to refine our ideas after genuine usability testing of the final UI.
We try to head off the last problem by carefully managing what and when we show clients. In particular, we avoid as much as possible showing clients early design concepts or prototypes. We want the first look to be pretty much what they will get. You can also manage this problem by making sure that a POC prototype does not look TOO good nor work TOO well. (E.g., leave visual components unaligned, don’t optimize access times, etc. Keep saying, “This is just a prototype, the real system will be much better.”) Think about a bread-boarded prototype in electronics. No one in their right mind would think of shipping that to consumers.
--Larry Constantine, IDSA