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

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

Expand Messages
  • Petteri Hiisilä
    ... The marketer approach to usability: http://www.econ.au.dk/fag/4141/e2001/dilbert_easy_to_use.gif ... Best, Petteri -- Petteri Hiisilä Palveluarkkitehti /
    Message 1 of 10 , Oct 10, 2004
    • 0 Attachment
      Michael Mahemoff wrote:
      > Phlip wrote:
      > > Michael Mahemoff wrote:
      > >>By now, at least some mareketers should be aware of
      > >>usability as a
      > >>potential differentiator.
      > >
      > >
      > > Hence today's Dilbert episode.
      > >
      > Funnily enough, it also does a great job of showing how long some
      > purchasers will take to choose between usability and the bottom line.

      The marketer approach to usability:

      http://www.econ.au.dk/fag/4141/e2001/dilbert_easy_to_use.gif

      :)

      Best,
      Petteri

      --
      Petteri Hiisilä
      Palveluarkkitehti / Interaction Designer /
      Alma Media Interactive Oy / NWS /
      +358505050123 / petteri.hiisila@...

      "I was told there's a miracle for each day that I try"
      - John Petrucci
    • William Pietri
      ... I think that principle is one people often misunderstand, because they confuse simple with easy . The easy thing to do is often to say, make it just
      Message 2 of 10 , Oct 10, 2004
      • 0 Attachment
        On Fri, 2004-10-08 at 17:45, jeff.grover@... wrote:
        >
        > Intellectually, there is a great temptation to say the "simplest thing
        > that could possibly work" (XP/agile principle) is to do what someone
        > else held in high regard (OS vendor, competing product, open-source
        > project, well-used application) chose to do.

        I think that principle is one people often misunderstand, because they
        confuse "simple" with "easy". The easy thing to do is often to say,
        "make it just like X". But the reason they just point to X rather than
        saying what specifically they want is that X is not simple.

        Figuring out what is really the simplest thing that could possibly work
        often takes a little more thinking, as you have to understand both the
        need and the medium in enough detail so that you can pick out the simple
        solution that addresses the core need.

        > 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), when someone else has presumably already paid for that
        > (...or got really lucky and got it right the first time)?

        I think of most moves toward agility as tightening feedback loops. The
        best way to get user feedback is to release early and often while
        listening to your users. When you can't do that, user testing can be an
        adequate substitute. Either way, getting frequent user feedback is very
        much in tune with the agile spirit.

        Personally, I think short iterations and frequent releases make it
        easier to innovate, as you get

        * more data -- prototypes are good, but there's nothing better
        than trying the real interface on real people.
        * more design time -- agile methods allow you to overlap the
        design and construction work.
        * less pressure -- when design is no longer a phase, it stops
        being a bottlneck. That means less pressure, making it easier
        to be creative.
        * less risk -- by taking things one step at a time, your bets are
        smaller, which reduces the incentive to chose the safe,
        well-understood solution.
        * better feedback -- because you can find out how you're doing at
        each step, you have a better environment for learning how to
        make good choices.

        > How can I make it more obvious to feature-driven stakeholders that
        > there is inherent value in re-thinking and innovating even though
        > pre-canned answers to tough usability questions seem there for the
        > taking (however false they may be)?

        I think you need to make this argument in financial terms. In essence,
        you're saying that you want them to spend their money differently, so
        you have to show them how that will result in reduced costs, better
        sales, or something else that improves the bottom line.

        William
      • 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 3 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 4 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.