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

Minimal commitment UX design

Expand Messages
  • Brian Marick
    I d be interested in hearing people who ve built user experiences in a never do today what you can put off until tomorrow style. The idea is that you make
    Message 1 of 33 , Sep 26, 2005
    • 0 Attachment
      I'd be interested in hearing people who've built user experiences in a
      "never do today what you can put off until tomorrow" style. The idea
      is that you make your commitments to user experience as late as
      possible and as tentatively as possible.

      Some characteristics of such a style might be:

      1. Early in the development of the system, most programming is driven
      by business rules described in a tabular style and used as tests.
      (For example, rules about preferred customer discounts would be
      given independently of how orders are placed.) Stories are done
      when the tests pass.

      I think of these rules as a palette of "facts about the world"
      that have to be accommodated by the user experience.

      2. People are also working on characterizing sequences of interactions
      that make sense. (Would these be sea-level use cases or lower? The
      way I characterize them is to tell the product owner to pretend
      she's telling an expert user how to accomplish some task over the
      telephone. She'd say things like "login, then go to the accounts
      page for your user, then bring up the summary detail screen,
      then...")

      The main goal here is to discover the logical "places" or
      interaction contexts in the system.

      These sequences can be turned into tests like those shown in the
      bottom figure here:
      <http://www.testing.com/cgi-bin/blog/2005/03/17#presenter1>

      My hunch is that most people would find it hard to think about
      such sequences without crude, wire-frame style sketches. Those
      sketches would get embodied in the code as a way to let people
      navigate through the system, getting the insight that (I suspect)
      only comes from hands-on use.

      But the implementations are intentionally very provisional, very
      crude, and they are expected to change a lot. All that matters is
      that a user can get from place to place and access the business
      logic. (Keeping the UI maximally flexible is a programming
      challenge.)

      3. As more user navigation stories get written and implemented, the
      business model in the code solidifies faster than the UI. The UI
      remains in flux - capabilities jump from one interaction context to
      another, the connections between interaction contexts change, etc.

      4. Particular interaction contexts stabilize faster than others. As
      they do, they get tests written about their details. ("Control X
      is visible only when...")

      5. Global rules of interaction are sometimes generalized from the most
      stable pages. (I would also hope there'd be the UI equivalent of
      emergent design here - see
      <http://www.testing.com/cgi-bin/blog/2004/08/11#advancers> for a
      code example.)

      But that's all speculation - what have people actually done?

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