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

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

Expand Messages
  • Brian Marick
    ... 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_,
    Message 1 of 33 , Oct 2, 2005
    • 0 Attachment
      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
      wary.

      -----
      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
    • Brian Marick
      ... See, that s the issue. I recently had a client who was converting an old, old system from one type of database to another. It was hell. But it would wrong
      Message 33 of 33 , Oct 2, 2005
      • 0 Attachment
        On Oct 1, 2005, at 9:28 AM, Joshua Seiden wrote:
        >
        >> 2) How could the system have been built such that the decision to
        >> switch could have been made later - still with reasonable cost?
        >
        > Don't know. I'm not in the construction business ;-)

        See, that's the issue. I recently had a client who was converting an
        old, old system from one type of database to another. It was hell. But
        it would wrong to conclude that's an unavoidable fact about systems
        that use databases. It's just a consequence of the way they originally
        decided to do it. We could go back in time and say to them, "What
        you're about to do is a *bad* idea. Do this instead. It's only a
        trivially different amount of work, it won't affect anything users see,
        but you'll be happy you did if you ever switch databases."

        So your data point isn't suggestive unless we could expose the design
        to an expert and have that person say either what my database person
        would have said or "I cannot see any way to build a system that would
        support UX 1 and also easily be switched to UX 2."

        If we're to understand what we have to get right up front and what can
        be deferred, we need to look in some detail at both successes and
        failures.


        >> 3) How can the system be built such that *not* switching doesn't
        >> result in a lot of work with no payoff?
        >
        > I'm not sure I understand this question. Can you clarify what you're
        > asking?

        Suppose there's a way of building a system such that it both supports
        UX 1 today and would make it easy to switch to UX 2 tomorrow. That way
        makes the system 50% more expensive to build today. If the switch is
        never made, that's a lot of money spent with no return. We need a way
        where additional up-front cost is low.

        -----
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.