Loading ...
Sorry, an error occurred while loading the content.

RE: [agile-usability] Rapid Contextual Design?

Expand Messages
  • Hugh Beyer
    _____ From: Desilets, Alain [mailto:alain.desilets@nrc-cnrc.gc.ca] Sent: Tuesday, January 11, 2005 8:50 AM To: agile-usability@yahoogroups.com Subject: RE:
    Message 1 of 7 , Jan 21, 2005
    • 0 Attachment
       


      From: Desilets, Alain [mailto:alain.desilets@...]
      Sent: Tuesday, January 11, 2005 8:50 AM
      To: 'agile-usability@yahoogroups.com'
      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
       
    • Jeff Patton
      ... team ... turned into ... I saw Lisa & Dave speak at LanDesk last week and wrote down something Lisa said: I find the prototype to be a good discussion
      Message 2 of 7 , Jan 27, 2005
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
        wrote:

        > Yes, do this. We're now doing this with an XP team in another
        > company--multiple paper prototype iteractions done by the customer
        team
        > during an iteration; then the findings from those iterations are
        turned 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
        Lisa said:

        "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-
        step.

        -Jeff
      Your message has been successfully submitted and would be delivered to recipients shortly.