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

Craftmanship doesn't scale... hence usability?

Expand Messages
  • jeff_grover
    There s an interesting history of usability on the redhat magazine site about how artisans gave way to mass production and usability:
    Message 1 of 3 , Jan 18, 2005
    • 0 Attachment
      There's an interesting "history" of usability on the redhat magazine
      site about how artisans gave way to mass production and usability:

      http://www.redhat.com/magazine/002dec04/features/usability/#principles

      I'm an agile developer, with interests in usability... and this
      article jives very well with my personal happiness scale.

      I had a job with a small company a few years back where the CEO and I
      just found out what needed to be done and built software to solve his
      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.

      This "everything I needed to know about usability I learned in
      small-company IT" attitude has served me well through the years.

      I guess consumers have to choose whether they want the Orange County
      Chopper or just a Honda. I only know the assembly line's not for me.
    • Jeff Patton
      ... compares ... 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
      Message 2 of 3 , Jan 27, 2005
      • 0 Attachment
        --- 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
      • Jade Ohlhauser
        Now that s interesting. We re entering a testing phase for our latest version and I m going to try that. Our software isn t as project focused as your great
        Message 3 of 3 , Feb 28, 2005
        • 0 Attachment
          Now that's interesting. We're entering a testing phase for our latest version and I'm going to try that. Our software isn't as "project' focused as your great software is, but I'm sure we can figure out something in the same spirit.
           
          Thanks,
           
          Jade Ohlhauser
          Product Manager
          RPM Software                          
          www.rpmsoftware.com 403-265-6727
           


          From: Alexandra Zwicker [mailto:aZwicker@...]
          Sent: Friday, February 25, 2005 9: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 

          -----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








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