RE: [agile-usability] Rapid Contextual Design?
From: Desilets, Alain [mailto:alain.desilets@...]
Sent: Tuesday, January 11, 2005 8:50 AM
Subject: RE: [agile-usability] Rapid Contextual Design?I have never tried either CD or RCD, but I like what I read about it. I
particularly like the fact that they focus on studying and understanding
workpractices as opposed to "requirements". In other words, you first try to
REALLY, REALLY understand the work that people are currently doing that your
software will have to support or complement or fit with. THEN, and only THEN
do you start thinking about features and requirements.
One of the interesting things about this approach is that it seems more
generative. Once you understand the user's work, you can imagine all kinds
of new innovative ways that S/W could support that work, and then test those
ideas with the users.Yes, absolutely. This is actually the origin of Contextual Inquiry--how do you come up with innovative product concepts? John Whiteside at DEC challenged Karen to answer that question about 15 years ago now. Contextual Inquiry, and eventually Contextual Design, was the answer.Hugh
- Hey, Jeff. Parachuted back in just in time to see this message. Yes, ways of synchronizing with agile methods are covered in this book but it's not the book's main focus--the main focus is to show how CD is (almost always) lightened up in practice to meet the needs of different projects.Hugh (business partner with the book's first author)
From: Jeff Patton [mailto:jpatton@...]
Sent: Monday, January 10, 2005 4:02 PM
Subject: [agile-usability] Rapid Contextual Design?
The UCD people on the list might have heard of Holtzblatt & Wood's
new Rapid Contextual Design. Can anyone comment on it?
Is it just fast? Or can we look at it as an agilization of
Contextual Design - by that I mean it deals with strategies for
incremental release and iterative development specifically.
- --- In firstname.lastname@example.org, "Hugh Beyer" <beyer@i...>
> Yes, do this. We're now doing this with an XP team in anotherteam
> company--multiple paper prototype iteractions done by the customer
> during an iteration; then the findings from those iterations areturned into
> user stories in time to feed the next iteration. Works a treat.I saw Lisa & Dave speak at LanDesk last week and wrote down something
"I find the prototype to be a good discussion point. If I don't have
it the discussion takes a lot longer."
Two things struck me - the importance of prototyping - and the
importance of conversation/communication.
I've seen this play out recently as well. We thrash a lot longer
over details when we don't have a prototype - a picture - to talk
over. The resulting software doesn't always end up looking exactly
like the prototype, but we spend a lot less time thrashing if we all
see the same things in our head first. For us UI prototyping is
becoming a critical step - or rather has become expensive to side-