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

Re: [agile-usability] The user is always right

Expand Messages
  • Ron Jeffries
    Hello, Nick. On Sunday, September 14, 2008, at 3:18:03 PM, you ... Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Inigo Montoya: You are
    Message 1 of 28 , Sep 14 2:01 PM
    • 0 Attachment
      Hello, Nick. On Sunday, September 14, 2008, at 3:18:03 PM, you
      wrote:

      > Now you're just being fluffy!

      > Sigh. Oh all right then, fair point. But it just doesn't help to have
      > to tiptoe around it.



      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Inigo Montoya: You are wonderful!
      Man in Black: Thank you. I have worked hard to become so.
    • George Dinwiddie
      ... Don t forget that the very same Henry Ford said, They can have any color they want so long as it is black. - George -- ... * George Dinwiddie *
      Message 2 of 28 , Sep 14 7:12 PM
      • 0 Attachment
        Dan Harrelson wrote:
        > Users can rarely tell you accurately what they want from a product. They
        > don't know the possibilities and limitations. They have a hard time even
        > expressing their frustrations in ways that you can act upon. The now
        > trite anecdote is Henry Ford stating that had he asked what people
        > wanted, they would have said a faster horse, not the automobile.

        Don't forget that the very same Henry Ford said, "They can have any
        color they want so long as it is black."

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Dan Harrelson
        Yeah, I personally think that both quotes demonstrate that Ford was not user-centered. ...Dan
        Message 3 of 28 , Sep 14 7:19 PM
        • 0 Attachment
          Yeah, I personally think that both quotes demonstrate that Ford was
          not user-centered.

          ...Dan

          On Sep 14, 2008, at 7:12 PM, George Dinwiddie wrote:
          >
          > Don't forget that the very same Henry Ford said, "They can have any
          > color they want so long as it is black."
          >
          > - George
        • James Page
          So the user did not want cheap cars? I think the point is that Ford knew that the user primary goal was. They wanted a fast means of communication, and didn t
          Message 4 of 28 , Sep 14 9:53 PM
          • 0 Attachment
            So the user did not want cheap cars? I think the point is that Ford knew that the user primary goal was. They wanted a fast means of communication, and didn't mind that the colour was black. 
             
            Yeah, I personally think that both quotes demonstrate that Ford was 
            not user-centered

             

            On Mon, Sep 15, 2008 at 3:19 AM, Dan Harrelson <danh@...> wrote:

            Yeah, I personally think that both quotes demonstrate that Ford was
            not user-centered.

            ...Dan



            On Sep 14, 2008, at 7:12 PM, George Dinwiddie wrote:
            >
            > Don't forget that the very same Henry Ford said, "They can have any
            > color they want so long as it is black."
            >
            > - George


          • Jon Kern
            even talking to Ron may not matter to the car makers... as a product development business, you pick and choose what to build from all of the conversations.
            Message 5 of 28 , Sep 15 5:43 AM
            • 0 Attachment
              even talking to "Ron" may not matter to the car makers... as a "product
              development" business, you pick and choose what to build from all of the
              conversations. you can't always please everybody :-)

              i had plenty of well-thought out feature requests that I simply would
              add to the issue tracker so i could record my rejection of said feature
              as being too "narrow" or having poor ROI -- recorded for "corporate memory."

              jon


              blog: TechnicalDebt.com <http://technicaldebt.com>
              View Jon Kern's profile <http://www.linkedin.com/in/jonkern>


              Nick Gassman said the following on 9/14/08 3:15 PM:
              >
              > On Sun, 14 Sep 2008 13:42:47 -0400, Ron wrote:
              >
              > >Yes. Experts don't know what I want. All the auto manufacturers have
              > >experts. Very few of them manage to build a car that I want.
              > >
              > >[William]
              > >> I think the solution to that isn't more or better experts. It's
              > more and
              > >> better collaboration. And more and better opportunities for all
              > involved
              > >> to learn how what they think will work differs from what ends up
              > working.
              > >
              > Hmm. It doesn't seem like more collaboration on the part of the car
              > makers would help Ron. More talking to Ron as the user would help.
              >
              > * Nick Gassman - Usability and Standards Manager - http://ba.com *
              >
              >
            • Jon Kern
              if you really think a feature is boneheaded and narrow, sometimes you can have the boss of that business person to ask How does that feature improve our
              Message 6 of 28 , Sep 15 5:46 AM
              • 0 Attachment
                if you really think a feature is boneheaded and narrow, sometimes you
                can have the "boss" of that business person to ask "How does that
                feature improve our business?"

                jon


                blog: TechnicalDebt.com <http://technicaldebt.com>
                View Jon Kern's profile <http://www.linkedin.com/in/jonkern>


                Nick Gassman said the following on 9/14/08 3:18 PM:
                >
                > On Sun, 14 Sep 2008 13:41:09 -0400, Ron wrote:
                >
                > >> Agreed. What becomes frustrating is when someone in the business
                > >> believes they know what the right answer is to their business need,
                > >> and objects to being asked 'why do you want that feature?'.
                > >
                > >
                > >I'll bet fewer would object to questions like
                > >
                > >
                > >Could you tell me more about that feature and how it fits in to
                > >what we're doing?
                > >
                > >
                > >What does that feature give you?
                > >
                > >
                > >How is that being done now?
                >
                > Now you're just being fluffy!
                >
                > Sigh. Oh all right then, fair point. But it just doesn't help to have
                > to tiptoe around it.
                >
                > * Nick Gassman - Usability and Standards Manager - http://ba.com *
                >
                >
              • Robert Biddle
                So a few comments from me on this thread. Firstly, I would like to point out the difference between and end-user and an XP customer (or Scrum PO). They might
                Message 7 of 28 , Sep 16 5:19 AM
                • 0 Attachment
                  So a few comments from me on this thread.

                  Firstly, I would like to point out the difference between and end-user
                  and an XP customer (or Scrum PO). They might in some cases be the
                  same, but in many they are very different. It certainly makes sense
                  for a Customer to consider and work with end users, but they do not
                  always want the same thing, even when they are partially aligned.


                  Secondly, I want to highlight the issue of design. Agile processes do
                  not say much about design. Much of this thread has related to better
                  understanding of the needs of the end user, and also the customer, and
                  I do agree these are important. But they don't say much at all
                  relating to how the needs might or should be met. Agile processes are
                  not alone here: this is also true in User-Centred Design. Moreover, I
                  don't even think this is necessarily a bad thing. I don't think agile
                  processes or UCD need to suggest an approach to design: I think it's
                  fine for them to leave that out. But I still think that it is an
                  important element that will come from somewhere, and I think we should
                  acknowledge it more, lest people assume it does not exist.
                  Moreover, there could be many many approaches to design, and many
                  might succeed. There does not have to be a single best answer. And it
                  might change over time.

                  Lastly, I think we should be very cautious about the nature of user
                  and business "problems" and our desire to provide "solutions".
                  Several people have mentioned the story of Henry Ford suggesting that,
                  if asked, people would have said they wanted better horses, rather
                  than cars. The story seems to carry weight because it is accepted that
                  cars were and are better than horses. It's not really clear to me that is
                  true. And I'm not arguing for or against cars, or for or against
                  horses. But it was not a case of a problem and a solution. It was a
                  case of how the world played out. For a while, anyway.

                  Paul Dourish (UC Irvine) has been talking about this lately. In
                  particularly, he has been urging caution in seeing ethnography as a
                  means to design. He is addressing UI design, but this is important
                  in agile processes more generally as well. See:

                  www.ics.uci.edu/~jpd/classes/readings/Dourish-Implications.pdf

                  Cheers
                  Robt


                  spbroi@... wrote:
                  >
                  > There appears to be a recurring theme in this list. To most questions
                  > asked, at least on reply will be some variation of “what does the user
                  > want?”
                  >
                  >
                  >
                  > It got me to thinking about whether the user has or should have such
                  > absolute power over what we create and deploy.
                  >
                  >
                  >
                  > Forty years ago there was no input from the users except to identify
                  > what they wanted on reports. Formatting was up to us as programmers,
                  > and input definitions (on punch cards) was also up to us. Users
                  > certainly didn’t specify how they’d like their punch cards to look.
                  >
                  >
                  >
                  > When the users were introduced to monitors, they still didn’t have
                  > much to say about the appearance. It was green-gray scroll mode only.
                  > Ask a question, input an answer.
                  >
                  >
                  >
                  > From the mid-70s on, or about the time we started doing prototyping on
                  > minicomputers and the like, the users held sway. Even if the
                  > interface didn’t appear logical to us, if the users said they wanted
                  > it a certain way, they got it. Of course, we didn’t have much in the
                  > way of user interface to play with: fixed input or display screens of
                  > black and white separated by menus. However, the final and ultimate
                  > word was always that of the user who would be staring at that screen
                  > day in and day out.
                  >
                  >
                  >
                  > Nowadays, of course, it’s all different. The user, however, still
                  > appears to control the interface. This leads me to wonder whether the
                  > user experience analysts and experts, the information architects and
                  > the human factors analysts should control the interface instead.
                  >
                  >
                  >
                  > Is there a line between a user’s power to dictate his/her own
                  > interface and the knowledge and skill that a specialist has to make
                  > the interface more efficient and the users of that interface more
                  > productive? Where is that line drawn?
                  >
                  >
                  >
                  > Who draws the line when two (or more) users agitate for different
                  > interfaces to perform the same activity? It could be a simple color
                  > difference or a different way of viewing the flow of entry. Certainly
                  > code could be written to accommodate all users’ peccadilloes. Where
                  > then is the line between the extra code written and subsequent cost of
                  > maintenance to accommodate all the users? Does one user get
                  > preference over others? Majority wins? All users are created equal,
                  > just some users are more equal?
                  >
                  >
                  >
                  > Finally, and it’s a shame to bring this up but that is the reality of
                  > business today, there is the misalignment of process and product. A
                  > user, in this case perhaps one with authority, specifies changes or a
                  > new feature that might benefit him or her personally, or perhaps his
                  > or her department, and it isn’t within the overall corporate strategy.
                  > Since upper level management does not always have checks and balances
                  > in place to coordinate tactical projects and strategic initiatives,
                  > who draws the line when the user’s request isn’t in line with
                  > corporate stragy or mission? I developed a slick system for a Vice
                  > President that did everything he wanted and more, and was delivered on
                  > time and under budget. Before we could even commence the celebratory
                  > party the VP was sacked and the system shelved because it didn’t fit
                  > in with the corporate strategy. We also built a neat system for a
                  > telecom company hitting all the early release dates and preparing for
                  > another five releases to improve the system based on user feedback,
                  > only to have the company sell off the entire system and division to
                  > another company, something that was in the works from before we
                  > started. We were then told the system wasn’t right because the
                  > purchaser didn’t like it.
                  >
                  >
                  >
                  > So where is the line between finding out what the user wants and
                  > delivering something that may be better than what the user requested,
                  > and aligned with the corporate strategy?
                  >
                  >
                  >
                  > Just some random weekend thought
                  >
                  > =Steve
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  > ------------------------------------------------------------------------
                  > Psssst...Have you heard the news? There's a new fashion blog, plus the
                  > latest fall trends and hair styles at StyleList.com
                  > <http://www.stylelist.com/trends?ncid=aolsty00050000000014>.
                  >
                • Ron Jeffries
                  Hello, Robert. On Tuesday, September 16, 2008, at 8:19:42 AM, you ... I very much agree with all this. Nor do I believe there has to be a single best answer
                  Message 8 of 28 , Sep 16 7:53 AM
                  • 0 Attachment
                    Hello, Robert. On Tuesday, September 16, 2008, at 8:19:42 AM, you
                    wrote:

                    > Secondly, I want to highlight the issue of design. Agile processes do
                    > not say much about design. Much of this thread has related to better
                    > understanding of the needs of the end user, and also the customer, and
                    > I do agree these are important. But they don't say much at all
                    > relating to how the needs might or should be met. Agile processes are
                    > not alone here: this is also true in User-Centred Design. Moreover, I
                    > don't even think this is necessarily a bad thing. I don't think agile
                    > processes or UCD need to suggest an approach to design: I think it's
                    > fine for them to leave that out. But I still think that it is an
                    > important element that will come from somewhere, and I think we should
                    > acknowledge it more, lest people assume it does not exist.
                    > Moreover, there could be many many approaches to design, and many
                    > might succeed. There does not have to be a single best answer. And it
                    > might change over time.

                    I very much agree with all this. Nor do I believe there has to be a
                    single best answer for anything. Regarding software development in a
                    sufficiently narrow sense, Agile as I do it is the best I know but I
                    do hope to learn over time. I like to think that I have done so in
                    the past.

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    If you don't push something beyond its boundary of usefulness
                    how do you find where that boundary is? -- Martin Fowler
                  • Kathy Glur
                    ... I ve been lurking for quite a while and this thread has finally compelled me to respond. The product owners and the users frequently ask for functions that
                    Message 9 of 28 , Oct 1, 2008
                    • 0 Attachment
                      > On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:

                      > Agreed. What becomes frustrating is when someone in the business
                      > believes they know what the right answer is to their business
                      > need,and objects to being asked 'why do you want that feature?'.

                      I've been lurking for quite a while and this thread has finally
                      compelled me to respond.

                      The product owners and the users frequently ask for functions that
                      they really don't need. I always ask them what the real issue
                      is...what are they trying to fix with the solution they're
                      proposing. If would I ask them why they wanted it, it would
                      instantly put them on the defensive. By digging into what the
                      problems are, they feel like they're involved in the better solution.

                      Here's an example: We have an ordering feature that we handle
                      through a wizard. If the user leaves the wizard, they lose their
                      progress. (We have an architecture that makes it difficult to save
                      progress.) The business came to us and asked us to allow them to
                      save and leave the wizard. I asked them what operations they needed
                      to perform when they were needing to save the wizard. They listed
                      three things that were much easier to integrate into the wizard than
                      the save function.

                      As usability practitioners, it's our role to listen to what the
                      business wants, observe what the users need (not ask them), and then
                      propose the best design to the stakeholders.
                    • Scott Preece
                      Hi, Kathy, The notion of always trying to understand the why before committing to the how is great. I have a little bit of concern about your example, though.
                      Message 10 of 28 , Oct 1, 2008
                      • 0 Attachment
                        Hi, Kathy,

                        The notion of always trying to understand the why before committing to the how is great. I have a little bit of concern about your example, though. Bending the user experience to make it easier to implement is a dangerous path; you need to be very sure that you're not making the user's job harder or more difficult to understand. It may, of course, be that the specifics of the example didn't have any issues, but it's a situation where you would probably want to test the tasks with users to make sure the new capabilities were clear and didn't make it harder for them to complete the task the wizard supported.

                        Also, you wouldn't want to go down this route if the added capabilities were things you would ever want to do when the wizarded process wasn't going on. That is, if they're things you might want to do at arbitrary times, building them into the wizard would potentially mean you needed to implement all or part of them more than once to make them available in different places.

                        [Obviously, I have no idea of the specifics of your applicatio, so these are general thoughts that may very well not apply here; in any case, figuring out what the customer needs to accomplish is, as you said, central to figuring out the best way to do it.]

                        regards,
                        scott

                        ----- Original Message ----
                        From: Kathy Glur <kaglur@...>
                        To: agile-usability@yahoogroups.com
                        Sent: Wednesday, October 1, 2008 8:33:35 AM
                        Subject: [agile-usability] Re: The user is always right

                        > On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:

                        > Agreed. What becomes frustrating is when someone in the business
                        > believes they know what the right answer is to their business
                        > need,and objects to being asked 'why do you want that feature?'.

                        I've been lurking for quite a while and this thread has finally
                        compelled me to respond.

                        The product owners and the users frequently ask for functions that
                        they really don't need. I always ask them what the real issue
                        is...what are they trying to fix with the solution they're
                        proposing. If would I ask them why they wanted it, it would
                        instantly put them on the defensive. By digging into what the
                        problems are, they feel like they're involved in the better solution.

                        Here's an example: We have an ordering feature that we handle
                        through a wizard. If the user leaves the wizard, they lose their
                        progress. (We have an architecture that makes it difficult to save
                        progress.) The business came to us and asked us to allow them to
                        save and leave the wizard. I asked them what operations they needed
                        to perform when they were needing to save the wizard. They listed
                        three things that were much easier to integrate into the wizard than
                        the save function.

                        As usability practitioners, it's our role to listen to what the
                        business wants, observe what the users need (not ask them), and then
                        propose the best design to the stakeholders.

                      • Kathy Glur
                        Scott, Lots of user observation before the recommendation and after the recommendation confirmed that the items we implemented were the right items. It s a
                        Message 11 of 28 , Oct 2, 2008
                        • 0 Attachment
                          Scott,
                          Lots of user observation before the recommendation and after the
                          recommendation confirmed that the items we implemented were the
                          right items. It's a call center application, so user research is
                          pretty cheap.
                          Kathy

                          --- In agile-usability@yahoogroups.com, Scott Preece <sepreece@...>
                          wrote:
                          >
                          > Hi, Kathy,
                          >
                          > The notion of always trying to understand the why before
                          committing to the how is great. I have a little bit of concern about
                          your example, though. Bending the user experience to make it easier
                          to implement is a dangerous path; you need to be very sure that
                          you're not making the user's job harder or more difficult to
                          understand. It may, of course, be that the specifics of the example
                          didn't have any issues, but it's a situation where you would
                          probably want to test the tasks with users to make sure the new
                          capabilities were clear and didn't make it harder for them to
                          complete the task the wizard supported.
                          >
                          > Also, you wouldn't want to go down this route if the added
                          capabilities were things you would ever want to do when the wizarded
                          process wasn't going on. That is, if they're things you might want
                          to do at arbitrary times, building them into the wizard would
                          potentially mean you needed to implement all or part of them more
                          than once to make them available in different places.
                          >
                          > [Obviously, I have no idea of the specifics of your applicatio, so
                          these are general thoughts that may very well not apply here; in any
                          case, figuring out what the customer needs to accomplish is, as you
                          said, central to figuring out the best way to do it.]
                          >
                          > regards,
                          > scott
                          >
                          >
                          >
                          > ----- Original Message ----
                          > From: Kathy Glur <kaglur@...>
                          > To: agile-usability@yahoogroups.com
                          > Sent: Wednesday, October 1, 2008 8:33:35 AM
                          > Subject: [agile-usability] Re: The user is always right
                          >
                          >
                          > > On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:
                          >
                          > > Agreed. What becomes frustrating is when someone in the business
                          > > believes they know what the right answer is to their business
                          > > need,and objects to being asked 'why do you want that feature?'.
                          >
                          > I've been lurking for quite a while and this thread has finally
                          > compelled me to respond.
                          >
                          > The product owners and the users frequently ask for functions that
                          > they really don't need. I always ask them what the real issue
                          > is...what are they trying to fix with the solution they're
                          > proposing. If would I ask them why they wanted it, it would
                          > instantly put them on the defensive. By digging into what the
                          > problems are, they feel like they're involved in the better
                          solution.
                          >
                          > Here's an example: We have an ordering feature that we handle
                          > through a wizard. If the user leaves the wizard, they lose their
                          > progress. (We have an architecture that makes it difficult to save
                          > progress.) The business came to us and asked us to allow them to
                          > save and leave the wizard. I asked them what operations they
                          needed
                          > to perform when they were needing to save the wizard. They listed
                          > three things that were much easier to integrate into the wizard
                          than
                          > the save function.
                          >
                          > As usability practitioners, it's our role to listen to what the
                          > business wants, observe what the users need (not ask them), and
                          then
                          > propose the best design to the stakeholders.
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.