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

[agile-usability] The user is always right

Expand Messages
  • spbroi@aol.com
    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
    Message 1 of 28 , Sep 13, 2008
    • 0 Attachment

      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

       

       

       

       




    • George Dinwiddie
      ... Steve, it sounds as if you re calling for a priesthood of people to provide the right answers. This is an approach that has a long history in
      Message 2 of 28 , Sep 13, 2008
      • 0 Attachment
        spbroi@... wrote:
        > 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.

        Steve, it sounds as if you're calling for a "priesthood" of people to
        provide the right answers. This is an approach that has a long history
        in Information Technology. We've certainly been through this in terms
        of system administration and software development.

        Your questions posit two possible answers: invest the power in the
        unwashed users or in the expert information architects and human factors
        analysts. It seems to me that both of these extremes are wrong.

        It is a good thing that people study what makes software more effective,
        both from the standpoint of producing the application and from the
        standpoint of designing user interfaces. Surely we do not want all of
        our applications designed by amateurs.

        But it is also a good thing that applications be designed to meet the
        actual needs (and sometimes even the ephemeral wants) of real users. As
        soon as you develop a cadre of people who "know" what to do, you run a
        real risk of misreading or ignoring those needs.

        The only approach that seems tenable to me is one in the middle, where
        professionals and users collaborate in some fashion. In some situations
        you can have end users collaborating directly during development. In
        others, you need to deploy to production environments and then be very
        open to any sort of feedback from those end users.

        William Pietri has mentioned on numerous times how his clients
        instrument their applications to see this sort of feedback. I wrote
        yesterday
        (http://blog.gdinwiddie.com/2008/09/12/a-funny-thing-happened-today/)
        about a situation where a company is not only NOT seeking such feedback,
        they're blocking it.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Nick Gassman
        ... interface more efficient and the users of that interface more productive? Where is that line drawn? ... Steve, this doesn t sound to me like an accurate
        Message 3 of 28 , Sep 14, 2008
        • 0 Attachment
          On Sat, 13 Sep 2008 17:18:29 EDT, Steve wrote:

          >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?
          >
          >
          >
          Steve, this doesn't sound to me like an accurate description of what a
          'specialist' should be doing. It also seems to me that you might be
          combining the role of the user, and that of the product owner.

          Whilst often users can describe features and functions that would be
          of use to them, it's not normally the user who decides whether the
          feature is actually built. The product owner would do that based on a
          judgement of business value (or at least, that's what it should be
          based on).

          Users can usually tell you the things that make the use of system
          difficult, but not always. They don't always know that it could be
          easier. Even less often can they say what to do to make it easier, in
          the sense of drawing an alternative design.

          The role of the 'specialist' is not to decide per se what the right
          design is, but to know most of the time the sorts of things that work
          and the sorts of things that don't, so that you can develop an initial
          interface for testing. The role of the specialist then becomes one of
          *discovering* an effective design through various methods of user
          feedback, only some of which will be the user saying what they want.
          Sometimes, the user won't even be aware of a change to the system. A
          small example is in the use of different images when trying to sell
          products. Some images will sell more than others.

          * Nick Gassman - Usability and Standards Manager - http://ba.com *
        • Ron Jeffries
          Hello, Nick. On Sunday, September 14, 2008, at 11:42:28 AM, you ... Yes. It is the perennial whine of the technical expert that no one listens to him and the
          Message 4 of 28 , Sep 14, 2008
          • 0 Attachment
            Hello, Nick. On Sunday, September 14, 2008, at 11:42:28 AM, you
            wrote:

            > Steve, this doesn't sound to me like an accurate description of what a
            > 'specialist' should be doing. It also seems to me that you might be
            > combining the role of the user, and that of the product owner.

            > Whilst often users can describe features and functions that would be
            > of use to them, it's not normally the user who decides whether the
            > feature is actually built. The product owner would do that based on a
            > judgement of business value (or at least, that's what it should be
            > based on).

            > Users can usually tell you the things that make the use of system
            > difficult, but not always. They don't always know that it could be
            > easier. Even less often can they say what to do to make it easier, in
            > the sense of drawing an alternative design.

            > The role of the 'specialist' is not to decide per se what the right
            > design is, but to know most of the time the sorts of things that work
            > and the sorts of things that don't, so that you can develop an initial
            > interface for testing. The role of the specialist then becomes one of
            > *discovering* an effective design through various methods of user
            > feedback, only some of which will be the user saying what they want.
            > Sometimes, the user won't even be aware of a change to the system. A
            > small example is in the use of different images when trying to sell
            > products. Some images will sell more than others.

            Yes. It is the perennial whine of the technical expert that no one
            listens to him and the world would be a much better place if
            everyone did. I'm familiar with this: I've whined that whine many
            times.

            And it damn well might be true. Often we who learn deep things and
            think hard about them are probably quite right.

            However, that doesn't seem to be the way of things. It's still the
            golden rule (him as has the gold makes the rules) and that means
            that if we want our ideas to prevail we pretty much have two
            choices. We can learn to persuade people of the rightness of our
            ideas (probably learning a lot about what they should be in the
            process). Or we can go our own way on our own money and build the
            better mousetrap and see whether they flock to our door.

            In practice, of course, we blend and mix and match. Still and all,
            we only get things done when we stop whining and start playing the
            game.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            To be on the wire is life. The rest is waiting. --Karl Wallenda
          • Jon Kern
            The user is not always right. Neither am I :-0 User s sometimes don t even ask for the right features. When it comes to User Experience designs from users,
            Message 5 of 28 , Sep 14, 2008
            • 0 Attachment
              The user is not always right. Neither am I :-0

              User's sometimes don't even ask for the right features. When it comes to
              User Experience designs from users, these can often be quite horrendous.
              We have to fight through the "crud" and see the true business needs.

              However, working together is always "right."

              <anecdote>
              We are almost in Alpha. I get a call from a manager "Just got an email
              from Marc. The business says we need to have encryption."
              "Oh? Well, we have the entire site done via https and a login. Isn't a
              login via authorized account, and having each page protected like how
              Amazon.com does for credit cards good enough?"
              Then I call the business analyst.
              Long story short: turns out the business needs to have specific fields
              (like social security number) hidden from view. "Do you mean with
              asterisks like we do for password fields?" "Yes." "Ok. Piece of cake to
              handle that. This is not 'encryption.'" "Oh, sorry." "No problem. Just
              try to express business needs in their language and don't try to speak
              my language. We don't need any additional mis-translations." "Ok."
              </anecdote>

              Working with the right folks to elicit the "true" business requirements
              at the right times in the project can improve the chances you will
              produce the right outcome in a timely manner to meet the business' needs.

              jon


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


              spbroi@... said the following on 9/13/08 5:18 PM:
              >
              > 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>.
              >
            • Dan Harrelson
              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
              Message 6 of 28 , Sep 14, 2008
              • 0 Attachment
                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. Take this into a modern context and the Microsoft Office team would hear from users that they want to create compelling documents, not the Ribbon interface.

                User behaviors on the other hand are often dead on. If they don't use a feature or create workarounds or find unexpected uses for your product, you learn about what needs to change. Watching the frustrations that a myriad of toolbars and options in MS Word causes brings about the realization that a simplified "just what you need right now" interface is required. The expert design team takes this input and comes up the the Ribbon.

                As others in this thread have identified, the combination of listening to your users plus expertise in product design results in the best possible solutions.

                ...Dan
              • Jon Kern
                I posted an anecdote that involves food jon blog: TechnicalDebt.com View
                Message 7 of 28 , Sep 14, 2008
                • 0 Attachment
                  I posted an anecdote
                  <http://technicaldebt.com/archives/2008_09.html#000787> that involves
                  food <g>


                  jon


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


                  Jon Kern said the following on 9/14/08 12:29 PM:
                  >
                  > The user is not always right. Neither am I :-0
                  >
                  > User's sometimes don't even ask for the right features. When it comes to
                  > User Experience designs from users, these can often be quite horrendous.
                  > We have to fight through the "crud" and see the true business needs.
                  >
                  > However, working together is always "right."
                  >
                  > <anecdote>
                  > We are almost in Alpha. I get a call from a manager "Just got an email
                  > from Marc. The business says we need to have encryption."
                  > "Oh? Well, we have the entire site done via https and a login. Isn't a
                  > login via authorized account, and having each page protected like how
                  > Amazon.com does for credit cards good enough?"
                  > Then I call the business analyst.
                  > Long story short: turns out the business needs to have specific fields
                  > (like social security number) hidden from view. "Do you mean with
                  > asterisks like we do for password fields?" "Yes." "Ok. Piece of cake to
                  > handle that. This is not 'encryption.'" "Oh, sorry." "No problem. Just
                  > try to express business needs in their language and don't try to speak
                  > my language. We don't need any additional mis-translations." "Ok."
                  > </anecdote>
                  >
                  > Working with the right folks to elicit the "true" business requirements
                  > at the right times in the project can improve the chances you will
                  > produce the right outcome in a timely manner to meet the business' needs.
                  >
                  > jon
                  >
                  > blog: TechnicalDebt.com <http://technicaldebt.com
                  > <http://technicaldebt.com>>
                  > View Jon Kern's profile <http://www.linkedin.com/in/jonkern
                  > <http://www.linkedin.com/in/jonkern>>
                  >
                  > spbroi@... <mailto:spbroi%40aol.com> said the following on 9/13/08
                  > 5:18 PM:
                  > >
                  > > 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
                  > <http://www.stylelist.com/trends?ncid=aolsty00050000000014>>.
                  > >
                  >
                  >
                • Nick Gassman
                  ... Seems reasonable to me. The person paying the money does have the right to call the shots, and whether or not they actually stay in business may depend on
                  Message 8 of 28 , Sep 14, 2008
                  • 0 Attachment
                    On Sun, 14 Sep 2008 11:50:35 -0400, Ron wrote:

                    >However, that doesn't seem to be the way of things. It's still the
                    >golden rule (him as has the gold makes the rules) and that means
                    >that if we want our ideas to prevail we pretty much have two
                    >choices. We can learn to persuade people of the rightness of our
                    >ideas (probably learning a lot about what they should be in the
                    >process). Or we can go our own way on our own money and build the
                    >better mousetrap and see whether they flock to our door.
                    >
                    >
                    >In practice, of course, we blend and mix and match. Still and all,
                    >we only get things done when we stop whining and start playing the
                    >game.

                    Seems reasonable to me. The person paying the money does have the
                    right to call the shots, and whether or not they actually stay in
                    business may depend on whether or not they listen and take advice.

                    From my point of view, I'll listen to ideas from anyone - *even* from
                    programmers :). Anyone working on a project can contribute ideas about
                    the UI, and it's the job of the UX person to ensure that they are all
                    considered, and to make a judgement as to whether they are worth
                    trying on users. This assumes that it's not feasible time-wise or
                    economically to test every idea. I'd also pre-empt a possible response
                    to say that you get good and bad UX people, but you have to have some
                    filtering method. I'd also emphasise again that I don't see it as my
                    role initially to decide what the design is, but just what's good
                    enough to try, including different approaches and options for any
                    given design issue.

                    * Nick Gassman - Usability and Standards Manager - http://ba.com *
                  • Nick Gassman
                    ... 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
                    Message 9 of 28 , Sep 14, 2008
                    • 0 Attachment
                      On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:

                      >Working with the right folks to elicit the "true" business requirements
                      >at the right times in the project can improve the chances you will
                      >produce the right outcome in a timely manner to meet the business' needs.

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

                      * Nick Gassman - Usability and Standards Manager - http://ba.com *
                    • William Pietri
                      ... Although I d agree energetically with all but one word of this, and wish more people understood the power of it, I think following this advice on its own
                      Message 10 of 28 , Sep 14, 2008
                      • 0 Attachment
                        Dan Harrelson wrote:
                        Users can rarely tell you accurately what they want from a product. [...]

                        User behaviors on the other hand are often dead on. [...]

                        As others in this thread have identified, the combination of listening to your users plus expertise in product design results in the best possible solutions.

                        Although I'd agree energetically with all but one word of this, and wish more people understood the power of it, I think following this advice on its own can lead people to the expert-as-priest style of interaction, which I think can be harmful.

                        Experts are more likely to be right, it's true. But they still are prone to error, and still have areas of weakness, often different areas of weakness than regular users or professionals in other disciplines.

                        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.

                        William

                      • Ron Jeffries
                        Hello, Nick. On Sunday, September 14, 2008, at 12:54:21 PM, you ... I ll bet fewer would object to questions like Could you tell me more about that feature
                        Message 11 of 28 , Sep 14, 2008
                        • 0 Attachment
                          Hello, Nick. On Sunday, September 14, 2008, at 12:54:21 PM, you
                          wrote:

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

                          >>Working with the right folks to elicit the "true" business requirements
                          >>at the right times in the project can improve the chances you will
                          >>produce the right outcome in a timely manner to meet the business' needs.

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

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          It is better to attempt something great and fail that attempt,
                          than to attempt to do nothing and succeed.
                          --Cookie, Garden Court Chinese Restaurant, Hamburg, MI
                        • Ron Jeffries
                          Hello, William. On Sunday, September 14, 2008, at 1:34:10 PM, you ... Yes. Experts don t know what I want. All the auto manufacturers have experts. Very few
                          Message 12 of 28 , Sep 14, 2008
                          • 0 Attachment
                            Hello, William. On Sunday, September 14, 2008, at 1:34:10 PM, you
                            wrote:

                            > Experts are more likely to be right, it's true. But they still are prone
                            > to error, and still have areas of weakness, often different areas of
                            > weakness than regular users or professionals in other disciplines.

                            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.

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

                            Yes, indeed.

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            I once had a coworker who worked so hard that when I came in the
                            morning, he was already sitting there trying to fix the things he
                            broke after I left the day before ... -- Ilja Preuss.
                          • Theo Mandel, Ph.D.
                            Interesting discussion topic! A long-standing saying in the UI/Usability/User experience field is, Listen to your users...and then do what s right. It s fine
                            Message 13 of 28 , Sep 14, 2008
                            • 0 Attachment
                              Interesting discussion topic!

                              A long-standing saying in the UI/Usability/User experience field
                              is, "Listen to your users...and then do what's right."

                              It's fine to ask users to tell you what they want from the UI and what
                              they want to do. However, users shouldn't be telling you how the UI
                              should look and work. Don't let users (especially executives in charge
                              of the project, rather than the actual users) get in the habit of
                              telling you, "Put a radio button here and a pick-list here." They
                              really don't understand how to design a UI - some people even call
                              them "radial buttons."

                              With my clients, I work hard to train and encourage users to tell me
                              what they want to do and what information they need to do their tasks,
                              but that they don't need to design the UI itself. That's what we're
                              here for.

                              Theo Mandel, Ph.D.
                              Interface Design and Development, LLC
                            • Nick Gassman
                              ... 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 -
                              Message 14 of 28 , Sep 14, 2008
                              • 0 Attachment
                                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 *
                              • Nick Gassman
                                ... 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
                                Message 15 of 28 , Sep 14, 2008
                                • 0 Attachment
                                  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 *
                                • William Pietri
                                  ... I m not knocking talking with users; it s great. But I didn t mean collaboration just among professionals. I was also thinking of collaboration with users.
                                  Message 16 of 28 , Sep 14, 2008
                                  • 0 Attachment
                                    Nick Gassman wrote:
                                    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.
                                      

                                    I'm not knocking talking with users; it's great. But I didn't mean collaboration just among professionals. I was also thinking of collaboration with users.

                                    As an example for modern design methods, cars are nearly pessimal. They're complicated, expensive physical objects made mainly by giant companies, with a small number of hard-to-change products for a large, varied base of users, and sold through extensive marketing and notoriously manipulative sales practices. It's a miracle anybody finds them satisfying.

                                    Consider instead the now-ubiquitous FAQs, or Ruby on Rails, or Wikipedia. All of these have a role for experts, but are at the core much more collaborative. Many modern web-based products like Flickr, Twitter, and many blogging platforms have their shape not because of elevated experts, but because users and designers explored the design space together.

                                    William

                                  • Ron Jeffries
                                    Hello, Nick. On Sunday, September 14, 2008, at 3:18:03 PM, you ... Courtesy isn t tiptoeing, you irritating little twit! :) But seriously, it seems to me that
                                    Message 17 of 28 , Sep 14, 2008
                                    • 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.

                                      Courtesy isn't tiptoeing, you irritating little twit! :)

                                      But seriously, it seems to me that if we're good at saying things
                                      that can be heard, we'll do better. I just wish I were ...

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
                                    • 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 18 of 28 , Sep 14, 2008
                                      • 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 19 of 28 , Sep 14, 2008
                                        • 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 20 of 28 , Sep 14, 2008
                                          • 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 21 of 28 , Sep 14, 2008
                                            • 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 22 of 28 , Sep 15, 2008
                                              • 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 23 of 28 , Sep 15, 2008
                                                • 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 24 of 28 , Sep 16, 2008
                                                  • 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 25 of 28 , Sep 16, 2008
                                                    • 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 26 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 27 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 28 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.