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

1638Re: [agile-usability] can agile customers support minimal commitment to UX design? was: Minimal commitment UX design

Expand Messages
  • Brian Marick
    Oct 2, 2005
      On Oct 1, 2005, at 9:28 AM, Joshua Seiden wrote:

      > As a group, "we software people" tend to be good at visualizing complex
      > abstractions in our heads. Some "users" are better at this than others.
      > Those who are good at this often play a bridging role with software
      > teams--becoming super-users and/or agile customers. Those who are not
      > can
      > provide tons of valuable input, but require different types in
      > communication
      > artifacts to support that communication.
      > As always, good communication is based (in part) on speaking a mutual
      > language. So it is of some importance--both to the process and to the
      > product--that we understand the language that our audience speaks. This
      > includes the visual language in which we present our work.

      The first two sentences in the last paragraph strike me as
      contradictory. To explain:

      There's an interesting book by Peter Galison, _Image and Logic_, which
      is about how different subcultures in particle physics cooperated
      toward shared goals. One pairing is theorists and experimentalists. The
      experimentalists were visual - think particle tracks in bubble chambers
      - whereas the theorists were not (mostly).

      Galison's theme throughout the book is that the different subcultures
      interact by constructing a shared language, which he likens to trading
      pidgins or creoles. Neither group "means" the same things by words in
      the language, and the language isn't as rich as each group's "native"
      language, but it suffices for their shared goals.

      For example, Dalitz charts (section 3.8, pp. 318ff). They was a visual
      device that "[brought] previously theoretical categories (such as
      spin-parity relations) to experimenters and [rendered] cloud chamber
      and emulsion work accessible to theorists" (p. 223) This chart allowed
      people to coordinate their work and, importantly, allowed them to
      collaborate in new types of work (shifting from a concentration on
      "golden events" - single pictures of particular collisions - to the
      aggregation of data from many labs).

      So, the contradiction I see is that "understanding the language in
      which our audience speaks" has this kind of flow:

      user speaks
      -----> expert in two domains translates
      makers update system
      update is made visible <---
      user reacts <-----

      Galison has more this kind of flow:

      | user speaks ----> blooming buzzing confusion <---- makers speak
      | user speaks ----> blooming buzzing confusion <---- makers speak
      | user speaks ----> creole develops <---- makers speak
      v user speaks creole <----> makers speak creole

      Which works better? I'm betting on the latter. But part of the reason
      Agile attracts me is that it seems to share my bias toward radical
      egalitarianism. You have widespread distrust of software architects.
      Many dispute the idea of code ownership. Ken Schwaber teaches Scrum
      Masters (Scrum's very rough equivalent of project managers) that one of
      the hardest things about being one is sitting on your hands and
      insisting that the team figure it out. People widely prefer generalists
      to specialists, hoping that a team of N generalists will, on average,
      beat a team of N specialists, even though none of the generalists is as
      good as one of the specialists in her specialty.

      If that's so, it's not surprising that Agilists are skittish of the
      expert interpreting the user to the makers in the way that the British
      social anthropologists interpreted what African tribes were really on
      about to colonial administrators. (Hmm... lots of overtones to that
      analogy that might be offensive. I don't mean to suggest malign motives
      to anyone.)

      Many people are rightly wary that if experts who've studied the user
      and user experience are moved away from the position of translating
      authority, the programmers will fill that vacuum. We'll pretend we're
      doing the second diagram, but we'll really be doing the first one, just
      with less qualified people acting as experts.

      Those of us - maybe it's only me - who think a shared language will
      surprise us with its good results have a responsibility to equally

      Brian Marick, independent consultant
      Mostly on agile methods with a testing slant
      www.exampler.com, www.testing.com/cgi-bin/blog
      Book in progress: www.exampler.com/book
    • Show all 33 messages in this topic