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

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

Expand Messages
  • 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 1 of 26 , Feb 3, 2005
      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 2 of 26 , Feb 3, 2005
        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 3 of 26 , Feb 3, 2005
          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 4 of 26 , Feb 3, 2005
            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 5 of 26 , Feb 3, 2005
              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 6 of 26 , Feb 10, 2005
                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 7 of 26 , Feb 10, 2005
                  --- 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 8 of 26 , Feb 10, 2005
                    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 9 of 26 , Feb 10, 2005
                      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 10 of 26 , Feb 10, 2005

                        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 11 of 26 , Feb 24, 2005
                          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 12 of 26 , Feb 25, 2005
                            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.