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

How does using an agile method /help/ doing UX work?

Expand Messages
  • Jeff Patton
    Last week when talking with a group of UX people I was asked the perfectly reasonably question: How does using an Agile method /help/ in doing UX work? I
    Message 1 of 8 , Mar 8 11:47 PM
    • 0 Attachment
      Last week when talking with a group of UX people I was asked the perfectly
      reasonably question: "How does using an Agile method /help/ in doing UX
      work?" I stammered out some possibly lame answer - or dodged the question
      outright - I don't remember. But, it made me realize:

      I actually hadn't thought about it that way before. I was already so sold
      on Agile approaches from a development techniques perspective, and based on
      the benefits of iterative development and incremental release, that it
      hadn't occurred to me that /not/ using an Agile approach was an option. I'd
      then been working at making UX approaches fit gracefully into an Agile
      lifecycle - because I believe that we must _intentionally_ design our
      software, and UX approaches offer solutions there. I actually came to
      practice UX approaches more seriously /after/ adopting agile approaches - so
      I'd never had to ask myself this question beforehand.

      But, all companies don't use Agile approaches - and many do pretty well
      without them.

      So, I know that there are subscribers on this list currently and
      successfully practicing UX techniques on projects that deliver using an
      Agile approach. And, I expect that there are designers that saw the
      adoption of agile approaches while they were practicing design. Can any of
      you comment on the advantages of using UX techniques in an Agile context?

      Thanks in advance for you comments. Please feel free to contact me on or
      off list.

      -Jeff
      ---------------------
      Jeff Patton
      (801) 910-7908
      www.abstractics.com/papers

      Canadian Agile Network Workshop:
      http://www.agilenetwork.ca/Wiki.jsp?page=Ws2005

      UPA Agile-UCD Tutorial:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=179

      UPA Agile-Usability Workshop:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=156OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?id=105

      Agile usability news group: http://groups.yahoo.com/group/agile-usability/

      "Computers are useless. They can only give you answers."
      -- PABLO PICASSO
    • Desilets, Alain
      ... From: Jeff Patton [mailto:jpatton@acm.org] Sent: Wednesday, March 09, 2005 2:47 AM To: agile-usability@yahoogroups.com Subject: [agile-usability] How does
      Message 2 of 8 , Mar 9 5:35 AM
      • 0 Attachment
        -----Original Message-----
        From: Jeff Patton [mailto:jpatton@...]
        Sent: Wednesday, March 09, 2005 2:47 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] How does using an agile method /help/ doing UX
        work?



        "How does using an Agile method /help/ in doing UX work?"

        -- Alain:
        Don't ask what your country can do for you, ask what you can do for your
        country!

        Seriously, I think this is the wrong question to ask altogether. Ux work is
        only a means to an end, in the same way that Agile methods are a means to an
        end. Both of those have a pretty good track record at helping achieve the
        bottom line better, but they are not the bottom line. So the real question
        to ask is:

        "How can Agile and Ux methods combine to even better achieve the customer's
        bottom line, which should be something like: timely delivery of working and
        usable software that provides value."
        ----

        I stammered out some possibly lame answer - or dodged the question outright
        - I don't remember. But, it made me realize:

        I actually hadn't thought about it that way before. I was already so sold
        on Agile approaches from a development techniques perspective, and based on
        the benefits of iterative development and incremental release, that it
        hadn't occurred to me that /not/ using an Agile approach was an option. I'd
        then been working at making UX approaches fit gracefully into an Agile
        lifecycle - because I believe that we must _intentionally_ design our
        software, and UX approaches offer solutions there. I actually came to
        practice UX approaches more seriously /after/ adopting agile approaches - so
        I'd never had to ask myself this question beforehand.

        But, all companies don't use Agile approaches - and many do pretty well
        without them.

        So, I know that there are subscribers on this list currently and
        successfully practicing UX techniques on projects that deliver using an
        Agile approach. And, I expect that there are designers that saw the
        adoption of agile approaches while they were practicing design. Can any of
        you comment on the advantages of using UX techniques in an Agile context?

        Thanks in advance for you comments. Please feel free to contact me on or
        off list.

        -Jeff
        ---------------------
        Jeff Patton
        (801) 910-7908
        www.abstractics.com/papers

        Canadian Agile Network Workshop:
        http://www.agilenetwork.ca/Wiki.jsp?page=Ws2005

        UPA Agile-UCD Tutorial:
        http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
        tivity.php?id=179

        UPA Agile-Usability Workshop:
        http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
        tivity.php?id=156OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?id=105

        Agile usability news group: http://groups.yahoo.com/group/agile-usability/

        "Computers are useless. They can only give you answers."
        -- PABLO PICASSO






        Yahoo! Groups Links
      • Ray Rupinski
        I tend to concur w/ Jeff s original question. I m responsible for a design team who is just getting started w/ agile techniques. Up to this point, we ve done
        Message 3 of 8 , Mar 9 7:48 AM
        • 0 Attachment
          I tend to concur w/ Jeff's original question. I'm responsible for a
          design team who is just getting started w/ agile techniques.

          Up to this point, we've done "traditional" design work developing
          prototypes with varying degrees of fidelity. In practice, a large
          number of our designs (and their underlying code) have been worked
          into the final product. I'm not condoning that practice, but it's
          been our reality in many situations.

          Our design for a particular component or feature evolves and
          matures. Improvements are made iteratively before they're included
          in the final version of the product. I'm wondering how agile
          methods support/conflict with this reality. We know that we're not
          going to have the perfect widget out of the box (or as part of this
          thing called a "sprint"). And my team benefits from
          that "maturation" process where it has time to be experienced by
          various users/representatives.

          I'd be interested in how other companies developing mission-critical
          apps handle this with applications that are extremely UI-intensive.
          I'd like to hear how companies w/ web designers and usability
          professionals "play" on scrum teams and handle sprints.

          Keep in mind, I'm still a novice at this agile stuff. So be kind.

          --- In agile-usability@yahoogroups.com, "Desilets, Alain"
          <alain.desilets@n...> wrote:
          >
          >
          > -----Original Message-----
          > From: Jeff Patton [mailto:jpatton@a...]
          > Sent: Wednesday, March 09, 2005 2:47 AM
          > To: agile-usability@yahoogroups.com
          > Subject: [agile-usability] How does using an agile method /help/
          doing UX
          > work?
          >
          >
          >
          > "How does using an Agile method /help/ in doing UX work?"
          >
          > -- Alain:
          > Don't ask what your country can do for you, ask what you can do
          for your
          > country!
          >
          > Seriously, I think this is the wrong question to ask altogether.
          Ux work is
          > only a means to an end, in the same way that Agile methods are a
          means to an
          > end. Both of those have a pretty good track record at helping
          achieve the
          > bottom line better, but they are not the bottom line. So the real
          question
          > to ask is:
          >
          > "How can Agile and Ux methods combine to even better achieve the
          customer's
          > bottom line, which should be something like: timely delivery of
          working and
          > usable software that provides value."
          > ----
          >
          > I stammered out some possibly lame answer - or dodged the question
          outright
          > - I don't remember. But, it made me realize:
          >
          > I actually hadn't thought about it that way before. I was already
          so sold
          > on Agile approaches from a development techniques perspective, and
          based on
          > the benefits of iterative development and incremental release,
          that it
          > hadn't occurred to me that /not/ using an Agile approach was an
          option. I'd
          > then been working at making UX approaches fit gracefully into an
          Agile
          > lifecycle - because I believe that we must _intentionally_ design
          our
          > software, and UX approaches offer solutions there. I actually
          came to
          > practice UX approaches more seriously /after/ adopting agile
          approaches - so
          > I'd never had to ask myself this question beforehand.
          >
          > But, all companies don't use Agile approaches - and many do pretty
          well
          > without them.
          >
          > So, I know that there are subscribers on this list currently and
          > successfully practicing UX techniques on projects that deliver
          using an
          > Agile approach. And, I expect that there are designers that saw
          the
          > adoption of agile approaches while they were practicing design.
          Can any of
          > you comment on the advantages of using UX techniques in an Agile
          context?
          >
          > Thanks in advance for you comments. Please feel free to contact
          me on or
          > off list.
          >
          > -Jeff
          > ---------------------
          > Jeff Patton
          > (801) 910-7908
          > www.abstractics.com/papers
          >
          > Canadian Agile Network Workshop:
          > http://www.agilenetwork.ca/Wiki.jsp?page=Ws2005
          >
          > UPA Agile-UCD Tutorial:
          >
          http://www.upassoc.org/conferences_and_events/upa_conference/2005/pro
          gram/ac
          > tivity.php?id=179
          >
          > UPA Agile-Usability Workshop:
          >
          http://www.upassoc.org/conferences_and_events/upa_conference/2005/pro
          gram/ac
          > tivity.php?id=156OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?
          id=105
          >
          > Agile usability news group: http://groups.yahoo.com/group/agile-
          usability/
          >
          > "Computers are useless. They can only give you answers."
          > -- PABLO PICASSO
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
        • Robin Dymond
          This is an interesting question, because it I believe it depends on the perspective of the practitioner. In my experience, this becomes an issue when the
          Message 4 of 8 , Mar 9 7:59 AM
          • 0 Attachment
            This is an interesting question, because it I believe it depends on the
            perspective of the practitioner. In my experience, this becomes an issue
            when the person doing the interaction design is really focused on creating
            the "best design" without much regard for the fact that the design lives
            embedded in an application or web site that a) is constrained by the
            business, or b) is constrained by the systems the design must live on top
            of. It is wonderful to come up with a great user experience, but if this
            work is done in a bubble, without properly accounting for the limitations
            and constraints of the system, the design is a fantasy that sooner or later
            must be altered to fit into a real system. This UCD/IA bubble is found in
            the waterfall process. This bubble makes practitioners happy, because they
            can focus on building the best user experience they can, unconstrained by
            dirty little realities. However this bubble results in re-work and delays
            that impact everyone downstream, including designers, web developers,
            application developers, QA, and of course the project timeline.

            So some UX practitioners will definitely prefer not living in the dirty
            realities of an agile project... But then again, no one could claim that a
            2" stack of Visio diagrams is working software...

            Cheers,
            Robin.


            -----Original Message-----
            From: Jeff Patton [mailto:jpatton@...]
            Sent: Wednesday, March 09, 2005 12:47 AM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] How does using an agile method /help/ doing UX
            work?


            Last week when talking with a group of UX people I was asked the perfectly
            reasonably question: "How does using an Agile method /help/ in doing UX
            work?" I stammered out some possibly lame answer - or dodged the question
            outright - I don't remember. But, it made me realize:

            I actually hadn't thought about it that way before. I was already so sold
            on Agile approaches from a development techniques perspective, and based on
            the benefits of iterative development and incremental release, that it
            hadn't occurred to me that /not/ using an Agile approach was an option. I'd
            then been working at making UX approaches fit gracefully into an Agile
            lifecycle - because I believe that we must _intentionally_ design our
            software, and UX approaches offer solutions there. I actually came to
            practice UX approaches more seriously /after/ adopting agile approaches - so
            I'd never had to ask myself this question beforehand.

            But, all companies don't use Agile approaches - and many do pretty well
            without them.

            So, I know that there are subscribers on this list currently and
            successfully practicing UX techniques on projects that deliver using an
            Agile approach. And, I expect that there are designers that saw the
            adoption of agile approaches while they were practicing design. Can any of
            you comment on the advantages of using UX techniques in an Agile context?

            Thanks in advance for you comments. Please feel free to contact me on or
            off list.

            -Jeff
            ---------------------
            Jeff Patton
            (801) 910-7908
            www.abstractics.com/papers

            Canadian Agile Network Workshop:
            http://www.agilenetwork.ca/Wiki.jsp?page=Ws2005

            UPA Agile-UCD Tutorial:
            http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
            tivity.php?id=179

            UPA Agile-Usability Workshop:
            http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
            tivity.php?id=156OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?id=105

            Agile usability news group: http://groups.yahoo.com/group/agile-usability/

            "Computers are useless. They can only give you answers."
            -- PABLO PICASSO






            Yahoo! Groups Links








            The information contained in this message is confidential. It is intended to be read only by the individual or entity named above or their designee. If the reader of this message is not the intended recipient, you are hereby notified that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message.
          • Kevin Doyle
            Hello all, I m a jack-of-all-design-trades and have only recently started working in an agile environment. This is also my first time posting to this group,
            Message 5 of 8 , Mar 14 2:24 PM
            • 0 Attachment
              Hello all,

              I'm a jack-of-all-design-trades and have only recently started working
              in an agile environment. This is also my first time posting to this
              group, so, as Ray asked, be kind. ;)

              Okay, from what I understand about agile/lean methodologies is that
              iterative development is key. As a designer, I'm used to iterations -
              get requirements, design, show to client, make design/requirement
              adjustments, deliver to client. Agile methodologies just refine the
              adjustment process and include more than just the client to the
              adjustment process - it brings the developer in the room with the
              designer.

              > Up to this point, we've done "traditional" design work developing
              > prototypes with varying degrees of fidelity. In practice, a large
              > number of our designs (and their underlying code) have been worked
              > into the final product. I'm not condoning that practice, but it's
              > been our reality in many situations.

              The prototypes should be developed with the designer and the developer
              in close communication. I didn't think about it until now, but perhaps
              this would be a good place to use a variant on "Pair Programming", but
              instead of creating code (unless you prototype in HTML, of course),
              the designer and developer work on laying out the screen together.
              Questions like, "is this possible in with our back-end?" or "is this
              behavior too complicated for our project's scope?" can be easily
              answered as the two work out the design. I know, I know... this works
              against the grain of most designers, but pair programming isn't
              (initially) very natural for developers, either - but every developer
              that I've met that pair programs loves it.

              > Our design for a particular component or feature evolves and
              > matures. Improvements are made iteratively before they're included
              > in the final version of the product. I'm wondering how agile
              > methods support/conflict with this reality. We know that we're not
              > going to have the perfect widget out of the box (or as part of this
              > thing called a "sprint"). And my team benefits from
              > that "maturation" process where it has time to be experienced by
              > various users/representatives.

              The design process is already very iterative - it's something you're
              already used to. Here's the difference - the designers should be
              working directly with the developers, not isolated with other
              designers. The team isn't "The Design Team", it's the "Project Team".
              Ideally, the designer and the developer are in the same room together.
              At the very least, they should have a channel of communication that's
              completely open - no middle project manager-types should get in their
              way.

              Thanks for letting me babble!
              Kevin


              :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
              "We are all in the gutter, but some of us are looking at the stars."
              -- Oscar Wilde
            • Mark FelcanSmith
              ... dirty ... claim that a ... So used to hearing this slam against designers, not UX practitioners. The various disciplines that support the overarching UX
              Message 6 of 8 , Mar 16 8:13 PM
              • 0 Attachment
                --- Robin Dymond <robind@c...> wrote:
                > So some UX practitioners will definitely prefer not living in the
                dirty
                > realities of an agile project... But then again, no one could
                claim that a
                > 2" stack of Visio diagrams is working software...
                >
                So used to hearing this slam against designers, not UX
                practitioners. The various disciplines that support the overarching
                UX umbrella necessitate that work is not done in a bubble.
                Interaction design at it's core must account for system
                responsibilities and human-computer interactions, IxD is a tenant of
                a complete and compelling UX solution. If you're experiencing such
                short-sighted solutions, I don't see how they could be called UX
                solutions.

                one other note...

                --- In agile-usability@yahoogroups.com, Kevin Doyle <kbdoyle@g...>
                wrote:
                > The prototypes should be developed with the designer and the
                developer
                > in close communication. I didn't think about it until now, but
                perhaps
                > this would be a good place to use a variant on "Pair Programming",

                Kevin hits the issue straight-on here. And as I eluded to above,
                looking at the various disciplines that make up UX,
                working/functioning software is an absolute - there is no option.
                To your point Kevin, re: pair programming, on that same note we
                implemented pair analysis. Acting as a solo practitioner, mostly
                doing usability analysis I was paired w/ systems analysts who were
                the main story authors, however we worked closely together to define
                the interaction model, wireframes, and usability issues related to
                the story at hand. Along w/ this structure we include story reviews
                by our developers, as well as QA testers and business user group to
                ensure we were defining solutions that were not only usable, but
                useful.

                Take a look at this Venn diagram we've been passing around lately, I
                put this version together tonight to share w/ you, but worked w/
                Nick Hoyt to compose this particular version. I think it
                quite simply states the message of balancing business, technology,
                and user needs.
                http://www.venndiagram.com/detail.lasso?id=1101107798.gif

                -Mark
              • Baker, Lisa
                ... customer s ... and ... The bottom line plus to XP, in my mind, is we all (dev, test, HF, product management) are focused on the customer and are all open
                Message 7 of 8 , Mar 17 8:04 AM
                • 0 Attachment
                  >"How can Agile and Ux methods combine to even better achieve the
                  customer's
                  >bottom line, which should be something like: timely delivery of working
                  and
                  >usable software that provides value.">

                  The bottom line plus to XP, in my mind, is we all (dev, test, HF,
                  product management) are focused on the customer and are all open to
                  adjusting priorities based on new information because the process is
                  iterative -by design-. Traditional methodologies kind of launch the
                  Queen Mary and then it can take weeks to make adjustments. (And just
                  forget returning her to port!)

                  I've worked in both the traditional and the agile methodologies. In each
                  scenario, I have worked closely with the development team to create a
                  workable design that will really lives in the code. Typically, the first
                  designs are more 'ideal' and 'conceptual,' then after refinement and
                  feedback from customers, product management, etc., I worked with the
                  development team to rein it into reality. In my experience, if I brought
                  them a pie in the sky design, my credibility went down the toilet and so
                  did my influence. But, if I don't start with "ideal," we don't make many
                  advances. Often, by showing the "ideal" the developers get an idea of
                  how they might do an interaction we haven't designed before within the
                  constraints of the project.

                  The thing that is challenging for me about the agile methodology is
                  there is no "big picture" "know your customer research" piece carved
                  into the iterations. At release plan, everyone starts. By release plan,
                  I need to know all that stuff (and in practice here, communicate it to
                  the dev team). That usually means I essentially exit a previous project
                  early so I can get the stuff for the "new project" done and then I am
                  also doing some of that stuff along the way--feeding the customer data
                  knowledge base, etc.

                  A challenging thing about the traditional methodology is that developers
                  were much less willing to iterate. So we'd get user feedback, beta
                  visits, usability test feedback, etc., and they'd say "No. I coded that.
                  We're done. No time." We'd always -say- the recommendations would go
                  into the next release, but a lot of it was just left in the gutter and
                  we'd have some new priority for the next release.

                  In XP, the developers -expect- to iterate based on feedback. I get less
                  "I've coded that so I am not touching it again" both from dev management
                  and from the engineers themselves.

                  So let's say we finish up a feature in iteration 3, but we don't get the
                  feedback from the field until iteration 4. It's compelling. We are much
                  more likely to go back and rework the code to resolve the issues our
                  feedback exposed. And, more importantly, there is a procedural way to
                  adjust for these priorities. "Wow. We should probably drop story z,
                  which is less important, so we adjust feature ACY based on the feedback
                  from the customers." So it's not just customer feedback=rework=more
                  work. It's customer feedback=rework=adjusted stories.

                  I do actually simply sit and "pair" with developers on specific
                  screens...often "the small stuff." But, for larger interactions I still
                  do the initial prototyping and hand that off. We work through any
                  issues, problems, or new information together. Without having a mockup
                  to start with, it always takes the developer more time because he's
                  thinking things through while coding. With the mockup, the developer,
                  tester and I have thought through things together and iterated it. We
                  talk about the required acceptance tests. The back end coding can adjust
                  to front end needs before anything actually exists. Again, the challenge
                  here is to be ready with the design before they are so my "iterations"
                  run about a week ahead of them. Preferably I'd be a full iteration ahead
                  of them.

                  The other real plus is there is a methodology for product management
                  (the 'customer') to give real-time feedback so we can quickly meet
                  recently discovered requirements or opportunities. In the 'traditional'
                  process, marketing would invest up-front resource, through the document
                  over the fence to development, and then development would make something
                  that perhaps only bore a faint resemblance to what marketing asked for.
                  In the XP process, product management is involved in release planning,
                  iteration planning, and any needed release adjustments. They know what
                  they are getting and they have input on the priorities and adjustments
                  we need to make.


                  Lisa

                  This email, and any files or previous email messages included with it, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.
                • Phil Borlin
                  ... Do you mind expanding on this? What does this look like? In a local group a guy named Zhon has been talking about the value of pairing in order to
                  Message 8 of 8 , Mar 17 8:44 AM
                  • 0 Attachment
                    On Thu, 17 Mar 2005 09:04:38 -0700, Baker, Lisa <lisa.baker@...> wrote:

                    > I do actually simply sit and "pair" with developers on specific
                    > screens...often "the small stuff."

                    Do you mind expanding on this? What does this look like? In a local
                    group a guy named Zhon has been talking about the value of pairing in
                    order to transfer knowledge so the fact that a UCD person seeks out
                    someone to pair with is fascinating.

                    -Phil
                  Your message has been successfully submitted and would be delivered to recipients shortly.