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
  • Ron Jeffries
    ... I didn t say or suggest that we should withhold information. I m in favor of sharing all the information we have and I m suggesting that real users will
    Message 1 of 33 , Oct 1, 2005
    • 0 Attachment
      On Saturday, October 1, 2005, at 10:28:23 AM, Joshua Seiden wrote:

      > An answer is: yes. I've seen it done, quite frequently. Contrary to
      > pessimistic notions one might hold about "mere users", they're quite capable
      > of understanding that there is more going on than the GUI, and they're quite
      > capable of understanding the value of a rough interface that lets them see
      > things.

      > They're even quite capable of expressing requirements in forms that lead to
      > acceptance tests.

      > Some of them are almost as smart as we are ... just about different stuff.

      > ---------------

      > Josh replies:

      > This is one of the ideas that user-centered design has investigated with
      > some subtly. Contrary to Ron's implication, withholding incomplete work does
      > not inherently infantilize users. Instead, it is simply a choice of
      > communication tactic.

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

      I didn't say or suggest that we should withhold information. I'm in
      favor of sharing all the information we have and I'm suggesting that
      real users will not be confused by seeing rough interfaces, and will
      not be confused by hearing there's more to the program than the
      glass on the front of it.

      Ron Jeffries
      www.XProgramming.com
      Sometimes you just have to stop holding on with both hands, both
      feet, and your tail, to get someplace better. Of course you might
      plummet to the earth and die, but probably not:
      You were made for this.
    • 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.