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

RE: [agile-usability] user centered design overlaps with traditional analysis?

Expand Messages
  • Jade Ohlhauser
    What I meant by wide over deep is that it covers the end to end experience , or say path , of the feature without having to go deep on each feature. In other
    Message 1 of 26 , Feb 3, 2005
    • 0 Attachment
      Message
      What I meant by wide over deep is that it covers the end to end "experience", or say "path", of the feature without having to go deep on each feature. In other words, make sure everything that needs to be talked about is there, without necessarily having each point fleshed out. Kind of like an outline.
       
      Other people have said this better than me and I think this point was from Cooper's Asylum, but I may be wrong (too many good books out there).
       
      Jade Ohlhauser
      Product Manager
      RPM Software                          
      www.rpmsoftware.com 403-265-6727
       


      From: Desilets, Alain [mailto:alain.desilets@...]
      Sent: Thursday, February 03, 2005 11:28 AM
      To: 'agile-usability@yahoogroups.com'
      Subject: RE: [agile-usability] user centered design overlaps with traditional analysis?

      When it comes to specs I believe width is more important to depth. Makes sure the spec is end to end, but it's OK if you can't go into detail on everything in between right away.  
       
      -- Alain Désilets
      I am confused by this statement... it seems to contradict itself.
       
      To me, doing things "end-to-end" means depth-first, not breadth first. More precisely, it means you focus on one particular user task that the system needs to support, and implement it without worrying about the rest (or at least, not until the rest is proven to be actually needed). In ExtremeProgramming, this has been captured by quaint phrases like YAGNI ("You Ain't Gonna Need It") and "Implement the Simplest Thing that Could Possibly Work".
       
      I have found that to work very well. You design a small part of the system, implement it, deploy it, gather feedback about it, then refactor it, or augment it with new functionality. Each of these cycles takes about one to two weeks. Note that refactoring includes changing the UI so that it is easier to  use given the current set of features supported by the system.
       
      In my opinion, this approach is the only way to gather information about ACTUAL needs, especially when you are designing a new and innovative product where no-one (including users, managers and yes, usability experts) really understand what is required.
       
      In my opinion, any process where more than 10% of the project time is spent upfront on gathering requirements and producing design documents, does not qualify as Agile.
       

      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada

       

    • Jeff Patton
      I m just catching up with this list [and the rest of my life for that matter...] ... These are the failure conditions I hear Alistair Cockburn harp about
      Message 2 of 26 , Feb 10, 2005
      • 0 Attachment
        I'm just catching up with this list [and the rest of my life for that
        matter...]

        --- In agile-usability@yahoogroups.com, Josh Seiden <joshseiden@y...>
        wrote:
        > This team has been very detail oriented, so the specs
        > represent a documentation of every possible thing that
        > could ever happen. (What if a fire alarm sounds while
        > the user is eating a low-fat tuna sandwich while
        > entering this data? Is that different from the case in
        > which the tuna sandwich is made with regular tuna
        > salad?")

        These are the failure conditions I hear Alistair Cockburn harp about
        frequently... and he's winning me over. Doing design work often has
        me focusing on the most probable "happy path" and paying a bit less
        attention to failure conditions. Alistair asserts that use cases
        force consideration of those failure conditions sooner. And,
        supporting what he's saying I've seen lots of nasty stuff that causes
        delays in development bubble out of the failure conditions. But,
        often that nasty stuff only slightly affects UI design or user
        interactions.

        Is it safe to assume that fire-alarm-with-low-fat-tuna-salad was a
        failure condition on a use case? Did you have use cases to work
        from, and did you find that the usecases documented basic user
        interaction reasonably - in a way useful for your design work?

        Thanks,

        -Jeff
      • Jeff Patton
        ... are sent ... folks ... revision, and ... We ve been bad at subscribing to changes - we ve had the silly belief that since they re sitting a few feet from
        Message 3 of 26 , Feb 10, 2005
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, "Sue Heim" <sue_heim@m...>
          wrote:
          > Can't your subscribe to the Wiki, so that changes to any document
          are sent
          > out to the appropriate parties? This would ensure, anyways, that
          folks
          > who've already read the doc will be notified that there is a
          revision, and
          > they oh yeah, maybe they oughta go check it out...?
          >

          We've been bad at subscribing to changes - we've had the silly belief
          that since they're sitting a few feet from us and they know that
          we're working on their story they might /tell/ us. But, I'm being
          overly harsh - our super users are good people and usually do tell
          us.

          The bigger problems have been that the documents they write contain
          lots of words... lots of words that they've written independently
          without a lot of support from others. Those words contain design
          decisions. Programmers read the words and say to themselves, "these
          are my requirements, I'll write the software this way." There's
          often not much conversation about those words. But, often we find
          out the words result in a piece of software that's clumsy to use - or
          has contradictory information in it. In those cases we have a
          conversation with the person who wrote the document and find that
          what they'd written isn't really what they meant, and they're quick
          to accept any suggestions we have for improvement.

          At our recent reflection session we decided it would be best if the
          documents were delievered along with a face to face conversation. We
          continue to be reminded that documents give us a false sense of
          security - that words in print seem "right" even though they're often
          not.

          thanks,

          -Jeff
        • Chris
          I lived though similar situations. And the politics always ended badly. ... From: Jeff Patton Date: Thu, 10 Feb 2005 15:04:28
          Message 4 of 26 , Feb 10, 2005
          • 0 Attachment
            I lived though similar situations. And the politics always ended badly.

            -----Original Message-----
            From: "Jeff Patton" <jpatton@...>
            Date: Thu, 10 Feb 2005 15:04:28
            To:agile-usability@yahoogroups.com
            Subject: [agile-usability] Re: user centered design overlaps with traditional analysis?



            --- In agile-usability@yahoogroups.com, "Sue Heim" <sue_heim@m...>
            wrote:
            > Can't your subscribe to the Wiki, so that changes to any document
            are sent
            > out to the appropriate parties? This would ensure, anyways, that
            folks
            > who've already read the doc will be notified that there is a
            revision, and
            > they oh yeah, maybe they oughta go check it out...?
            >

            We've been bad at subscribing to changes - we've had the silly belief
            that since they're sitting a few feet from us and they know that
            we're working on their story they might /tell/ us. But, I'm being
            overly harsh - our super users are good people and usually do tell
            us.

            The bigger problems have been that the documents they write contain
            lots of words... lots of words that they've written independently
            without a lot of support from others. Those words contain design
            decisions. Programmers read the words and say to themselves, "these
            are my requirements, I'll write the software this way." There's
            often not much conversation about those words. But, often we find
            out the words result in a piece of software that's clumsy to use - or
            has contradictory information in it. In those cases we have a
            conversation with the person who wrote the document and find that
            what they'd written isn't really what they meant, and they're quick
            to accept any suggestions we have for improvement.

            At our recent reflection session we decided it would be best if the
            documents were delievered along with a face to face conversation. We
            continue to be reminded that documents give us a false sense of
            security - that words in print seem "right" even though they're often
            not.

            thanks,

            -Jeff







            Yahoo! Groups Links









            Sent wirelessly via BlackBerry from T-Mobile.
          • Chris
            It s funny that you mention those failure conditions. There is this product that automatically handes those failures. They call these failures exceptions. For
            Message 5 of 26 , Feb 10, 2005
            • 0 Attachment
              It's funny that you mention those failure conditions. There is this product that automatically handes those failures. They call these failures exceptions. For design, you just have to worry about the happy paths. So far I'm really impressed by its simplicity.

              -----Original Message-----
              From: "Jeff Patton" <jpatton@...>
              Date: Thu, 10 Feb 2005 14:53:48
              To:agile-usability@yahoogroups.com
              Subject: [agile-usability] Re: user centered design overlaps with traditional analysis?



              I'm just catching up with this list [and the rest of my life for that
              matter...]

              --- In agile-usability@yahoogroups.com, Josh Seiden <joshseiden@y...>
              wrote:
              > This team has been very detail oriented, so the specs
              > represent a documentation of every possible thing that
              > could ever happen. (What if a fire alarm sounds while
              > the user is eating a low-fat tuna sandwich while
              > entering this data? Is that different from the case in
              > which the tuna sandwich is made with regular tuna
              > salad?")

              These are the failure conditions I hear Alistair Cockburn harp about
              frequently... and he's winning me over. Doing design work often has
              me focusing on the most probable "happy path" and paying a bit less
              attention to failure conditions. Alistair asserts that use cases
              force consideration of those failure conditions sooner. And,
              supporting what he's saying I've seen lots of nasty stuff that causes
              delays in development bubble out of the failure conditions. But,
              often that nasty stuff only slightly affects UI design or user
              interactions.

              Is it safe to assume that fire-alarm-with-low-fat-tuna-salad was a
              failure condition on a use case? Did you have use cases to work
              from, and did you find that the usecases documented basic user
              interaction reasonably - in a way useful for your design work?

              Thanks,

              -Jeff







              Yahoo! Groups Links









              Sent wirelessly via BlackBerry from T-Mobile.
            • Cummins, Darin
              We ve only recently started writing use-cases, so take this for what it is worth. When we sit down to create the use-cases (usually with product management, QA
              Message 6 of 26 , Feb 10, 2005
              • 0 Attachment

                We’ve only recently started writing use-cases, so take this for what it is worth.

                 

                When we sit down to create the use-cases (usually with product management, QA and someone from customer service all taking the role of “user”), it’s been interesting to see how the UI has changed from what the developer thought it should be, to something that really works for the user.  By discussing the failure conditions and how the UI is going to respond, the developers have really been re-thinking the entire front end, especially how it interacts with the backend.

                 

                We had one project recently where a developer created the UI based on the simple requirements delivered, just the way we use to do it.  Everyone, including people from outside of development, really liked what he had done.  He was then pulled off on another project while we got together and created use-cases.  When we revisited the UI, it became blatantly obvious that it would not work and we redesigned it.  (What a concept!)

                 

                Anyway, in that case, the failure conditions and how it was decided to be handled in the UI, actually simplified the way the backend needed to work.

                 

                --Darin

                 

                 

                 

                 

                 


                From: Jeff Patton [mailto:jpatton@...]
                Sent: Thursday, February 10, 2005 7:54 AM
                To: agile-usability@yahoogroups.com
                Subject: [agile-usability] Re: user centered design overlaps with traditional analysis?

                 


                I'm just catching up with this list [and the rest of my life for that
                matter...]

                --- In agile-usability@yahoogroups.com, Josh Seiden <joshseiden@y...>
                wrote:
                > This team has been very detail oriented, so the specs
                > represent a documentation of every possible thing that
                > could ever happen. (What if a fire alarm sounds while
                > the user is eating a low-fat tuna sandwich while
                > entering this data? Is that different from the case in
                > which the tuna sandwich is made with regular tuna
                > salad?")

                These are the failure conditions I hear Alistair Cockburn harp about
                frequently... and he's winning me over.  Doing design work often has
                me focusing on the most probable "happy path" and paying a bit less
                attention to failure conditions.  Alistair asserts that use cases
                force consideration of those failure conditions sooner.  And,
                supporting what he's saying I've seen lots of nasty stuff that causes
                delays in development bubble out of the failure conditions.  But,
                often that nasty stuff only slightly affects UI design or user
                interactions.

                Is it safe to assume that fire-alarm-with-low-fat-tuna-salad was a
                failure condition on a use case?  Did you have use cases to work
                from, and did you find that the usecases documented basic user
                interaction reasonably - in a way useful for your design work?

                Thanks,

                -Jeff






              • Jamie Nettles
                Absolutely. I use software to accomplish tasks. I want the software to work. I want to get the job done efficiently and move on. Makes me want to reread
                Message 7 of 26 , Feb 24, 2005
                • 0 Attachment
                  Absolutely. I use software to accomplish tasks. I want the software to work. I want to get the job done efficiently and move on. Makes me want to reread "Software for Use".

                  > -----Original Message-----
                  > From: Larry Constantine [mailto:lconstantine@...]
                  > Sent: Thursday, February 24, 2005 11:00 AM
                  > To: agile-usability@yahoogroups.com
                  > Subject: RE: [agile-usability] Naming the thing (was "user
                  > centered design overlaps with traditional analysis?)
                  >
                  >
                  > Josh et al.,
                  >
                  > Ux (user experience) design does seem to be winning the
                  > branding race, in part because it is so wonderfully fuzzy and
                  > capable of covering almost anything and everything--the
                  > entire "experience" of the user. Aside from the philosophical
                  > and semantic issue of whether anyone can ever design
                  > another's experience (and this from someone who wrote a
                  > classic article on psychotherapy training titled "Designed
                  > Experience"), it is precisely the enormous potential purview
                  > of UxD that is worrisome.
                  >
                  > Ultimately what gives users a good experience is their
                  > ability to do what they need to do efficiently and
                  > dependably. Supporting effective user performance is 90% of
                  > the story, which is why we make that the centerpiece of
                  > USAGE-centered design. The problem with so much of
                  > user-experience design and user-centered approaches in
                  > practice, is that they spend so much time and attention on
                  > matters that may be fun and interesting and help make users
                  > feel appreciated and attended to while promoting full
                  > employment for Ux designers but that have little if anything
                  > to do with the really important stuff in visual and
                  > interaction design.
                  >
                  > (Would you believe, for example, a forthcoming book on
                  > personas argues that clipart headshots or stock photos are
                  > not "real" enough and should not be used to illustrate
                  > personas. Instead, each team should go out and do its own
                  > photo shoots of real people based on careful research on how
                  > best to embody each persona. Somebody, methinks, has too much
                  > time on their hands.)
                  >
                  > We use small, simple, scaled-down abstract models to focus on
                  > the bare essentials with the greatest impact because we want
                  > to use our limited time for designing a user interface that
                  > really works for users, rather than for shooting and editing
                  > compelling videotapes, compiling and categorizing great heaps
                  > of stick-notes, or concocting believable biographies for
                  > fictitious users whose profiles can be turned into
                  > large-format color posters to grace the walls of the
                  > development facility.
                  >
                  > Okay, I know I am a minority voice here (and when or where
                  > has it been otherwise?), but I have seen too many loftily
                  > user-centered projects miss the boat completely because they
                  > missed the central point of good design. It is not about
                  > users, it is about uses (or usage, if you prefer).
                  >
                  > --Larry Constantine, IDSA [mailto:lconstantine@...]
                  >   Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com
                  >
                  > > -----Original Message-----
                  > > From: Josh Seiden [mailto:joshseiden@...]
                  > > Sent: Tuesday, 01 February 2005 6:10 PM
                  > > To: agile-usability@yahoogroups.com
                  > > Subject: [agile-usability] Naming the thing (was "user
                  > centered design
                  > overlaps with
                  > > traditional analysis?)
                  > >
                  > >
                  > > Since this has come up a lot recently, I thought I'd chime in.
                  > >
                  > > There is a growing movement to call the larger practice of
                  > > user-centered-design by the name "User Experience Design",
                  > "Experience
                  > > Design" or simply, "UX", and to consider the word
                  > "usability" in it's
                  > > narrow meaning.
                  > >
                  > > This naming convention is based on a couple of ideas:
                  > >
                  > > 1. That as products and services become more complex, they require
                  > > people who practice a variety of disciplines to get the
                  > > product/service built.
                  > >
                  > > An e-commerce site might need interaction design, information
                  > > architecture, usability evaluation graphic design, service design,
                  > > corporate identity design, etc.
                  > >
                  > > 2. Some of these people have titles that identify the single
                  > > discipline they practice (graphic design) and other do not.
                  > (As noted,
                  > > "usability people" might practice a variety of disciplines.)
                  > >
                  > > 3. That there is value in identifying the common thread and
                  > methods,
                  > > and value in developing the various disciplines with greater rigor.
                  > >
                  > > Thus, we're starting to see some umbrella organizations emerge to
                  > > represent the larger practice of User Experience Design. These
                  > > organizations include AIGA-ED and UXnet.net.
                  > >
                  > > We're also starting to see some new discipline-focused
                  > organizations
                  > > like AIFIA and IxDG that advocate for more narrow
                  > definitions of their
                  > > respective disciplines.
                  > >
                  > > And of course, as with all naming exercises, this one had plenty of
                  > > politics and controversy too. ;-)
                  > >
                  > > JS
                  > >
                  > >
                  > >
                  > > --- Kay Burnett <kayburnett2002@...> wrote:
                  > >
                  > > > I have
                  > > > thought for some time that the title or topic of
                  > "usability" needs
                  > > > to either be defined narrowly or be expanded
                  > >
                  > >
                  > >
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  >
                  >
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                • Larry Constantine
                  Jamie wrote: Absolutely. I use software to accomplish tasks. I want the software to work. I want to get the job done efficiently and move on. Makes me
                  Message 8 of 26 , Feb 25, 2005
                  • 0 Attachment
                    Jamie wrote:

                    "Absolutely. I use software to accomplish tasks. I want the software to
                    work. I want to get the job done efficiently and move on. Makes me want to
                    reread "Software for Use"."

                    Go for it! :-) I'll even autograph your copy.

                    I am increasingly convinced that mainstream user-centered design has drifted
                    off target, although I get brickbats every time I dare to suggest this in
                    public. I did stick my neck out recently in the Cutter IT Journal in a
                    provocative article called "Beyond User-Centered Design"
                    (http://www.cutter.com/offers/userdesign.html).

                    --Larry Constantine, IDSA
                    Chief Scientist | Constantine & Lockwood Ltd | www.foruse.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.