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

user centered design overlaps with traditional analysis?

Expand Messages
  • Jeff Patton
    I ve been making the assertion over the last couple months that what traditional analysts are doing overlaps to a large degree with what UCD folks do. I d be
    Message 1 of 26 , Feb 1, 2005
    • 0 Attachment
      I've been making the assertion over the last couple months that what
      traditional analysts are doing overlaps to a large degree with what
      UCD folks do. I'd be curious if others agree.

      On my current project we have super user/analysts - folks that were
      strong users that are now being coached by a super-analyst to write
      XP type stories. We've also got a few UCD/UI design/usability
      people. There's a strained collaboration between these two groups.
      Both seem to have the goal of describing a piece of software that
      best addresses user needs. But, they have different backgrounds, use
      different approaches, and often come up with different solutions.
      They know they have something to offer each other, but are having
      trouble coming up with common language to do so. [I sometimes wonder
      whether the Meyers-Briggs scores for these two groups will ever allow
      them to communicate effectively... ;-) ]

      I spent a bit of time with Alistair Cockburn over last week trying to
      draw lines between use cases [and the techniques surrounding their
      use] and the hodge-podge of UCD stuff I'm doing. User profiles look
      like elaborated on actors. Actor-goal lists look like Constantine-
      style user roles - or possibly summary level use cases. User tasks
      look like "sea level" use cases. Where my UCD stuff emphasizes
      information about the user and their context of use, Use Cases excel
      at putting pressure on workflow variations - the ones that point out
      exceptions in business rules and approaches to failures in tasks -
      stuff I often don't spend much time thinking about. In short
      strokes, I'm seeing a fair bit of conceptual overlap between
      information covered in use case stuff, and information I try to
      contain in other types of UCD models. The information is just
      expressed differently.

      I sense that this is the challenge that UCD people often have
      integrating what they do into organizations with traditional
      requirements gathering analysts. Can anyone listening in speak to
      that?

      And, can anyone draw some correlation between traditional analysis
      artifacts and UCD models?

      And finally, can anyone tell any stories about how they've
      effectively [or ineffectively] combined analysts and UCD people?

      thanks,

      -Jeff
    • Kay Burnett
      this is a really interesting conversation about many topics in one context! I come to it as a former analyst turned UCD/Usability person. And I will segway
      Message 2 of 26 , Feb 1, 2005
      • 0 Attachment
        this is a really interesting conversation about many topics in one context! I come to it as a former analyst turned UCD/Usability person. And I will segway (sp?) with a comment on Hugh's notion of the changing role of the usability person -- I have thought for some time that the title or topic of "usability" needs to either be defined narrowly or be expanded to include the up-front processes of UCD with some monitoring during the actaul development and then back-end usability in an iterative cycle. This change has to occur, IMHO, because our clients often know only the word usability but don't really know UCD. We need to push to do the full cycle of UCD and usability: gathering customer needs, developing concepts based on their needs, prototyping and testing various concepts to find a fit to user needs and then and only then building out a final product.
         
        The best convergence of analyst and designer came from a conversation at UPA 2004 during the /what are they called/ poster sessions. A woman / whom I don't want to incorrectly identify but I'm not sure of her name so I won't name her / talked about her agile environment in which she was spearheading a continuous user research effort so that when user centered information was needed quickly in the agile cycle, she could visit the base of research that had been done and pull out user needs and desires around the part of the system that was being developed at that time. So they ran parallel processes in research and development and the 2 came together when needed. In a traditional UCD process, the user research often is crunched by being squeezed into a short timeframe and risking missing having the impact it could on the design and subsequent development.
         
        Hope this makes some sense to someone...thanks for the impetus to share.
        Kay Burnett
        Information Architect
        Dearborn

        Jeff Patton <jpatton@...> wrote:

        I've been making the assertion over the last couple months that what
        traditional analysts are doing overlaps to a large degree with what
        UCD folks do.  I'd be curious if others agree.

        On my current project we have super user/analysts - folks that were
        strong users that are now being coached by a super-analyst to write
        XP type stories.  We've also got a few UCD/UI design/usability
        people.  There's a strained collaboration between these two groups. 
        Both seem to have the goal of describing a piece of software that
        best addresses user needs.  But, they have different backgrounds, use
        different approaches, and often come up with different solutions. 
        They know they have something to offer each other, but are having
        trouble coming up with common language to do so.  [I sometimes wonder
        whether the Meyers-Briggs scores for these two groups will ever allow
        them to communicate effectively... ;-) ]

        I spent a bit of time with Alistair Cockburn over last week trying to
        draw lines between use cases [and the techniques surrounding their
        use] and the hodge-podge of UCD stuff I'm doing.  User profiles look
        like elaborated on actors.  Actor-goal lists look like Constantine-
        style user roles - or possibly summary level use cases.  User tasks
        look like "sea level" use cases.  Where my UCD stuff emphasizes
        information about the user and their context of use, Use Cases excel
        at putting pressure on workflow variations - the ones that point out
        exceptions in business rules and approaches to failures in tasks -
        stuff I often don't spend much time thinking about.  In short
        strokes, I'm seeing a fair bit of conceptual overlap between
        information covered in use case stuff, and information I try to
        contain in other types of UCD models.  The information is just
        expressed differently. 

        I sense that this is the challenge that UCD people often have
        integrating what they do into organizations with traditional
        requirements gathering analysts.  Can anyone listening in speak to
        that?

        And, can anyone draw some correlation between traditional analysis
        artifacts and UCD models?

        And finally, can anyone tell any stories about how they've
        effectively [or ineffectively] combined analysts and UCD people?

        thanks,

        -Jeff







        Do you Yahoo!?
        Yahoo! Search presents - Jib Jab's 'Second Term'
      • Josh Seiden
        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
        Message 3 of 26 , Feb 1, 2005
        • 0 Attachment
          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
        • Kay Burnett
          I didn t really follow my own train of thought when I started out the paragraph below. I wanted to comment on the different approaches that a UC designer and a
          Message 4 of 26 , Feb 2, 2005
          • 0 Attachment
            I didn't really follow my own train of thought when I started out the paragraph below. I wanted to comment on the different approaches that a UC designer and a traditional analyst may have to a project -- not to say that it has to be this way but this IME (in my experience) has been the reality -- per the original note of this subject.
             
            A User Centered Designer approaches the beginning of a project wanting to know about the users, the audience, the people who are the target and others who may be incidental users of a product. They want to understand the needs, the desires, the tasks, activities, environments, objects and other people that this person will interact with in the course of their use of the product. IME, the traditional analyst assumes a product and wants to start by defining features and functions which makes me uncomfortable until I can know something about the people involved. Once the effort gets underway, there is overlap in the analysis of available information. It is just that the starting places are different -- and this, in the long run, is a BIG difference.

            Kay Burnett <kayburnett2002@...> wrote:
            The best convergence of analyst and designer came from a conversation at UPA 2004 during the /what are they called/ poster sessions.
            Kay Burnett
            Information Architect
            Dearborn

            Jeff Patton <jpatton@...> wrote:

            I've been making the assertion over the last couple months that what
            traditional analysts are doing overlaps to a large degree with what
            UCD folks do.  I'd be curious if others agree.

            On my current project we have super user/analysts - folks that were
            strong users that are now being coached by a super-analyst to write
            XP type stories.  We've also got a few UCD/UI design/usability
            people.  There's a strained collaboration between these two groups. 
            Both seem to have the goal of describing a piece of software that
            best addresses user needs.  But, they have different backgrounds, use
            different approaches, and often come up with different solutions. 
            They know they have something to offer each other, but are having
            trouble coming up with common language to do so.  [I sometimes wonder
            whether the Meyers-Briggs scores for these two groups will ever allow
            them to communicate effectively... ;-) ]

            I spent a bit of time with Alistair Cockburn over last week trying to
            draw lines between use cases [and the techniques surrounding their
            use] and the hodge-podge of UCD stuff I'm doing.  User profiles look
            like elaborated on actors.  Actor-goal lists look like Constantine-
            style user roles - or possibly summary level use cases.  User tasks
            look like "sea level" use cases.  Where my UCD stuff emphasizes
            information about the user and their context of use, Use Cases excel
            at putting pressure on workflow variations - the ones that point out
            exceptions in business rules and approaches to failures in tasks -
            stuff I often don't spend much time thinking about.  In short
            strokes, I'm seeing a fair bit of conceptual overlap between
            information covered in use case stuff, and information I try to
            contain in other types of UCD models.  The information is just
            expressed differently. 

            I sense that this is the challenge that UCD people often have
            integrating what they do into organizations with traditional
            requirements gathering analysts.  Can anyone listening in speak to
            that?

            And, can anyone draw some correlation between traditional analysis
            artifacts and UCD models?

            And finally, can anyone tell any stories about how they've
            effectively [or ineffectively] combined analysts and UCD people?

            thanks,

            -Jeff







            Do you Yahoo!?
            Yahoo! Search presents - Jib Jab's 'Second Term'


            Do you Yahoo!?
            Yahoo! Search presents - Jib Jab's 'Second Term'

          • Joshua Seiden
            ... what ... what ... [snip] ... effectively ... Jeff, I agreee that there is a lot of overlap but as Kay said, a lot of the foundational assumptions are
            Message 5 of 26 , Feb 2, 2005
            • 0 Attachment
              > I've been making the assertion over the last couple months that
              what
              > traditional analysts are doing overlaps to a large degree with
              what
              > UCD folks do. I'd be curious if others agree.

              [snip]

              > And finally, can anyone tell any stories about how they've
              effectively
              > [or ineffectively] combined analysts and UCD people?

              Jeff,

              I agreee that there is a lot of overlap but as Kay said, a lot of
              the foundational assumptions are different.

              What's maddening is that the goals of the analyst and UX person
              are similar, the differences in assumptions are rather subtle,
              and the tools similar.

              Witness the thread last year on use cases that Alistair and I
              participated in. It took a long time to work out the similarities
              and distinctions between the narrative tools he calls Use Cases,
              and the one I call Scenarios. And frankly, a few months later,
              I've still got a pretty slippery grasp on the subject.

              Now, a story:

              On my current project, I'm working with a team that is building a
              supply-chain management application. The application will be
              used by an organization of 500+ people, working in a global
              sourcing operation. The team (composed of 6 outside business
              analysts, 6 inside business analysts and user representatives, 3
              inside technology analysts, and a large vendor team with
              expertise in this business area) worked for 8 months producing
              functional spec documents. When they saw the first builds coming
              in from the development team, they realized they needed someone
              to help with UI design, and called me in.

              Here's what I found: The team has completed about 10 functional
              spec documents, covering 10 of the 20 modules of the system. Each
              spec doc is about 80 pages long. Each contains use cases,
              business rules, and detailed field definitions. They are detailed
              and carefully considered documents. But they're not enough.

              Some observations:

              1. The functional specs have no drawings in them. They are text
              documents, with long paragraphs, complex indented bulleted lists,
              and long multi-page tables. Thus to understand the spec each
              reader must work hard to visualization the system in his or her
              head.

              2. The specs describe *the way the team wants the software to
              work* rather than the business problem to solve. In other words,
              the specs are not problem descriptions, ("requirements"
              documents) but solution descriptions. To describe a solution,
              one has to envision a solution, which is what this team did, but:
              -- they embodied their vision in text, not pictures
              -- the visioning is thus implicit, not explicit.
              -- There is no way to be certain that anyone was envisioning the
              same thing.

              3. Some of the specs have been written by analysts with a
              background in software, but others are written by business
              experts. Some have good visualization skills, some don't.
              Regardless, none are experts in visualizing software Uis, so each
              imagined certain functions working in certain ways. Some way
              database tables. Some saw the relationships between objects. Some
              saw Excel. Some saw SAP. Regardless of the relative visualization
              skills of each reader, there is a high probability that none will
              be visualizing the same thing.

              Conclusion: This team created and documented a design, but had no
              designer working to visualize that design--to turn the abstract
              concrete. Futhermore, they didn't think they needed one! It
              wasn't until they saw the project starting to head south that
              they realized they had to augment their team.

              So how does this tie back to Jeff's original point?

              The analysis team did excellent work, but they were missing an
              entire "dimension" of specification. Without a visual channel,
              the specs were incomplete, and thus unworkable. I couldn't have
              done my work without the analysis in place, but if I had come on
              early, my needs would have changed the structure of the analysis.
              We probably would have covered the same material--and perhaps
              made most of the same decisions, but we would have organized the
              work and the work product very differently, and we would have
              saved a lot of wasted effort. I think the reverse is true as
              well--if I had been working on the problem for eight months
              without "traditional analysis", I would have missed a dimension
              of specification, and would have had to go back, restructure, and
              re-spec. (But I never would have gotten 8 months down the road
              first ;-)

              JS
            • Chris
              Hmmm... Been my experience that documents and artifacts are communication channels geared to a particular audience... That it is an agreement of what is to be
              Message 6 of 26 , Feb 3, 2005
              • 0 Attachment
                Hmmm... Been my experience that documents and artifacts are communication channels geared to a particular audience... That it is an agreement of what is to be done. If I were to write something for the CEO, it would look very different than if it was for a programmer. Even if I was conveying the same information. Sometimes verbal works better than written to

                -----Original Message-----
                From: "Joshua Seiden" <joshseiden@...>
                Date: Wed, 2 Feb 2005 23:18:24
                To:<agile-usability@yahoogroups.com>
                Subject: RE: [agile-usability] user centered design overlaps with traditional analysis?



                > I've been making the assertion over the last couple months that
                what
                > traditional analysts are doing overlaps to a large degree with
                what
                > UCD folks do. I'd be curious if others agree.

                [snip]

                > And finally, can anyone tell any stories about how they've
                effectively
                > [or ineffectively] combined analysts and UCD people?

                Jeff,

                I agreee that there is a lot of overlap but as Kay said, a lot of
                the foundational assumptions are different.

                What's maddening is that the goals of the analyst and UX person
                are similar, the differences in assumptions are rather subtle,
                and the tools similar.

                Witness the thread last year on use cases that Alistair and I
                participated in. It took a long time to work out the similarities
                and distinctions between the narrative tools he calls Use Cases,
                and the one I call Scenarios. And frankly, a few months later,
                I've still got a pretty slippery grasp on the subject.

                Now, a story:

                On my current project, I'm working with a team that is building a
                supply-chain management application. The application will be
                used by an organization of 500+ people, working in a global
                sourcing operation. The team (composed of 6 outside business
                analysts, 6 inside business analysts and user representatives, 3
                inside technology analysts, and a large vendor team with
                expertise in this business area) worked for 8 months producing
                functional spec documents. When they saw the first builds coming
                in from the development team, they realized they needed someone
                to help with UI design, and called me in.

                Here's what I found: The team has completed about 10 functional
                spec documents, covering 10 of the 20 modules of the system. Each
                spec doc is about 80 pages long. Each contains use cases,
                business rules, and detailed field definitions. They are detailed
                and carefully considered documents. But they're not enough.

                Some observations:

                1. The functional specs have no drawings in them. They are text
                documents, with long paragraphs, complex indented bulleted lists,
                and long multi-page tables. Thus to understand the spec each
                reader must work hard to visualization the system in his or her
                head.

                2. The specs describe *the way the team wants the software to
                work* rather than the business problem to solve. In other words,
                the specs are not problem descriptions, ("requirements"
                documents) but solution descriptions. To describe a solution,
                one has to envision a solution, which is what this team did, but:
                -- they embodied their vision in text, not pictures
                -- the visioning is thus implicit, not explicit.
                -- There is no way to be certain that anyone was envisioning the
                same thing.

                3. Some of the specs have been written by analysts with a
                background in software, but others are written by business
                experts. Some have good visualization skills, some don't.
                Regardless, none are experts in visualizing software Uis, so each
                imagined certain functions working in certain ways. Some way
                database tables. Some saw the relationships between objects. Some
                saw Excel. Some saw SAP. Regardless of the relative visualization
                skills of each reader, there is a high probability that none will
                be visualizing the same thing.

                Conclusion: This team created and documented a design, but had no
                designer working to visualize that design--to turn the abstract
                concrete. Futhermore, they didn't think they needed one! It
                wasn't until they saw the project starting to head south that
                they realized they had to augment their team.

                So how does this tie back to Jeff's original point?

                The analysis team did excellent work, but they were missing an
                entire "dimension" of specification. Without a visual channel,
                the specs were incomplete, and thus unworkable. I couldn't have
                done my work without the analysis in place, but if I had come on
                early, my needs would have changed the structure of the analysis.
                We probably would have covered the same material--and perhaps
                made most of the same decisions, but we would have organized the
                work and the work product very differently, and we would have
                saved a lot of wasted effort. I think the reverse is true as
                well--if I had been working on the problem for eight months
                without "traditional analysis", I would have missed a dimension
                of specification, and would have had to go back, restructure, and
                re-spec. (But I never would have gotten 8 months down the road
                first ;-)

                JS









                Yahoo! Groups Links









                Sent wirelessly via BlackBerry from T-Mobile.
              • Jeff Patton
                ... wrote: ...with in the course of their use of the product. IME, the traditional analyst assumes a product and wants to start by
                Message 7 of 26 , Feb 3, 2005
                • 0 Attachment
                  --- In agile-usability@yahoogroups.com, Kay Burnett
                  <kayburnett2002@y...> wrote:
                  <snip>
                  ...with in the course of their use of the product. IME, the
                  traditional analyst assumes a product and wants to start by defining
                  features and functions which makes me uncomfortable until I can know
                  something about the people involved. Once the effort gets underway,
                  there is overlap in the analysis of available information. It is just
                  that the starting places are different -- and this, in the long run,
                  is a BIG difference.
                  </snip>

                  That "starting by describing the features and functions of the
                  product" thing is the part that makes me nervous for a couple
                  reasons. I've observed that among folks engaged in analyst type
                  activities that the idea of looking back and doing some work to
                  understand the users of the system and their goals is usually thought
                  of as adding more work onto their already full plate. But what
                  concerns me more, is the plate is full describing, in too much
                  detail, a hypothetical piece of software - described without
                  understanding of how and why it would be used.

                  But, I'm venting. I'm hoping it only seems that way to me. I'm
                  hoping there are activities that analysts are engaged in that overlap
                  with the type of user info gathering done by some UCD approach. If I
                  could identify those, place emphasis on them, and combine them with
                  some UCD techniques, I think we'd all come out ahead.

                  thanks Kay for your post!

                  -Jeff
                • Jeff Patton
                  ... wrote: Thanks Josh, this is a great story - ... In your story you describe what the analysts produced as a design specification - one
                  Message 8 of 26 , Feb 3, 2005
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, "Joshua Seiden"
                    <joshseiden@y...> wrote:

                    Thanks Josh, this is a great story -

                    > The analysis team did excellent work, but they were missing an
                    > entire "dimension" of specification. Without a visual channel,
                    > the specs were incomplete,

                    In your story you describe what the analysts produced as a design
                    specification - one missing a visual channel. I wonder if you think
                    the design was an appropriate one? I suspect to help this company
                    out that you had to backtrack a little and learn about about the
                    people using the software and what they were trying to accomplish by
                    doing so. Is that true? If so, how was that effort met? Did you
                    find any surprises doing that? Was there functionality designed into
                    the spec that wasn't needed? Was there functionality left out of the
                    spec that was? And, finally, assuming some of that stuff whas true,
                    giving bad news about an expensive-to-create design spec usually
                    results in the death of a messenger. Assuming some of that went on,
                    how was your resulting advice met?

                    Thanks again for the post.

                    -Jeff
                  • Chris
                    Accidentially sent it out. To finish my thought... Sometimes verbal is better than written. It depends. I saw artifacts hinder a project in terms of
                    Message 9 of 26 , Feb 3, 2005
                    • 0 Attachment
                      Accidentially sent it out.

                      To finish my thought...

                      Sometimes verbal is better than written. It depends. I saw artifacts hinder a project in terms of productivity, infighting and politics. Or the process was to deliver artifacts, not value.

                      Found things usually don't fail from a missing artifact. Usually because of communication - uncontrolled or lack of.

                      -----Original Message-----
                      From: "Chris" <chris@...>
                      Date: Thu, 3 Feb 2005 14:47:45
                      To:agile-usability@yahoogroups.com
                      Subject: Re: [agile-usability] user centered design overlaps with traditional analysis?


                      Hmmm... Been my experience that documents and artifacts are communication channels geared to a particular audience... That it is an agreement of what is to be done. If I were to write something for the CEO, it would look very different than if it was for a programmer. Even if I was conveying the same information. Sometimes verbal works better than written to

                      -----Original Message-----
                      From: "Joshua Seiden" <joshseiden@...>
                      Date: Wed, 2 Feb 2005 23:18:24
                      To:<agile-usability@yahoogroups.com>
                      Subject: RE: [agile-usability] user centered design overlaps with traditional analysis?



                      > I've been making the assertion over the last couple months that
                      what
                      > traditional analysts are doing overlaps to a large degree with
                      what
                      > UCD folks do. I'd be curious if others agree.

                      [snip]

                      > And finally, can anyone tell any stories about how they've
                      effectively
                      > [or ineffectively] combined analysts and UCD people?

                      Jeff,

                      I agreee that there is a lot of overlap but as Kay said, a lot of
                      the foundational assumptions are different.

                      What's maddening is that the goals of the analyst and UX person
                      are similar, the differences in assumptions are rather subtle,
                      and the tools similar.

                      Witness the thread last year on use cases that Alistair and I
                      participated in. It took a long time to work out the similarities
                      and distinctions between the narrative tools he calls Use Cases,
                      and the one I call Scenarios. And frankly, a few months later,
                      I've still got a pretty slippery grasp on the subject.

                      Now, a story:

                      On my current project, I'm working with a team that is building a
                      supply-chain management application. The application will be
                      used by an organization of 500+ people, working in a global
                      sourcing operation. The team (composed of 6 outside business
                      analysts, 6 inside business analysts and user representatives, 3
                      inside technology analysts, and a large vendor team with
                      expertise in this business area) worked for 8 months producing
                      functional spec documents. When they saw the first builds coming
                      in from the development team, they realized they needed someone
                      to help with UI design, and called me in.

                      Here's what I found: The team has completed about 10 functional
                      spec documents, covering 10 of the 20 modules of the system. Each
                      spec doc is about 80 pages long. Each contains use cases,
                      business rules, and detailed field definitions. They are detailed
                      and carefully considered documents. But they're not enough.

                      Some observations:

                      1. The functional specs have no drawings in them. They are text
                      documents, with long paragraphs, complex indented bulleted lists,
                      and long multi-page tables. Thus to understand the spec each
                      reader must work hard to visualization the system in his or her
                      head.

                      2. The specs describe *the way the team wants the software to
                      work* rather than the business problem to solve. In other words,
                      the specs are not problem descriptions, ("requirements"
                      documents) but solution descriptions. To describe a solution,
                      one has to envision a solution, which is what this team did, but:
                      -- they embodied their vision in text, not pictures
                      -- the visioning is thus implicit, not explicit.
                      -- There is no way to be certain that anyone was envisioning the
                      same thing.

                      3. Some of the specs have been written by analysts with a
                      background in software, but others are written by business
                      experts. Some have good visualization skills, some don't.
                      Regardless, none are experts in visualizing software Uis, so each
                      imagined certain functions working in certain ways. Some way
                      database tables. Some saw the relationships between objects. Some
                      saw Excel. Some saw SAP. Regardless of the relative visualization
                      skills of each reader, there is a high probability that none will
                      be visualizing the same thing.

                      Conclusion: This team created and documented a design, but had no
                      designer working to visualize that design--to turn the abstract
                      concrete. Futhermore, they didn't think they needed one! It
                      wasn't until they saw the project starting to head south that
                      they realized they had to augment their team.

                      So how does this tie back to Jeff's original point?

                      The analysis team did excellent work, but they were missing an
                      entire "dimension" of specification. Without a visual channel,
                      the specs were incomplete, and thus unworkable. I couldn't have
                      done my work without the analysis in place, but if I had come on
                      early, my needs would have changed the structure of the analysis.
                      We probably would have covered the same material--and perhaps
                      made most of the same decisions, but we would have organized the
                      work and the work product very differently, and we would have
                      saved a lot of wasted effort. I think the reverse is true as
                      well--if I had been working on the problem for eight months
                      without "traditional analysis", I would have missed a dimension
                      of specification, and would have had to go back, restructure, and
                      re-spec. (But I never would have gotten 8 months down the road
                      first ;-)

                      JS









                      Yahoo! Groups Links









                      Sent wirelessly via BlackBerry from T-Mobile.



                      Yahoo! Groups Links









                      Sent wirelessly via BlackBerry from T-Mobile.
                    • Jeff Patton
                      ... communication channels geared to a particular audience... Maybe that s a good argument for a one size doesn t fit all rule. Spending a lot of time and
                      Message 10 of 26 , Feb 3, 2005
                      • 0 Attachment
                        --- In agile-usability@yahoogroups.com, "Chris" <chris@p...> wrote:
                        > Hmmm... Been my experience that documents and artifacts are
                        communication channels geared to a particular audience...

                        Maybe that's a good argument for a "one size doesn't fit all" rule.
                        Spending a lot of time and money crafting a single way to communicate
                        information seems like a risky notion.


                        -Jeff
                      • Josh Seiden
                        Well yes, the point is about communication, not about artifacts. The fact that the artifacts were missing an entire dimension of communication is a symptom of
                        Message 11 of 26 , Feb 3, 2005
                        • 0 Attachment
                          Well yes, the point is about communication, not about
                          artifacts.

                          The fact that the artifacts were missing an entire
                          dimension of communication is a symptom of a
                          communication problem.

                          But paradoxically, if the team had felt that the
                          artifacts required a visual channel, then they would
                          have had to think about the problem in visual
                          terms--and would have been forced to think through the
                          problem more completely.

                          JS

                          --- Chris <chris@...> wrote:

                          >
                          > Accidentially sent it out.
                          >
                          > To finish my thought...
                          >
                          > Sometimes verbal is better than written. It depends.
                          > I saw artifacts hinder a project in terms of
                          > productivity, infighting and politics. Or the
                          > process was to deliver artifacts, not value.
                          >
                          > Found things usually don't fail from a missing
                          > artifact. Usually because of communication -
                          > uncontrolled or lack of.
                          >
                          > -----Original Message-----
                          > From: "Chris" <chris@...>
                          > Date: Thu, 3 Feb 2005 14:47:45
                          > To:agile-usability@yahoogroups.com
                          > Subject: Re: [agile-usability] user centered design
                          > overlaps with traditional analysis?
                          >
                          >
                          > Hmmm... Been my experience that documents and
                          > artifacts are communication channels geared to a
                          > particular audience... That it is an agreement of
                          > what is to be done. If I were to write something for
                          > the CEO, it would look very different than if it was
                          > for a programmer. Even if I was conveying the same
                          > information. Sometimes verbal works better than
                          > written to
                          >
                          > -----Original Message-----
                          > From: "Joshua Seiden" <joshseiden@...>
                          > Date: Wed, 2 Feb 2005 23:18:24
                          > To:<agile-usability@yahoogroups.com>
                          > Subject: RE: [agile-usability] user centered design
                          > overlaps with traditional analysis?
                          >
                          >
                          >
                          > > I've been making the assertion over the last
                          > couple months that
                          > what
                          > > traditional analysts are doing overlaps to a large
                          > degree with
                          > what
                          > > UCD folks do. I'd be curious if others agree.
                          >
                          > [snip]
                          >
                          > > And finally, can anyone tell any stories about how
                          > they've
                          > effectively
                          > > [or ineffectively] combined analysts and UCD
                          > people?
                          >
                          > Jeff,
                          >
                          > I agreee that there is a lot of overlap but as Kay
                          > said, a lot of
                          > the foundational assumptions are different.
                          >
                          > What's maddening is that the goals of the analyst
                          > and UX person
                          > are similar, the differences in assumptions are
                          > rather subtle,
                          > and the tools similar.
                          >
                          > Witness the thread last year on use cases that
                          > Alistair and I
                          > participated in. It took a long time to work out the
                          > similarities
                          > and distinctions between the narrative tools he
                          > calls Use Cases,
                          > and the one I call Scenarios. And frankly, a few
                          > months later,
                          > I've still got a pretty slippery grasp on the
                          > subject.
                          >
                          > Now, a story:
                          >
                          > On my current project, I'm working with a team that
                          > is building a
                          > supply-chain management application. The application
                          > will be
                          > used by an organization of 500+ people, working in a
                          > global
                          > sourcing operation. The team (composed of 6 outside
                          > business
                          > analysts, 6 inside business analysts and user
                          > representatives, 3
                          > inside technology analysts, and a large vendor team
                          > with
                          > expertise in this business area) worked for 8 months
                          > producing
                          > functional spec documents. When they saw the first
                          > builds coming
                          > in from the development team, they realized they
                          > needed someone
                          > to help with UI design, and called me in.
                          >
                          > Here's what I found: The team has completed about 10
                          > functional
                          > spec documents, covering 10 of the 20 modules of the
                          > system. Each
                          > spec doc is about 80 pages long. Each contains use
                          > cases,
                          > business rules, and detailed field definitions. They
                          > are detailed
                          > and carefully considered documents. But they're not
                          > enough.
                          >
                          > Some observations:
                          >
                          > 1. The functional specs have no drawings in them.
                          > They are text
                          > documents, with long paragraphs, complex indented
                          > bulleted lists,
                          > and long multi-page tables. Thus to understand the
                          > spec each
                          > reader must work hard to visualization the system in
                          > his or her
                          > head.
                          >
                          > 2. The specs describe *the way the team wants the
                          > software to
                          > work* rather than the business problem to solve. In
                          > other words,
                          > the specs are not problem descriptions,
                          > ("requirements"
                          > documents) but solution descriptions. To describe a
                          > solution,
                          > one has to envision a solution, which is what this
                          > team did, but:
                          > -- they embodied their vision in text, not pictures
                          > -- the visioning is thus implicit, not explicit.
                          > -- There is no way to be certain that anyone was
                          > envisioning the
                          > same thing.
                          >
                          > 3. Some of the specs have been written by analysts
                          > with a
                          > background in software, but others are written by
                          > business
                          > experts. Some have good visualization skills, some
                          > don't.
                          > Regardless, none are experts in visualizing software
                          > Uis, so each
                          > imagined certain functions working in certain ways.
                          > Some way
                          > database tables. Some saw the relationships between
                          > objects. Some
                          > saw Excel. Some saw SAP. Regardless of the relative
                          > visualization
                          > skills of each reader, there is a high probability
                          > that none will
                          > be visualizing the same thing.
                          >
                          > Conclusion: This team created and documented a
                          > design, but had no
                          > designer working to visualize that design--to turn
                          > the abstract
                          > concrete. Futhermore, they didn't think they needed
                          > one! It
                          > wasn't until they saw the project starting to head
                          > south that
                          > they realized they had to augment their team.
                          >
                          > So how does this tie back to Jeff's original point?
                          >
                          > The analysis team did excellent work, but they were
                          > missing an
                          > entire "dimension" of specification. Without a
                          > visual channel,
                          > the specs were incomplete, and thus unworkable. I
                          > couldn't have
                          > done my work without the analysis in place, but if I
                          > had come on
                          > early, my needs would have changed the structure of
                          > the analysis.
                          > We probably would have covered the same
                          > material--and perhaps
                          > made most of the same decisions, but we would have
                          > organized the
                          > work and the work product very differently, and we
                          > would have
                          > saved a lot of wasted effort. I think the reverse is
                          > true as
                          > well--if I had been working on the problem for eight
                          > months
                          > without "traditional analysis", I would have missed
                          > a dimension
                          > of specification, and would have had to go back,
                          > restructure, and
                          > re-spec. (But I never would have gotten 8 months
                          > down the road
                          > first ;-)
                          >
                          > JS
                          >
                          >
                          >
                          === message truncated ===
                        • Jeff Patton
                          ... artifacts hinder a project in terms of productivity, infighting and politics. Or the process was to deliver artifacts, not value. ... because of
                          Message 12 of 26 , Feb 3, 2005
                          • 0 Attachment
                            --- In agile-usability@yahoogroups.com, "Chris" <chris@p...> wrote:
                            > Accidentially sent it out.
                            >
                            > To finish my thought...
                            >
                            > Sometimes verbal is better than written. It depends. I saw
                            artifacts hinder a project in terms of productivity, infighting and
                            politics. Or the process was to deliver artifacts, not value.
                            >
                            > Found things usually don't fail from a missing artifact. Usually
                            because of communication - uncontrolled or lack of.

                            Glad you finished your thought. Couldn't agree more. On my current
                            agile project we document stuff we know about a story and post it on
                            a wiki. Our expert users sit feet from us. We've noticed a problem
                            where the expert user finds out an important piece of information,
                            then updates the document to include it. Now folks have already read
                            the document, and don't think to scan it for changes/revisions. At
                            the end of the iteration when we've missed an important detail, and
                            can see it right there in the document, our first thought is "why
                            didn't we just talk about this?" The artifact was present - but gave
                            folks a false sense of security.

                            thanks for your post.

                            -Jeff
                          • Chris
                            Sometimes a visual channel is not appropriate. Depends again on the audience. Myself I prefer visual. Seen others more productive with written word. It depends
                            Message 13 of 26 , Feb 3, 2005
                            • 0 Attachment
                              Sometimes a visual channel is not appropriate. Depends again on the audience. Myself I prefer visual. Seen others more productive with written word. It depends on a person's logical systems and beliefs. The common problem is information complexity and organization.

                              -----Original Message-----
                              From: Josh Seiden <joshseiden@...>
                              Date: Thu, 3 Feb 2005 07:36:50
                              To:agile-usability@yahoogroups.com
                              Subject: Re: [agile-usability] user centered design overlaps with traditional analysis?


                              Well yes, the point is about communication, not about
                              artifacts.

                              The fact that the artifacts were missing an entire
                              dimension of communication is a symptom of a
                              communication problem.

                              But paradoxically, if the team had felt that the
                              artifacts required a visual channel, then they would
                              have had to think about the problem in visual
                              terms--and would have been forced to think through the
                              problem more completely.

                              JS

                              --- Chris <chris@...> wrote:

                              >
                              > Accidentially sent it out.
                              >
                              > To finish my thought...
                              >
                              > Sometimes verbal is better than written. It depends.
                              > I saw artifacts hinder a project in terms of
                              > productivity, infighting and politics. Or the
                              > process was to deliver artifacts, not value.
                              >
                              > Found things usually don't fail from a missing
                              > artifact. Usually because of communication -
                              > uncontrolled or lack of.
                              >
                              > -----Original Message-----
                              > From: "Chris" <chris@...>
                              > Date: Thu, 3 Feb 2005 14:47:45
                              > To:agile-usability@yahoogroups.com
                              > Subject: Re: [agile-usability] user centered design
                              > overlaps with traditional analysis?
                              >
                              >
                              > Hmmm... Been my experience that documents and
                              > artifacts are communication channels geared to a
                              > particular audience... That it is an agreement of
                              > what is to be done. If I were to write something for
                              > the CEO, it would look very different than if it was
                              > for a programmer. Even if I was conveying the same
                              > information. Sometimes verbal works better than
                              > written to
                              >
                              > -----Original Message-----
                              > From: "Joshua Seiden" <joshseiden@...>
                              > Date: Wed, 2 Feb 2005 23:18:24
                              > To:<agile-usability@yahoogroups.com>
                              > Subject: RE: [agile-usability] user centered design
                              > overlaps with traditional analysis?
                              >
                              >
                              >
                              > > I've been making the assertion over the last
                              > couple months that
                              > what
                              > > traditional analysts are doing overlaps to a large
                              > degree with
                              > what
                              > > UCD folks do. I'd be curious if others agree.
                              >
                              > [snip]
                              >
                              > > And finally, can anyone tell any stories about how
                              > they've
                              > effectively
                              > > [or ineffectively] combined analysts and UCD
                              > people?
                              >
                              > Jeff,
                              >
                              > I agreee that there is a lot of overlap but as Kay
                              > said, a lot of
                              > the foundational assumptions are different.
                              >
                              > What's maddening is that the goals of the analyst
                              > and UX person
                              > are similar, the differences in assumptions are
                              > rather subtle,
                              > and the tools similar.
                              >
                              > Witness the thread last year on use cases that
                              > Alistair and I
                              > participated in. It took a long time to work out the
                              > similarities
                              > and distinctions between the narrative tools he
                              > calls Use Cases,
                              > and the one I call Scenarios. And frankly, a few
                              > months later,
                              > I've still got a pretty slippery grasp on the
                              > subject.
                              >
                              > Now, a story:
                              >
                              > On my current project, I'm working with a team that
                              > is building a
                              > supply-chain management application. The application
                              > will be
                              > used by an organization of 500+ people, working in a
                              > global
                              > sourcing operation. The team (composed of 6 outside
                              > business
                              > analysts, 6 inside business analysts and user
                              > representatives, 3
                              > inside technology analysts, and a large vendor team
                              > with
                              > expertise in this business area) worked for 8 months
                              > producing
                              > functional spec documents. When they saw the first
                              > builds coming
                              > in from the development team, they realized they
                              > needed someone
                              > to help with UI design, and called me in.
                              >
                              > Here's what I found: The team has completed about 10
                              > functional
                              > spec documents, covering 10 of the 20 modules of the
                              > system. Each
                              > spec doc is about 80 pages long. Each contains use
                              > cases,
                              > business rules, and detailed field definitions. They
                              > are detailed
                              > and carefully considered documents. But they're not
                              > enough.
                              >
                              > Some observations:
                              >
                              > 1. The functional specs have no drawings in them.
                              > They are text
                              > documents, with long paragraphs, complex indented
                              > bulleted lists,
                              > and long multi-page tables. Thus to understand the
                              > spec each
                              > reader must work hard to visualization the system in
                              > his or her
                              > head.
                              >
                              > 2. The specs describe *the way the team wants the
                              > software to
                              > work* rather than the business problem to solve. In
                              > other words,
                              > the specs are not problem descriptions,
                              > ("requirements"
                              > documents) but solution descriptions. To describe a
                              > solution,
                              > one has to envision a solution, which is what this
                              > team did, but:
                              > -- they embodied their vision in text, not pictures
                              > -- the visioning is thus implicit, not explicit.
                              > -- There is no way to be certain that anyone was
                              > envisioning the
                              > same thing.
                              >
                              > 3. Some of the specs have been written by analysts
                              > with a
                              > background in software, but others are written by
                              > business
                              > experts. Some have good visualization skills, some
                              > don't.
                              > Regardless, none are experts in visualizing software
                              > Uis, so each
                              > imagined certain functions working in certain ways.
                              > Some way
                              > database tables. Some saw the relationships between
                              > objects. Some
                              > saw Excel. Some saw SAP. Regardless of the relative
                              > visualization
                              > skills of each reader, there is a high probability
                              > that none will
                              > be visualizing the same thing.
                              >
                              > Conclusion: This team created and documented a
                              > design, but had no
                              > designer working to visualize that design--to turn
                              > the abstract
                              > concrete. Futhermore, they didn't think they needed
                              > one! It
                              > wasn't until they saw the project starting to head
                              > south that
                              > they realized they had to augment their team.
                              >
                              > So how does this tie back to Jeff's original point?
                              >
                              > The analysis team did excellent work, but they were
                              > missing an
                              > entire "dimension" of specification. Without a
                              > visual channel,
                              > the specs were incomplete, and thus unworkable. I
                              > couldn't have
                              > done my work without the analysis in place, but if I
                              > had come on
                              > early, my needs would have changed the structure of
                              > the analysis.
                              > We probably would have covered the same
                              > material--and perhaps
                              > made most of the same decisions, but we would have
                              > organized the
                              > work and the work product very differently, and we
                              > would have
                              > saved a lot of wasted effort. I think the reverse is
                              > true as
                              > well--if I had been working on the problem for eight
                              > months
                              > without "traditional analysis", I would have missed
                              > a dimension
                              > of specification, and would have had to go back,
                              > restructure, and
                              > re-spec. (But I never would have gotten 8 months
                              > down the road
                              > first ;-)
                              >
                              > JS
                              >
                              >
                              >
                              === message truncated ===




                              Yahoo! Groups Links









                              Sent wirelessly via BlackBerry from T-Mobile.
                            • Josh Seiden
                              ... The big problem is that it was not complete. Most of the work that was there was appropriate. 5-10 percent was misguided because it made incorrect
                              Message 14 of 26 , Feb 3, 2005
                              • 0 Attachment
                                >
                                > In your story you describe what the analysts
                                > produced as a design
                                > specification - one missing a visual channel. I
                                > wonder if you think
                                > the design was an appropriate one?

                                The big problem is that it was not complete. Most of
                                the work that was there was appropriate. 5-10 percent
                                was misguided because it made incorrect assumptions
                                about the user interface.

                                But because it did not specify a user interface, it
                                left open a giant risk factor.

                                > I suspect to
                                > help this company
                                > out that you had to backtrack a little and learn
                                > about about the
                                > people using the software and what they were trying
                                > to accomplish by
                                > doing so. Is that true? If so, how was that effort
                                > met? Did you
                                > find any surprises doing that?

                                I did have to backtrack, and I'm still doing it. But
                                the timeline is such that not much backtracking is
                                possible.

                                The team include a great many users, ex-users, and
                                subject matter experts, so I am reviewing the work
                                with them.

                                In this case though, it's not that the team didn't ask
                                the right questions or gather the right data. They
                                just did a different form of analysis that I needed to
                                do.

                                So my "backtracking" is really a matter of reviewing
                                the work with them and performing a different kind of
                                analysis on the data.

                                > Was there
                                > functionality designed into
                                > the spec that wasn't needed? Was there
                                > functionality left out of the
                                > spec that was?

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

                                My starting place has been to separate out the
                                probable from the possible.

                                > And, finally, assuming some of that
                                > stuff whas true,
                                > giving bad news about an expensive-to-create design
                                > spec usually
                                > results in the death of a messenger. Assuming some
                                > of that went on,
                                > how was your resulting advice met?

                                Well, the project leaders have been very receptive to
                                my work. They saw the first UIs coming in, and saw the
                                future of the project suddenly turn black. They have
                                spent a lot of time and money on this and are willing
                                to spend a little more to ensure success.

                                One measure of success: the executive sponsors saw my
                                first design proposals, and demanded a *project delay*
                                in order to ensure that the improved UI designs were
                                included in the first release. The sponsors went to
                                the well for a very large dollar amount to fund the
                                extra three months of development work that this
                                change requires.

                                > Thanks again for the post.

                                Thanks again for the list.
                              • Sue Heim
                                ... 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
                                Message 15 of 26 , Feb 3, 2005
                                • 0 Attachment
                                  Jeff:
                                  >Glad you finished your thought. Couldn't agree more. On my current
                                  >agile project we document stuff we know about a story and post it on
                                  >a wiki. Our expert users sit feet from us. We've noticed a problem
                                  >where the expert user finds out an important piece of information,
                                  >then updates the document to include it. Now folks have already read
                                  >the document, and don't think to scan it for changes/revisions. At
                                  >the end of the iteration when we've missed an important detail, and
                                  >can see it right there in the document, our first thought is "why
                                  >didn't we just talk about this?" The artifact was present - but gave
                                  >folks a false sense of security.

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

                                  ...sue
                                • Jade Ohlhauser
                                  I like this conversation because I ve found spec documentation to be the most important design & development tool I have. And I try to use *agile documentation
                                  Message 16 of 26 , Feb 3, 2005
                                  • 0 Attachment
                                    I like this conversation because I've found spec documentation to be the most important design & development tool I have. And I try to use *agile documentation creation*. I think it would be disastrous to simply take a design team, spend x months writing a complete spec down to the finest detail, then "throw it over the wall" to the developers. Our specs grow along with the development the code (in fact we keep them in source control).
                                     
                                    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. However, where there is a lack of details or an unknown make sure it is clearly identified. This way we can get started reviewing the spec and talking about the feature sooner. With the unknowns or potential issues flagged it means they can't "go unspoken" until the end of development and blow up. As development goes on the spec also starts "filling in"
                                     
                                    For me I think the most valuable things of written specs are they force you to think of the complete solution and they remove ambiguity.
                                     
                                    Some things I've learned about good specs:
                                     
                                    1. Every feature/module starts out with a 1 sentence summary. That headline style introduction is then followed by a 1 paragraph summary. It's important to ease people into the details like this, as I think Joshua knows all too well :)
                                     
                                    2. In addition to the summary, is paragraph (or so) summarizing the business need for the feature. It's here where I defend (in brief) why this feature should be built including mentioning specific customers if applicable. Now you could argue that developers don't need this information, but I've found it to be valuable for everyone to know the business influences. The same applies to the next section... 
                                     
                                    3. Every feature also includes a sentence (or so) that says what the goal of this feature is. What is the user trying to accomplish? Of course this will be covered extensively in the meat of the spec, it's good to ease people in and provide them with the big picture view. This also gives people the challenge the spec, i.e. does the feature as spec meet the goal it says it's supposed to.
                                     
                                    4. Those first 3 may seem to overlap, but that's OK. Giving people a little extra info is far better than not giving them enough or expecting them to build a visual model of the feature from details only. Imagine trying to visualize a new building from blueprints alone. It's possible, but how much easier is it when you also get a little cardboard model. Also, the above 3 each approach the overview of the feature from a different angle: the functionality, the reason for building it, and the end goal of the user.
                                     
                                    5. Each spec document must have 1 author only. Many people will contribute, but 1 person needs to own the document and control the addition, editing, and removal of content.
                                     
                                    6. There shouldn't be any rigid structure or formatting rules. For our specs, the summary, need, and goal are required, but they are followed by the large "details" section which can be any format, allowing the author to do what's best for the given feature. We do have a set style template everyone uses for the fonts and such, but we don't impose any rules on things like how deep to nest x type of list or you have to include a list of every user type, etc. Every feature has unique requirements so this gives the author the freedom to decide what's best. It also makes the writing effort about the content, not the document itself.
                                     
                                    7. It's OK to be informal or even attempt to be funny. This makes the spec easier to read and easier to write.
                                     
                                    8. When there is a long list of variables or something, it should be move to an appendix at the end of the document. This helps keep the reading flow. The same idea applies to using footnotes where applicable for off-topic notes, term definitions, etc.
                                     
                                     
                                    Our specs:
                                    We have various functional spec Word documents, each containing several features. Each one of these documents has a matching technical spec document. These documents reside in our StarTeam source control. Along with the functional specs there are page sketches (using less now) and HTML mockups (using more now).
                                     
                                    Jade Ohlhauser
                                    Product Manager
                                    RPM Software                          
                                    www.rpmsoftware.com 403-265-6727
                                     


                                    From: Chris [mailto:chris@...]
                                    Sent: Thursday, February 03, 2005 8:28 AM
                                    To: agile-usability@yahoogroups.com
                                    Subject: Re: [agile-usability] user centered design overlaps with traditional analysis?

                                    Accidentially sent it out.

                                    To finish my thought...

                                    Sometimes verbal is better than written. It depends. I saw artifacts hinder a project in terms of productivity, infighting and politics. Or the process was to deliver artifacts, not value.

                                    Found things usually don't fail from a missing artifact. Usually because of communication - uncontrolled or lack of.

                                    -----Original Message-----
                                    From: "Chris" <chris@...>
                                    Date: Thu, 3 Feb 2005 14:47:45
                                    To:agile-usability@yahoogroups.com
                                    Subject: Re: [agile-usability] user centered design overlaps with traditional analysis?


                                    Hmmm... Been my experience that documents and artifacts are communication channels geared to a particular audience... That it is an agreement of what is to be done. If I were to write something for the CEO, it would look very different than if it was for a programmer. Even if I was conveying the same information. Sometimes verbal works better than written to

                                    -----Original Message-----
                                    From: "Joshua Seiden" <joshseiden@...>
                                    Date: Wed, 2 Feb 2005 23:18:24
                                    To:<agile-usability@yahoogroups.com>
                                    Subject: RE: [agile-usability] user centered design overlaps with traditional analysis?



                                    >
                                    I've been making the assertion over the last couple months that
                                    what
                                    >
                                    traditional analysts are doing overlaps to a large degree with
                                    what
                                    >
                                    UCD folks do.  I'd be curious if others agree.

                                    [snip]

                                    >
                                    And finally, can anyone tell any stories about how they've
                                    effectively
                                    > [or ineffectively] combined analysts and UCD
                                    people?

                                    Jeff,

                                    I agreee that there is a lot of overlap but as Kay said, a lot of
                                    the foundational assumptions are different.

                                    What's maddening is that the goals of the analyst and UX person
                                    are similar, the differences in assumptions are rather subtle,
                                    and the tools similar.

                                    Witness the thread last year on use cases that Alistair and I
                                    participated in. It took a long time to work out the similarities
                                    and distinctions between the narrative tools he calls Use Cases,
                                    and the one I call Scenarios. And frankly, a few months later,
                                    I've still got a pretty slippery grasp on the subject.

                                    Now, a story:

                                    On my current project, I'm working with a team that is building a
                                    supply-chain management application. The application  will be
                                    used by an organization of 500+ people, working in a global
                                    sourcing operation. The team (composed of 6 outside business
                                    analysts, 6 inside business analysts and user representatives, 3
                                    inside technology analysts, and a large vendor team with
                                    expertise in this business area) worked for 8 months producing
                                    functional spec documents. When they saw the first builds coming
                                    in from the development team, they realized they needed someone
                                    to help with UI design, and called me in.

                                    Here's what I found: The team has completed about 10 functional
                                    spec documents, covering 10 of the 20 modules of the system. Each
                                    spec doc is about 80 pages long. Each contains use cases,
                                    business rules, and detailed field definitions. They are detailed
                                    and carefully considered documents. But they're not enough.

                                    Some observations:

                                    1. The functional specs have no drawings in them. They are text
                                    documents, with long paragraphs, complex indented bulleted lists,
                                    and long multi-page tables. Thus to understand the spec each
                                    reader must work hard to visualization the system in his or her
                                    head.

                                    2. The specs describe *the way the team wants the software to
                                    work* rather than the business problem to solve. In other words,
                                    the specs are not problem descriptions, ("requirements"
                                    documents) but solution descriptions.  To describe a solution,
                                    one has to envision a solution, which is what this team did, but:
                                    -- they embodied their vision in text, not pictures
                                    -- the visioning is thus implicit, not explicit.
                                    -- There is no way to be certain that anyone was envisioning the
                                    same thing.

                                    3. Some of the specs have been written by analysts with a
                                    background in software, but others are written by business
                                    experts. Some have good visualization skills, some don't.
                                    Regardless, none are experts in visualizing software Uis, so each
                                    imagined certain functions working in certain ways. Some way
                                    database tables. Some saw the relationships between objects. Some
                                    saw Excel. Some saw SAP. Regardless of the relative visualization
                                    skills of each reader, there is a high probability that none will
                                    be visualizing the same thing.

                                    Conclusion: This team created and documented a design, but had no
                                    designer working to visualize that design--to turn the abstract
                                    concrete. Futhermore, they didn't think they needed one! It
                                    wasn't until they saw the project starting to head south that
                                    they realized they had to augment their team.

                                    So how does this tie back to Jeff's original point?

                                    The analysis team did excellent work, but they were missing an
                                    entire "dimension" of specification. Without a visual channel,
                                    the specs were incomplete, and thus unworkable. I couldn't have
                                    done my work without the analysis in place, but if I had come on
                                    early, my needs would have changed the structure of the analysis.
                                    We probably would have covered the same material--and perhaps
                                    made most of the same decisions, but we would have organized the
                                    work and the work product very differently, and we would have
                                    saved a lot of wasted effort. I think the reverse is true as
                                    well--if I had been working on the problem for eight months
                                    without "traditional analysis", I would have missed a dimension
                                    of specification, and would have had to go back, restructure, and
                                    re-spec. (But I never would have gotten 8 months down the road
                                    first ;-)

                                    JS









                                    Yahoo! Groups Links









                                    Sent wirelessly via BlackBerry from T-Mobile.



                                    Yahoo! Groups Links









                                    Sent wirelessly via BlackBerry from T-Mobile.
                                  • Chris
                                    Agreed. I use risk with priorities to guide efforts. I see change and the impact of change as risks. Putting together a very detailed artifact is a risk at
                                    Message 17 of 26 , Feb 3, 2005
                                    • 0 Attachment
                                      Agreed.

                                      I use risk with priorities to guide efforts. I see change and the impact of change as risks.

                                      Putting together a very detailed artifact is a risk at different levels. Political, business, project survival, etc.

                                      Reducing the risks sets up the environment for success.

                                      -----Original Message-----
                                      From: "Desilets, Alain" <alain.desilets@...>
                                      Date: Thu, 3 Feb 2005 13:28:14
                                      To:"'agile-usability@yahoogroups.com'" <agile-usability@yahoogroups.com>
                                      Subject: RE: [agile-usability] user centered design overlaps with traditio
                                      nal 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



                                      Yahoo! Groups Links
                                      To visit your group on the web, go to:
                                      http://groups.yahoo.com/group/agile-usability/
                                      To unsubscribe from this group, send an email to:
                                      agile-usability-unsubscribe@yahoogroups.com
                                      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                      Sent wirelessly via BlackBerry from T-Mobile.
                                    • Chris
                                      Forgot to mention that this way of thinking is similar to some eastern philosophy. Can t recall which one. ... From: Chris Date: Thu, 3
                                      Message 18 of 26 , Feb 3, 2005
                                      • 0 Attachment
                                        Forgot to mention that this way of thinking is similar to some eastern philosophy. Can't recall which one.

                                        -----Original Message-----
                                        From: "Chris" <chris@...>
                                        Date: Thu, 3 Feb 2005 18:51:18
                                        To:agile-usability@yahoogroups.com
                                        Cc:"Pehura, Urgent" <urgent@...>
                                        Subject: Re: [agile-usability] user centered design overlaps with traditional analysis?

                                        Agreed.

                                        I use risk with priorities to guide efforts. I see change and the impact of change as risks.

                                        Putting together a very detailed artifact is a risk at different levels. Political, business, project survival, etc.

                                        Reducing the risks sets up the environment for success.

                                        -----Original Message-----
                                        From: "Desilets, Alain" <alain.desilets@...>
                                        Date: Thu, 3 Feb 2005 13:28:14
                                        To:"'agile-usability@yahoogroups.com'" <agile-usability@yahoogroups.com>
                                        Subject: RE: [agile-usability] user centered design overlaps with traditio
                                        nal 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



                                        Yahoo! Groups Links
                                        To visit your group on the web, go to:
                                        http://groups.yahoo.com/group/agile-usability/
                                        To unsubscribe from this group, send an email to:
                                        agile-usability-unsubscribe@yahoogroups.com
                                        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                        Sent wirelessly via BlackBerry from T-Mobile.


                                        Yahoo! Groups Links





                                        Sent wirelessly via BlackBerry from T-Mobile.
                                      • 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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.