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

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

Expand Messages
  • 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 1 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 2 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.