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

The simplest thing that could possibly be re-invented?

Expand Messages
  • jeff.grover@att.net
    Maybe I ve just been at this too long, but it seems to me that it s all been done before . Working for a large software company which produces shrinkwrap
    Message 1 of 10 , Oct 8, 2004

      Maybe I've just been at this too long, but it seems to me that "it's all been done before".  Working for a large software company which produces "shrinkwrap" product software, 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>"

       

      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.  In my experience, however, this is absolutely not the case.  It may be the "simplest way to *design* a UI" (least work.. hey, look... a working prototype!), but it yeilds a result that to the user is at best slightly better than the similar work, and at worst... a completely inappropriate tack-on to the user's "task flow" within the new system.

       

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

       

      This of course, assumes that you agree with my premise that value exists in thinking "outside the box" of existing UI that serves similar (although importantly non-identical) purposes.

       

      Lurker no more,

      Jeff Grover

    • Ron Jeffries
      ... There is value to doing the creative work that you describe. However, it is highly risky, and almost impossible to sell to most organizations. My
      Message 2 of 10 , Oct 10, 2004
        On Friday, October 8, 2004, at 8:45:59 PM, jeff.grover@... wrote:

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

        > This of course, assumes that you agree with my premise that value exists in thinking "outside
        > the box" of existing UI that serves similar (although importantly non-identical) purposes.

        There is value to doing the creative work that you describe. However, it is
        highly risky, and almost impossible to sell to most organizations. My
        subjective impression is that most innovative human factors ideas (most
        innovative ideas in general?) come from outside the conventional
        marketing-driven product development food chain.

        Ron Jeffries
        www.XProgramming.com
        Any errors you find in this are the work of Secret Villains,
        whose mad schemes will soon be revealed. -- Wil McCarthy
      • Phlip
        ... Hence today s Dilbert episode. ===== Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces _______________________________ Do you
        Message 3 of 10 , Oct 10, 2004
          Michael Mahemoff wrote:

          > By now, at least some mareketers should be aware of
          > usability as a
          > potential differentiator.

          Hence today's Dilbert episode.



          =====
          Phlip
          http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



          _______________________________
          Do you Yahoo!?
          Declare Yourself - Register online to vote today!
          http://vote.yahoo.com
        • Petteri Hiisilä
          ... I agree. Those companies have a strategy. If it ain t broken, don t fix it. ... The impacts are often slow and not easy to measure. The single biggest
          Message 4 of 10 , Oct 10, 2004
            > First, it is important to acknowledge not all companies actually want to
            > innovate on design - they may well be more interested in copying
            > features and innovating in other areas, like cheaper development time.

            I agree. Those companies have a strategy. If it ain't broken, don't fix it.

            > By now, at least some mareketers should be aware of usability as a
            > potential differentiator. I'm sure many are aware, but are still
            > concerned about its actual impact.

            The impacts are often slow and not easy to measure.

            The single biggest benefit is substantially higher customer loyalty. If
            you already have a very useful (usable, purposeful, satistying, stable,
            high-quality) product, the competitors are in trouble.

            Everybody knows that customer loyalty is a big deal once you have it,
            but its value is very hard to predict, especially in dollars.

            As Alan Cooper put it: "After all, you can sell dirty water in the
            desert to rave reviews, but the same product elicits a different
            response in an upscale restaurant."

            http://www.cooper.com/newsletters/jan01/the_iteration_trap.htm

            What happens if you start selling the clean water in the desert too?
            What can the competitors do?

            Thus, the opposite applies: those companies whose current products don't
            satisfy customers, leave room for competition. It can be fatal. True,
            people generally accept the new, better products slowly, but once they
            have made the move, they usually don't turn back to the old vendor.

            - More satistying products have (almost?) killed Novell and Borland.
            - WordStar was replaced by WordPerfect.
            - WordPerfect was replaced by Word.
            - Word will be replaced by ??? (not OpenOffice, it's essentially an open
            source Word clone)

            It's not easy to design satisfying user interfaces, no more than it's
            easy to create clever technical architecture or efficient code. It
            requires a lot of (often new) thinking and tools. And organizational
            changes!

            Marketers are not able to design usable products with their current
            thinking. They have tools that tell what _sells_. Not what _works_. And
            even when they know what works, they don't know why it works and how to
            make their product work too. They sure know how to clone features, and
            that's what they do!

            Marketing can help when you need to get the product through the
            customers' doors. But once the product is in, that's where desireable
            design, clever engineering and quality programming starts to count.

            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
          • 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 5 of 10 , Oct 10, 2004
              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 6 of 10 , Oct 10, 2004
                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
              • Michael Mahemoff
                ... First, it is important to acknowledge not all companies actually want to innovate on design - they may well be more interested in copying features and
                Message 7 of 10 , Oct 10, 2004
                  >
                  > 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), when someone else has presumably already paid for that
                  > (...or got really lucky and got it right the first time)? 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)?
                  >

                  First, it is important to acknowledge not all companies actually want to
                  innovate on design - they may well be more interested in copying
                  features and innovating in other areas, like cheaper development time.
                  In that case, usability work is more about prototyping and early testing
                  than brainstorming and exploring ideas. If management and marketing
                  genuinely do want to differentiate their product, then usability can be
                  an effective way to achieve it.

                  By now, at least some mareketers should be aware of usability as a
                  potential differentiator. I'm sure many are aware, but are still
                  concerned about its actual impact. At the end of the day, they need to
                  sell products. One of the complications with usability is that end-users
                  might only see the benefits after some time using the product. Also, the
                  purchasing decision-makers are often separated, and prefer a features
                  matrix to a vague statement about usability. For these reasons, the case
                  must be made that improved usability will increase the product's appeal
                  among purchasers; not just that usability can be improved.

                  How much experience do they have with the user base? It can be an
                  incredibly powerful slap in the face for developers to sit with users
                  and see how they work. The same is likely true for non-technical
                  stakeholders. Arranging it might require some effort and a few tactics.
                • Michael Mahemoff
                  ... Funnily enough, it also does a great job of showing how long some purchasers will take to choose between usability and the bottom line.
                  Message 8 of 10 , Oct 10, 2004
                    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.
                  • 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 9 of 10 , Oct 11, 2004
                      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 10 of 10 , Oct 11, 2004
                        --- 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.