Craftmanship doesn't scale... hence usability?
- There's an interesting "history" of usability on the redhat magazine
site about how artisans gave way to mass production and usability:
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.
- --- In firstname.lastname@example.org, "jeff_grover"
> business problems. Since then, I've experienced varying degrees ofcompares
> "agility/formality" and "usability/lack thereof"... but none
> to interacting daily and one-on-one with the people for whom you areI read the article ref you attached /finally/ and like it alot.
> building the software.
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
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
Thanks for posting Jeff!
- 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 OhlhauserProduct ManagerRPM Softwarewww.rpmsoftware.com 403-265-6727
From: Alexandra Zwicker [mailto:aZwicker@...]
Sent: Friday, February 25, 2005 9:07 AM
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
From: Desilets, Alain [mailto:alain.desilets@...]
Sent: Friday, February 25, 2005 10:01 AM
Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence usability?
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
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
(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
(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
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@...]
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: 'email@example.com'
> Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence
> I reviewed a workshop proposal for XP Agile 2004 (I forget who it was
> 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
> put developpers in the shoes of users so that they can take better
> design decisions. Something like this might just turn developpers into
> 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
> 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