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

RE: [agile-usability] Re: Craftmanship doesn't scale... hence usa bility?

Expand Messages
  • Desilets, Alain
    I reviewed a workshop proposal for XP Agile 2004 (I forget who it was from) which was describing a process whereby at the end of each iteration, the whole team
    Message 1 of 7 , Jan 27, 2005
    • 0 Attachment
      I reviewed a workshop proposal for XP Agile 2004 (I forget who it was from)
      which was describing a process whereby at the end of each iteration, the
      whole team "celebrates" by spending half a day playing around with the
      system and eating their own dog food. That struck me as a really good way to
      put developpers in the shoes of users so that they can take better design
      decisions. Something like this might just turn developpers into craftmans.

      Unfortunately, the proposal for the workshop was turned down (I gave it
      thumbs up myself). I would have liked to attend it.

      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada



      -----Original Message-----
      From: Jeff Patton [mailto:jpatton@...]
      Sent: Thursday, January 27, 2005 10:47 AM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Re: Craftmanship doesn't scale... hence
      usability?




      --- In agile-usability@yahoogroups.com, "jeff_grover"
      <jeff.grover@a...> wrote:
      > business problems. Since then, I've experienced varying degrees of
      > "agility/formality" and "usability/lack thereof"... but none
      compares
      > to interacting daily and one-on-one with the people for whom you are
      > building the software.

      I read the article ref you attached /finally/ and like it alot.

      Thinking about it, I think a problem with software design is in fact
      the /absence/ of craftsmanship.

      If I imagine the way a craftsman designs something I'd imagine him
      working closely with the person using the thing, asking them lots of
      questions about what they do, building versions of the thing, and
      watching them use it. I suspect lots of craftsman actually use the
      things they build. [Those west coast chopper guys love to ride
      motorcycles - but I know few software developers who love to play
      with medical billing systems.] Craftsmen have intimate knowledge of
      the people who will use their product.

      That's what UCD and usability people strive for. The absence of that
      intimate knowlede of who's using your product, why and how is, in my
      mind, the craftsmanship that's absent today in much of the software I
      see.

      I believe craftsmanship does scale - if we try. I believe many
      organizations and individual developers have given up trying. It
      frustrates me to hear developers ask "what are the requirements?"
      instead of "what's the person using this software hope to
      accomplish?" The first question is one asked by someone who doesn't
      care to know their user. The second question is the one a craftsman
      would ask.

      Thanks for posting Jeff!

      -Jeff








      Yahoo! Groups Links
    • Desilets, Alain
      -- Alain: I mostly agree. Developpers can t catch ALL usability issues because they know the interface too well. So you still need to test with real users
      Message 2 of 7 , Feb 25, 2005
      • 0 Attachment
        -- Alain:
        I mostly agree.

        Developpers can't catch ALL usability issues because they know the interface
        too well. So you still need to test with real users (that's point (1)). But
        in my experience, developpers CAN intercept MANY important usability issues,
        especially if, as you propose in (2), they do more than "play around" with
        the system and try to carry out realistic tasks (which could be crafted by a
        usability expert).

        The point I was trying to make is that I believe there is a lot of value in
        having the development team as a whole be actively involed in usability
        design and testing. It educates the whole team about usability issues. After
        a while, I bet you would find developpers:

        (a) Truly valuing usability (now wouldn't THAT be nice).

        (b) Independantly finding usability issues that were missed by testing with
        real users (after all, testing can only find issues that show up in the
        specific scenarios that were tried)

        (c) Independantly making good design decisions for minor things (as a
        usability expert, wouldn't you prefer to spend more of your time on the big
        picture instead of whether a list should be a pick list or a series of radio
        buttons?).

        (d) Turning to usability experts for advice on the more difficult issues.

        This may sound threatening to usability experts but it's not. Basically it
        means that their role would move from being the Usability Police to being a
        Usability Coach and Partner.

        This is exactly what has happened with unit testing and design in XP.
        Instead of having a separate Architecture Police or Quality Police, everyone
        is actively involed in design (constant refactoring) and testing (unit
        testing) and loving it. Typically though, you still need at least one person
        on the team who is an expert designer and/or tester and acts as a "gardener"
        and coach for Architecture and Quality. And those people are highly valued.


        -----

        (1) Developers' inside-out knowledge of how the user interface was
        constructed and how it functions handicaps them in actually experiencing the
        user experience.


        (2) "Playing around with" is not using.

        More payoff can be obtained if someone independent creates realistic and
        challenging usage scenarios for the developers to carry out with
        representative volume and complexity ("complete the following 28 new patient
        admissions and correct the following 12 billing errors while intermittently
        interrupting each other"). An application that can feel just fine when you
        are freely exploring it without pressure and with no particular goal in mind
        can turn out to be completely unacceptable under realistic and repetitive
        conditions.

        This sort of trial use is less fun than a "celebration" but more useful in
        gaining insight into user needs. Over time, developers who do this will find
        their design and development practices gradually morph. For example, some
        developers tend to see modal dialogs as the solution to every interaction
        problem. Only when they experience them popping up in their faces at every
        turn and having to launch-act-and-close 28 times in a row do they start
        thinking about within-context alternatives.

        --Larry Constantine, IDSA [mailto:lconstantine@...]
          Chief Scientist
          Constantine & Lockwood, Ltd.
          58 Kathleen Circle | Rowley, MA 01969
          tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


        > -----Original Message-----
        > From: Desilets, Alain [mailto:alain.desilets@...]
        > Sent: Thursday, 27 January 2005 11:45 AM
        > To: 'agile-usability@yahoogroups.com'
        > Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence
        usability?
        >
        >
        > I reviewed a workshop proposal for XP Agile 2004 (I forget who it was
        from)
        > which was describing a process whereby at the end of each iteration,
        > the whole team "celebrates" by spending half a day playing around with
        > the system and eating their own dog food. That struck me as a really
        > good way
        to
        > put developpers in the shoes of users so that they can take better
        > design decisions. Something like this might just turn developpers into
        > craftmans.
        >
        > Unfortunately, the proposal for the workshop was turned down (I gave
        > it thumbs up myself). I would have liked to attend it.
        >
        > Alain Désilets, MASc
        > Agent de recherches/Research Officer
        > Institut de technologie de l'information du CNRC /
        > NRC Institute for Information Technology
        >
        > alain.desilets@...
        > Tél/Tel (613) 990-2813
        > Facsimile/télécopieur: (613) 952-7151
        >
        > Conseil national de recherches Canada, M50, 1200 chemin Montréal,
        > Ottawa (Ontario) K1A 0R6 National Research Council Canada, M50, 1200
        > Montreal Rd., Ottawa, ON K1A 0R6
        >
        > Gouvernement du Canada | Government of Canada





        Yahoo! Groups Links
      • Larry Constantine
        Alain wrote: The point I was trying to make is that I believe there is a lot of value in having the development team as a whole be actively involed in
        Message 3 of 7 , Feb 25, 2005
        • 0 Attachment
          Alain wrote:

          "The point I was trying to make is that I believe there is a lot of value in
          having the development team as a whole be actively involed in usability
          design and testing."

          I couldn't agree more. Usability needs to be everybody's job. I can
          absolutely attest that the long-term benefits you identify are real.

          "(as a usability expert, wouldn't you prefer to spend more of your time on
          the big picture instead of whether a list should be a pick list or a series
          of radio buttons?)....This may sound threatening to usability experts but
          it's not. Basically it means that their role would move from being the
          Usability Police to being a Usability Coach and Partner."

          I don't think many usability experts would be threatened by something that
          makes their jobs easier. Admittedly, there are those who believe that their
          craft is so high-level and sophisticated that "mere" developers could not
          learn it, but I am not one of those. Indeed, I early earned the disfavor of
          some parts of the UI/Ux community for teaching programmers interaction
          design principles and techniques.

          That said, for my part, I see usability as involving interactions between
          the big picture and the myriad miniscule details. I consider it part of my
          job as designer to specify widget choice if it matters, which it often does,
          and that means I have to think about whether it matters in each given
          situation. On the other hand, there is never time to specify everything, and
          if I am working with sophisticated developers who understand the tradeoffs,
          I am a lot more comfortable trusting the details to them.

          Another technique for enhancing developer awareness of and ability to
          contribute to usability is collaborative usability inspections, a formal
          peer review technique. A new article on the subject just appeared
          (http://www.cutter.com/offers/peerreviews.html) and an in-depth treatment is
          also on the Web (http://www.foruse.com/articles/inspections2003.pdf).

          --Larry Constantine, IDSA
          Chief Scientist | Constantine & Lockwood Ltd | www.foruse.com
        • Alexandra Zwicker
          This is a great way to personalize for the team the usability issues that our customers face every day. We often will assign the whole team (developers,
          Message 4 of 7 , Feb 25, 2005
          • 0 Attachment
            This is a great way to personalize for the team the usability issues that our customers face every day.  We often will assign the whole team (developers, documentation, QA, usability people, etc.) a weekly project to do.  The project will focus on a real-world task that our users rely on our software for (and not something small like entering a set of data..that isn't really representative of how users will be using the whole application, is it).  We try to test something that encompasses a larger workflow so we get a more realistic idea of the overall experience.  Our product specialist will obtain real work samples from a customer, and that is what we will work with (instead of us providing our own work samples, which are often set-up for success).  The project is something that people on the team can pick up and work on intermittently, while taking a break from their real work.  At the end of the week, we have a meeting where each person on the team presents their results for the project, and talks about the experience.  It is a great way for all of us to step out of our roles and find out what it's like to use the software from a user's perspective. 
            ---
            Alexandra Zwicker  Alias  Interaction Designer 

            -----Original Message-----
            From: Desilets, Alain [mailto:alain.desilets@...]
            Sent: Friday, February 25, 2005 10:01 AM
            To: 'agile-usability@yahoogroups.com'
            Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence usability?

            -- Alain:
            I mostly agree.

            Developpers can't catch ALL usability issues because they know the interface
            too well. So you still need to test with real users (that's point (1)). But
            in my experience, developpers CAN intercept MANY important usability issues,
            especially if, as you propose in (2), they do more than "play around" with
            the system and try to carry out realistic tasks (which could be crafted by a
            usability expert).

            The point I was trying to make is that I believe there is a lot of value in
            having the development team as a whole be actively involed in usability
            design and testing. It educates the whole team about usability issues. After
            a while, I bet you would find developpers:

            (a) Truly valuing usability (now wouldn't THAT be nice).

            (b) Independantly finding usability issues that were missed by testing with
            real users (after all, testing can only find issues that show up in the
            specific scenarios that were tried)

            (c) Independantly making good design decisions for minor things (as a
            usability expert, wouldn't you prefer to spend more of your time on the big
            picture instead of whether a list should be a pick list or a series of radio
            buttons?).

            (d) Turning to usability experts for advice on the more difficult issues.

            This may sound threatening to usability experts but it's not. Basically it
            means that their role would move from being the Usability Police to being a
            Usability Coach and Partner.

            This is exactly what has happened with unit testing and design in XP.
            Instead of having a separate Architecture Police or Quality Police, everyone
            is actively involed in design (constant refactoring) and testing (unit
            testing) and loving it. Typically though, you still need at least one person
            on the team who is an expert designer and/or tester and acts as a "gardener"
            and coach for Architecture and Quality. And those people are highly valued.


            -----

            (1) Developers' inside-out knowledge of how the user interface was
            constructed and how it functions handicaps them in actually experiencing the
            user experience.


            (2) "Playing around with" is not using.

            More payoff can be obtained if someone independent creates realistic and
            challenging usage scenarios for the developers to carry out with
            representative volume and complexity ("complete the following 28 new patient
            admissions and correct the following 12 billing errors while intermittently
            interrupting each other"). An application that can feel just fine when you
            are freely exploring it without pressure and with no particular goal in mind
            can turn out to be completely unacceptable under realistic and repetitive
            conditions.

            This sort of trial use is less fun than a "celebration" but more useful in
            gaining insight into user needs. Over time, developers who do this will find
            their design and development practices gradually morph. For example, some
            developers tend to see modal dialogs as the solution to every interaction
            problem. Only when they experience them popping up in their faces at every
            turn and having to launch-act-and-close 28 times in a row do they start
            thinking about within-context alternatives.

            --Larry Constantine, IDSA [mailto:lconstantine@...]
              Chief Scientist
              Constantine & Lockwood, Ltd.
              58 Kathleen Circle | Rowley, MA 01969
              tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


            > -----Original Message-----
            > From: Desilets, Alain [mailto:alain.desilets@...]
            > Sent: Thursday, 27 January 2005 11:45 AM
            > To: 'agile-usability@yahoogroups.com'
            > Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence
            usability?
            >
            >
            > I reviewed a workshop proposal for XP Agile 2004 (I forget who it was
            from)
            > which was describing a process whereby at the end of each iteration,
            > the whole team "celebrates" by spending half a day playing around with
            > the system and eating their own dog food. That struck me as a really
            > good way
            to
            > put developpers in the shoes of users so that they can take better
            > design decisions. Something like this might just turn developpers into
            > craftmans.
            >
            > Unfortunately, the proposal for the workshop was turned down (I gave
            > it thumbs up myself). I would have liked to attend it.
            >
            > Alain Désilets, MASc
            > Agent de recherches/Research Officer
            > Institut de technologie de l'information du CNRC /
            > NRC Institute for Information Technology
            >
            > alain.desilets@...
            > Tél/Tel (613) 990-2813
            > Facsimile/télécopieur: (613) 952-7151
            >
            > Conseil national de recherches Canada, M50, 1200 chemin Montréal,
            > Ottawa (Ontario) K1A 0R6 National Research Council Canada, M50, 1200
            > Montreal Rd., Ottawa, ON K1A 0R6
            >
            > Gouvernement du Canada | Government of Canada





            Yahoo! Groups Links







          • Larry Constantine
            Alexandra, That s a GREAT technique that I would like to try. --Larry Constantine, IDSA Chief Scientist | Constantine & Lockwood Ltd | www.foruse.com _____
            Message 5 of 7 , Feb 25, 2005
            • 0 Attachment

              Alexandra,

               

              That’s a GREAT technique that I would like to try.

               

              --Larry Constantine, IDSA

                Chief Scientist | Constantine & Lockwood Ltd | www.foruse.com

               


              From: Alexandra Zwicker [mailto:aZwicker@...]
              Sent: Friday, February 25, 2005 11:07 AM
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence usability?

               

              This is a great way to personalize for the team the usability issues that our customers face every day.  We often will assign the whole team (developers, documentation, QA, usability people, etc.) a weekly project to do.  The project will focus on a real-world task that our users rely on our software for (and not something small like entering a set of data..that isn't really representative of how users will be using the whole application, is it).  We try to test something that encompasses a larger workflow so we get a more realistic idea of the overall experience.  Our product specialist will obtain real work samples from a customer, and that is what we will work with (instead of us providing our own work samples, which are often set-up for success).  The project is something that people on the team can pick up and work on intermittently, while taking a break from their real work.  At the end of the week, we have a meeting where each person on the team presents their results for the project, and talks about the experience.  It is a great way for all of us to step out of our roles and find out what it's like to use the software from a user's perspective. 

              ---
              Alexandra Zwicker 
              Alias  .  Interaction Designer .

            • Thyra Rauch
              I ve got a couple minutes here while waiting for my next flight, so I ll chime in on this one as it s near and dear to my heart. Responding to Alain s
              Message 6 of 7 , Feb 25, 2005
              • 0 Attachment

                I've got a couple minutes here while waiting for my next flight, so I'll chime in on this one as it's near and dear to my heart.  Responding to Alain's comments below:

                < But in my experience, developpers CAN intercept MANY important usability

                issues, especially if, as you propose in (2), they do more than "play around"
                with the system and try to carry out realistic tasks (which could be crafted
                by a usability expert).>

                Absolutely!  Bringing the realistic tasks back from my interactions with customers is one of the critical things I can do.  And my development team is outstanding at intercepting a lot of usability issues as they contructing the product and putting the pieces together.

                < The point I was trying to make is that I believe there is a lot of value in
                having the development team as a whole be actively involed in usability
                design and testing. It educates the whole team about usability issues. After
                a while, I bet you would find developpers:
                (a) Truly valuing usability (now wouldn't THAT be nice).>


                Yes, because it's really not about "usability" the way some folks think about it -- e.g., radio buttons or entry field placement.  It's about the total user experience and trying to bring value and return on investment back to the customer.  If they cannot use your product or do not find it valuable, they will not use it, and we all pay the price for that.

                < (c) Independantly making good design decisions for minor things (as a
                usability expert, wouldn't you prefer to spend more of your time on the big
                picture instead of whether a list should be a pick list or a series of radio
                buttons?).>


                And with my limited time and resource, I'm thrilled to have a whole team of folks being extended eyes and ears so we don't miss things.


                < This may sound threatening to usability experts but it's not. Basically it
                means that their role would move from being the Usability Police to being a
                Usability Coach and Partner.>


                It's not threatening to me in the slightest.  I welcome and embrace the input and involvement of my development team.  In return, I have more time to spend on solution-level integration issues and being a key contact to the customers.  Being a "usability police" has never sat well with me and tends to bring alienation rather than respect.  Understanding all issues including the customer's viewpoint, the needs of the business, and the limitations of the code and schedule, as well as rolling your sleeves up and assisting them when necessary buy a lot more respect.


                trauch@...
                Customer Research Architect
                WebSphere Information Integration and Search
                Phone:  408-463-2465

              • Anita Salem
                This is a great discussion. Thyra said:
                Message 7 of 7 , Feb 25, 2005
                • 0 Attachment
                  This is a great discussion.

                  Thyra said:
                  <Absolutely! Bringing the realistic tasks back from my interactions with
                  customers is one of the critical things I can do. And my development team
                  is outstanding at intercepting a lot of usability issues as they contructing
                  the product and putting the pieces together.>

                  Yes and more. Taking members of the development team with you on customer
                  visits can give them a rich picture that no verbal or written report can
                  ever capture. Seeing customers work not only gives us critical information
                  about work flow, it helps all of us to think more conceptually about how and
                  why users do what they do. I think we're pretty good at capturing tasks and
                  workflow and bringing it back to the team, and I think we can do more.

                  Often I think back on a customer observation and what comes to mind is not
                  necessarily the details of a work process, but how it exemplified a users
                  goal, or the users environment, or a critical stumbling block, or the
                  inter-relationship between business elements. Those "aha" moments are very
                  powerful and can be extremely useful in future usability decisions because
                  they capture both the how AND why's of a process. As Personas tend to do
                  for "user-centered" design, in-context observations are invaluable for
                  capturing the grand picture of "usage" and help place "customer stories" in
                  a richer context.

                  We researchers can then as Alain says, become coaches and partners. Our
                  time is spent structuring, coordinating, and synthesizing the visits. The
                  "report" then becomes a tool for enumerating tasks AND a trigger for
                  remembering all of the rich context that has been observed. A two hour
                  customer visit is worth a thousand words...

                  Anita
                   
                  SalemSystemsInc.
                           customer-driven product development

                          Aptos CA  Seattle  WA
                          (831) 277-6616 (206) 550-3027
                          www.salemsystems.com
                Your message has been successfully submitted and would be delivered to recipients shortly.