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

RE: [agile-usability] The simplest thing that could possibly be re-invented?

Expand Messages
  • Joshua Seiden
    Jeff Grover wrote: ... a great deal of the usability input we get whether evolutionary or revolutionary originates from or is relative to products
    Message 1 of 10 , Oct 11, 2004
    • 0 Attachment
      Jeff Grover wrote:

      ... a great deal of the usability input we get whether
      "evolutionary" or "revolutionary" originates from or is
      relative to products competing with ours or performing
      similar functions in some other market space. Here are
      some examples:

      "We need a <Fill in your favorite object here> editor
      that looks like <our competition>"
      "Make the browsing feel like the Windows Explorer".
      "Make the web page look like My Yahoo!, Amazon,...
      <fill in your favorite site here>"


      And:

      How can I more eloquently describe this to people
      driven by "industry standards", "competetive analysis",
      "code reuse", and "feature envy"? And, more
      importantly, if I'm trying to be "agile"... how can I
      argue the need for more rigorous user/interaction
      design and testing (feedback)


      -----------

      I find that when designs and solutions are expressed
      relative to another product, it is often the sign of
      sloppy thinking. If someone has thought through a
      problem, there will be less need for comparison--and a
      good chance that he or she will have some drawings,
      documents, specifications--anything--that will express
      that thinking more completely.

      Your examples above are solution statements--divorced
      from any particular problem statement. Try seeking the
      problem. (We had a good long thread on this a while
      ago.) Ask a simple question: "Why?" This may reveal a
      lack of thought, or it may yield a very good answer.
      Sometimes, when you encounter a lack of thought, you
      will find at it's core a lack of understanding of the
      problem space. This is where you may have a good
      opportunity to employ a more rigorous cycle of user
      research, interaction design and testing.

      The potential upside is not "innovation" for its own
      sake, but rather a solution that better fits the
      *specific* problem you are trying to solve.

      Thanks,
      JS
    • Jeff Patton
      ... I can only agree with what s been posted so far. If there isn t a financial reason for changing the software, it s going to be a hard sell. I m hearing
      Message 2 of 10 , Oct 11, 2004
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Joshua Seiden"
        <joshseiden@y...> wrote:
        >
        >> Jeff Grover wrote:
        >>
        >> ... a great deal of the usability input we get whether
        >> "evolutionary" or "revolutionary" originates from or is
        >> relative to products competing with ours or performing
        >> similar functions in some other market space.

        > The potential upside is not "innovation" for its own
        > sake, but rather a solution that better fits the
        > *specific* problem you are trying to solve.

        I can only agree with what's been posted so far. If there isn't a
        financial reason for changing the software, it's going to be a hard
        sell.

        I'm hearing that you believe a usability person might come up with
        better solutions than the "us-too" choices you see being made. No
        offense to the usability people and designers on the list - but what
        they're doing isn't so innovative - not usually. It's exactly what
        Josh has said in his post: it's correctly identifying the goals of
        the user and determining the simplest way to address those goals.
        It's just remarkable how often people don't choose to identify the
        goals of the user.

        Ok - it's really not quite that simple. You sorta need to know
        something about that user and the context of use as well. A little
        experience with a few proven approaches doesn't hurt either. But
        knowing just a little about user, goals, and context of use can go a
        long way at disqualifying "us-too" solutions. The idea isn't to
        disqualify them because they're not innovative - but to disqualify
        them because they're inapropriate... inapropriate for the goals of
        the user, their experience level and the context of use.

        Start with identifying goals first. Ask what the user's goals are
        until you get a good answer. Try the "popping the why stack"
        or "poking with the why-stick" technique. If you really know the
        goal of the feature, you often find the simplest appropriate solution
        is also the cheapest to build.

        Finally, consider trying to make a case for low cost usability
        testing. By that I mean recording users actually trying to use the
        software - using software that records the screen and the face of the
        user running it. There are inexpensive tools that could connect to a
        laptop and be set up quickly - say on a routine customer site visit.
        I've heard from several people that replays of people struggling to
        use software have at least as much political value as value in
        identifying usability problems.

        I understand that if designers aren't part of your current
        development approach, it's going to be hard to explain to folks what
        there unknown unknowns are. And, I suspect others might have
        diagnosed part of the issue correctly? Do you currently suffer from
        lack of competition and large market share? Those are terrible
        burdens on usability. ;-)

        Thanks Jeff G. for posting!

        -Jeff
      Your message has been successfully submitted and would be delivered to recipients shortly.