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

RE: [agile-usability] Minimal commitment UX design

Expand Messages
  • Joshua Seiden
    ... Well, here s an example about why it s important to consider the navigation framework early: I m currently working on a large supply chain management
    Message 1 of 33 , Oct 1, 2005
    • 0 Attachment
      > What specific things make it unwise to commit later? Examples, please.

      Well, here's an example about why it's important to consider the navigation
      framework early:

      I'm currently working on a large supply chain management application. When
      the first modules of functionality were developed, they were given an MDI
      navigation scheme. (Multiple document interface: every action happens in
      it's own window.) This was identified as a problem, new navigation was
      designed, and all new functionality is deployed within an SDI framework.

      But what to do with the old functionality? It has be made to work within the
      SDI framework we designed. All of the UI for the old modules has to be
      re-written. This extra rewrite is six months of work that would not have to
      be done had the navigation design been considered early on.

      ----------

      A note about process: the project in this example is not agile. Until I
      joined, it did not have a user-centered nature either. So the example is
      drawn from outside the scope of this discussion list, but is instructive
      none-the less.

      I do believe that if we were working within an agile context, the scope of
      the rework would have been considerably smaller. I will claim that working
      in a user-centered agile context, the cost of the rework would have been
      zero--the problem could have easily been identified before a single line of
      code was written.

      So what's the point of the example? Just to illustrate that there are design
      dependencies. Certain classes of decisions need to be made earlier than
      others.

      --------------

      In an earlier post, I wrote:

      >> Finally, the earliest UX decisions blend into product definition and
      >> strategy. What functionality is required? What is the product
      >> emphasis? As an example, in an early case study from Cooper, they talk
      >> about some scanner managment software they worked on for Logitech.
      >> This utility accompanied a low-end sheet-feed style scanner, and was
      >> conceived of as "scanner managment" software. Some user research
      >> revealed that at this price point, no-one wanted to manage and
      >> configure the scanner. Everyone simply wanted to use the scanner to
      >> get images into Word. This insight, followed to it's conclusion,
      >> radically changed the product requirements, the set of funtionality
      >> that was included, and, of course, the nature of the user interface.


      Brian aksed:

      > The interesting questions here are:
      >
      >1) What functionality was common between the two kinds of scanners?

      The scanners were the same. Only the management software changed.

      The internal functionality of the process-centric software was a subset of
      the scanner management software. The scanner management software include
      rich scanner parameter adjustment capability. The Process-centric version
      used 5 presets. The scanner management software allow image rotation in
      1-degree increments within a 360-degree space. The process-centric version
      allowed only 90-degree increments. Etc.

      The process-centric version includes some UI features that the
      scanner-management version did not. Image-cropping used a non-destructive
      method, for example, and was invoked by a UI that was able to visualize this
      (then non-standard) method of cropping.

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

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


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