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

Kidnapping users

Expand Messages
  • acockburn@aol.com
    ... I found this an intriguing question and more appropriate for this group. ============================================== Alistair Cockburn Humans and
    Message 1 of 27 , Aug 31, 2005
    • 0 Attachment
      From the XP list: On Tuesday, August 30, 2005, at 9:08:15 PM, Cory Foy wrote:

      > Richard Sheridan of Menlo Innovations recently
      said:

      > "A second problem with kidnapping a user is that the user
      rapidly
      > becomes a "former user."  The Stockholm Syndrome kicks in
      and the kidnap
      > victim begins to identify with their captors.  They
      start to accept the
      > explanations that intuitive interface is simply "too
      hard" to implement.
      >   It doesn't take long before the
      developers have fully brain washed the
      > captive user, and the user begins
      to think of the "computer" as the
      > dominant force in making interface
      decisions. From here it's a slippery
      > slope into the morass of "file
      selection dialogs", "standard user
      > interface widgets from Microsoft"
      and other "standard practices" in
      > building user interface that leave the
      real users saying,  "What were
      > they thinking?"
      >  
      At its core the "kidnap a user" approach is irreparably flawed.  Any
      > users repeatedly exposed to designs during the process of
      software
      > development are unconsciously "tainted" by the process itself.
      > Assumptions become facts, facts become reality, and serious blind
      spots
      > develop.  A screen that is not intuitive at all seems
      intuitive to the
      > "kidnapped user" after they have seen it 100
      times."

      > Is this true? If so, how do you keep this from happening in
      projects you
      > lead/mentor/work on?

      I found this an intriguing question and more appropriate for this group.
       

      ==============================================
       
      Alistair Cockburn
      Humans and Technology

      801.582.3162   |  1814 Ft Douglas Cir |  Salt Lake City, UT 84103
      http://alistair.cockburn.us/   | acockburn@...
       
      ==============================================

      "La perfection est atteinte non quand il ne reste rien a ajouter,
      mais quand il ne reste rien a enlever." (Saint-Exupery)

      "The first thing to build is trust." -- Brad Appleton

      ==============================================

    • Jon Meads
      Alistair , It s important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment
      Message 2 of 27 , Aug 31, 2005
      • 0 Attachment
        Alistair ,
         
        It's important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code behavior to operating environment is just a total black art to the user. When a software engineer says, "It can't be done," that becomes fact for the user. "Gee if it's impossible to use radio buttons here, I guess I'll have to live with check boxes and be careful that I don't make a mistake."
         
        It's been a long time since I have done any coding but, often enough, I will find a programmer who claims it can't be done simply because they haven't figured out how to do it. Add to these, the complaints that "it will take too much work to make that change" and you have good user interfaces being sabotaged to save software engineering time and money at the cost of much greater production usage time and money.
         
        Cheers,
        jon


        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of acockburn@...
        Sent: Wednesday, August 31, 2005 8:21 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] Kidnapping users

        From the XP list: On Tuesday, August 30, 2005, at 9:08:15 PM, Cory Foy wrote:

        > Richard Sheridan of Menlo Innovations recently
        said:

        > "A second problem with kidnapping a user is that the user
        rapidly
        > becomes a "former user."  The Stockholm Syndrome kicks in
        and the kidnap
        > victim begins to identify with their captors.  They
        start to accept the
        > explanations that intuitive interface is simply "too
        hard" to implement.
        >   It doesn't take long before the
        developers have fully brain washed the
        > captive user, and the user begins
        to think of the "computer" as the
        > dominant force in making interface
        decisions. From here it's a slippery
        > slope into the morass of "file
        selection dialogs", "standard user
        > interface widgets from Microsoft"
        and other "standard practices" in
        > building user interface that leave the
        real users saying,  "What were
        > they thinking?"
        >  
        At its core the "kidnap a user" approach is irreparably flawed.  Any
        > users repeatedly exposed to designs during the process of
        software
        > development are unconsciously "tainted" by the process itself.
        > Assumptions become facts, facts become reality, and serious blind
        spots
        > develop.  A screen that is not intuitive at all seems
        intuitive to the
        > "kidnapped user" after they have seen it 100
        times."

        > Is this true? If so, how do you keep this from happening in
        projects you
        > lead/mentor/work on?

        I found this an intriguing question and more appropriate for this group.
         

        ==============================================
         
        Alistair Cockburn
        Humans and Technology

        801.582.3162   |  1814 Ft Douglas Cir |  Salt Lake City, UT 84103
        http://alistair.cockburn.us/   | acockburn@...
         
        ==============================================

        "La perfection est atteinte non quand il ne reste rien a ajouter,
        mais quand il ne reste rien a enlever." (Saint-Exupery)

        "The first thing to build is trust." -- Brad Appleton

        ==============================================

      • Elizabeth Whitworth
        ... One way to partially save users, can be to only *gather* data from users - get their feedback, but do not provide any feedback, discussion, or
        Message 3 of 27 , Aug 31, 2005
        • 0 Attachment
          > Richard Sheridan of Menlo Innovations recently said:
          > "A second problem with kidnapping a user is that the user
          rapidly
          > becomes a "former user."  The Stockholm Syndrome kicks in
          and the kidnap
          > victim begins to identify with their captors.
          ...
          >Is this true? If so, how do you keep this from happening in projects you
          > lead/mentor/work on?


          One way to partially "save" users, can be to only *gather* data from users - get their feedback, but do not provide any feedback, discussion, or rationalization to the user in turn. This tactic, however, doesn't seem to work well into the communicative nature of agile.

          Another tactic is to have a relatively impartial 3rd party (a usability person) do the user testing...the actual developers/designers of the system can and should watch the tests, but should not talk to the user or try to explain their designs to them (corrupt them :-). Having this usability middle man to gather information and to represent the user in discussions may be a solution...?

          note - this suggestion has nothing to do with the fact that I will need a job once I graduate :-P

          Elizabeth Whitworth
          M.A. Student, HCI

          On 8/31/05, acockburn@... <acockburn@...> wrote:
          From the XP list: On Tuesday, August 30, 2005, at 9:08:15 PM, Cory Foy wrote:

          > Richard Sheridan of Menlo Innovations recently said:

          > "A second problem with kidnapping a user is that the user rapidly
          > becomes a "former user."  The Stockholm Syndrome kicks in and the kidnap
          > victim begins to identify with their captors.  They start to accept the
          > explanations that intuitive interface is simply "too hard" to implement.
          >   It doesn't take long before the developers have fully brain washed the
          > captive user, and the user begins to think of the "computer" as the
          > dominant force in making interface decisions. From here it's a slippery
          > slope into the morass of "file selection dialogs", "standard user
          > interface widgets from Microsoft" and other "standard practices" in
          > building user interface that leave the real users saying,  "What were
          > they thinking?"
          >   At its core the "kidnap a user" approach is irreparably flawed.  Any
          > users repeatedly exposed to designs during the process of software
          > development are unconsciously "tainted" by the process itself.
          > Assumptions become facts, facts become reality, and serious blind spots
          > develop.  A screen that is not intuitive at all seems intuitive to the
          > "kidnapped user" after they have seen it 100 times."

          > Is this true? If so, how do you keep this from happening in projects you
          > lead/mentor/work on?

          I found this an intriguing question and more appropriate for this group.
           

          ==============================================
           
          Alistair Cockburn
          Humans and Technology

          801.582.3162   |  1814 Ft Douglas Cir |  Salt Lake City, UT 84103
          http://alistair.cockburn.us/   | acockburn@...
           
          ==============================================

          "La perfection est atteinte non quand il ne reste rien a ajouter,
          mais quand il ne reste rien a enlever." (Saint-Exupery)

          "The first thing to build is trust." -- Brad Appleton

          ==============================================



          SPONSORED LINKS
          Usability testing Usability Agile software development
          Agile development


          YAHOO! GROUPS LINKS




        • Desilets, Alain
          It s important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code
          Message 4 of 27 , Aug 31, 2005
          • 0 Attachment
            Message
             
            It's important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code behavior to operating environment is just a total black art to the user. When a software engineer says, "It can't be done," that becomes fact for the user. "Gee if it's impossible to use radio buttons here, I guess I'll have to live with check boxes and be careful that I don't make a mistake."
             
            It's been a long time since I have done any coding but, often enough, I will find a programmer who claims it can't be done simply because they haven't figured out how to do it. Add to these, the complaints that "it will take too much work to make that change" and you have good user interfaces being sabotaged to save software engineering time and money at the cost of much greater production usage time and money. 
             
            -- Alain:
            Maximising usability at all costs is the wrong idea, and it is anti-Agile. Cost and time of producing the software is a very important part of the equation for the people who commissioned the work. I have never heard a senior executives ask about a project: "How are we doing on usability?", but I ALWAYS hear them ask "How are we doing with budget and delivery time?". Maybe that's wrong and executives should be asking more about usability than time and budget, but that's the reality we live in.
             
            One of the great advantages of mixing people up in an Agile environment is that people from different disciplines get an understanding of the values and constraints that they each faced. When developpers, quality assurange, U*, business analysts,  work separately in their own corner, they all assume that /their/ agenda (ex: delivering on time and in-budget, making sure there are no bugs, making sure the system is usable, making sure that the system will make money) is the only one that counts.
             
            In an Agile environment, if a U* professional comes up with a design that the developper has problem with, what naturally ensues is a discussion between the two. Through this discussion, the U* person would get a better understanding of the issue, which could be:
             
            - "No one on the team knows how to do it, and but we can probably find out by doing a 3 day spike"
            - "It can be done, but only on platforms X, Y and Z"
            - "It can be done, but it will make the system really slow"
            - "It can be done, but we would have to spend a month rewriting this part of the system"
            - "It can't be done unless you rewrite Windows XP"
            - "It is mathematically impossible"
             
            The U* professional, who is also aware of the pressure to deliver on-time and on-budget and knows how late or on-time the project is (by virtue of being part of the building process) can then decide if the cost of implementing the original design (in terms of time, money, portability, performance, etc...) is worth it, or if less costly yet only slightly less usable design is better overall.
             
            Similarly, the developper will get an understanding of the rationale for the original design in terms of usability, and might be able to work with the U* to come up with a design that is easier to implement without sacrificing too much usability.
             

            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

             

            ----
          • Ron Jeffries
            ... It s also important to realize that in (a) agile methods, and (b) actually any healthy organization, it doesn t work that way. Progress is visible, and the
            Message 5 of 27 , Aug 31, 2005
            • 0 Attachment
              On Wednesday, August 31, 2005, at 1:18:43 PM, Desilets, Alain wrote:

              > It's important to realize how much power the software engineer has over the
              > development of a product. Much of what they do from coding environment to code
              > behavior to operating environment is just a total black art to the user. When a
              > software engineer says, "It can't be done," that becomes fact for the user. "Gee if
              > it's impossible to use radio buttons here, I guess I'll have to live with check boxes
              > and be careful that I don't make a mistake."

              It's also important to realize that in (a) agile methods, and (b)
              actually any healthy organization, it doesn't work that way.
              Progress is visible, and the difficulty of doing things is
              translated into comparative cost, not into "can't be done".

              In short, "it can't be done" is never true and should never be
              believed. "I can't do that," on the other hand, is believable.

              Ron Jeffries
              www.XProgramming.com
              You don't want to sell me waterfall.
              You want to go home and rethink your life.
            • William Pietri
              ... That s absolutely the case. I may have mentioned it here before, but there was a great presentation from some PARC researchers a few years back at a BayXP
              Message 6 of 27 , Aug 31, 2005
              • 0 Attachment
                On Wed, 2005-08-31 at 13:18 -0400, Desilets, Alain wrote:
                > The U* professional, who is also aware of the pressure to
                > deliver on-time and on-budget and knows how late or on-time
                > the project is (by virtue of being part of the building
                > process) can then decide if the cost of implementing the
                > original design (in terms of time, money, portability,
                > performance, etc...) is worth it, or if less costly yet only
                > slightly less usable design is better overall.

                That's absolutely the case.

                I may have mentioned it here before, but there was a great presentation
                from some PARC researchers a few years back at a BayXP meeting. The user
                experts had some interesting theories about how people use email and
                needed a special email client with a novel interface to test their
                theories.

                Although their normal bias was toward a very usable interface, when they
                found themselves in the driver's seat, their priorities changed. That
                doesn't mean the tool was awful, but they looked hard for alternate ways
                (e.g., more training, more documentation) to get users going rather than
                remove features that they wanted for their research.

                I also found it very interesting that they didn't see the process as
                constraining. Instead, because they could try things out as they went,
                they had feedback that drove more innovation. As one of their
                researchers put it, "XP expands the design space."

                William

                --
                William Pietri <william@...>
              • Jon Meads
                An interesting response. IMHO, maximizing anything at all costs is usually a sure path to disaster. And I have seen plenty of products where the functionality
                Message 7 of 27 , Aug 31, 2005
                • 0 Attachment
                  Message
                  An interesting response.  IMHO, maximizing anything at all costs is usually a sure path to disaster.
                   
                  And I have seen plenty of products where the functionality was such a major improvement over current capabilities that making it available to the user ASAP without any "usability engineering" per se was the smart business move and appreciated by the users.
                   
                  OTOH, good usability engineering, properly done [please note qualifiers!], can often save significant development time and cost. And, while budget and schedule are often critical parameters, getting a product out that meets the business needs is usually even more critical. I'd rather be over budget and schedule with a product of value than to produce a worthless one that is on time and under budget.
                   
                  The thing is that agile development and usability engineering are not at odds with each other. They complement each other very nicely when done right. Good usability engineering can be integrated with smart agile development so that the overall product development process is improved and the resulting product is too.
                   
                  Cheers,
                  jon 


                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                  Sent: Wednesday, August 31, 2005 10:19 AM
                  To: agile-usability@yahoogroups.com
                  Subject: RE: [agile-usability] Kidnapping users

                   
                  It's important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code behavior to operating environment is just a total black art to the user. When a software engineer says, "It can't be done," that becomes fact for the user. "Gee if it's impossible to use radio buttons here, I guess I'll have to live with check boxes and be careful that I don't make a mistake."
                   
                  It's been a long time since I have done any coding but, often enough, I will find a programmer who claims it can't be done simply because they haven't figured out how to do it. Add to these, the complaints that "it will take too much work to make that change" and you have good user interfaces being sabotaged to save software engineering time and money at the cost of much greater production usage time and money. 
                   
                  -- Alain:
                  Maximising usability at all costs is the wrong idea, and it is anti-Agile. Cost and time of producing the software is a very important part of the equation for the people who commissioned the work. I have never heard a senior executives ask about a project: "How are we doing on usability?", but I ALWAYS hear them ask "How are we doing with budget and delivery time?". Maybe that's wrong and executives should be asking more about usability than time and budget, but that's the reality we live in.
                   
                  One of the great advantages of mixing people up in an Agile environment is that people from different disciplines get an understanding of the values and constraints that they each faced. When developpers, quality assurange, U*, business analysts,  work separately in their own corner, they all assume that /their/ agenda (ex: delivering on time and in-budget, making sure there are no bugs, making sure the system is usable, making sure that the system will make money) is the only one that counts.
                   
                  In an Agile environment, if a U* professional comes up with a design that the developper has problem with, what naturally ensues is a discussion between the two. Through this discussion, the U* person would get a better understanding of the issue, which could be:
                   
                  - "No one on the team knows how to do it, and but we can probably find out by doing a 3 day spike"
                  - "It can be done, but only on platforms X, Y and Z"
                  - "It can be done, but it will make the system really slow"
                  - "It can be done, but we would have to spend a month rewriting this part of the system"
                  - "It can't be done unless you rewrite Windows XP"
                  - "It is mathematically impossible"
                   
                  The U* professional, who is also aware of the pressure to deliver on-time and on-budget and knows how late or on-time the project is (by virtue of being part of the building process) can then decide if the cost of implementing the original design (in terms of time, money, portability, performance, etc...) is worth it, or if less costly yet only slightly less usable design is better overall.
                   
                  Similarly, the developper will get an understanding of the rationale for the original design in terms of usability, and might be able to work with the U* to come up with a design that is easier to implement without sacrificing too much usability.
                   

                  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

                   

                  ----
                • Desilets, Alain
                  OTOH, good usability engineering, properly done [please note qualifiers!], can often save significant development time and cost. And, while budget and schedule
                  Message 8 of 27 , Aug 31, 2005
                  • 0 Attachment
                    Message
                    OTOH, good usability engineering, properly done [please note qualifiers!], can often save significant development time and cost. And, while budget and schedule are often critical parameters, getting a product out that meets the business needs is usually even more critical. I'd rather be over budget and schedule with a product of value than to produce a worthless one that is on time and under budget.
                     
                    The thing is that agile development and usability engineering are not at odds with each other. They complement each other very nicely when done right. Good usability engineering can be integrated with smart agile development so that the overall product development process is improved and the resulting product is too.
                     
                    -- Alain:
                    I agree completely. I was merely responding to this statement:
                     
                    > Add to these, the complaints that "it will take too much work to make that change" and you have good
                    > user interfaces being sabotaged to save software engineering time and money at the cost of much
                    > greater production usage time and money. 
                     
                    which, as I read carry overtones of "improving usability is more important than saving implementation time".
                     
                    I agree with you that getting a good product out late and over budget is often better than getting a bad product on time. But that decision is neither for the developpers or U* experts to make. If the people funding the project would rather get a bad product out on time and on budget for business reasons (ex: they are running out of venture capital), then it's their choice. We can try to dissuade them, but THEY should be in control of such tradeoffs.
                    ---- 
                  • Desilets, Alain
                    -- Alain Désilets wrote: I agree with you that getting a good product out late and over budget is often better than getting a bad product on time. But that
                    Message 9 of 27 , Aug 31, 2005
                    • 0 Attachment
                      Message
                       
                      -- Alain Désilets wrote: 
                       I agree with you that getting a good product out late and over budget is often better than getting a bad product on time. But that decision is neither for the developpers or U* experts to make. If the people funding the project would rather get a bad product out on time and on budget for business reasons (ex: they are running out of venture capital), then it's their choice. We can try to dissuade them, but THEY should be in control of such tradeoffs.
                      ----  
                       
                      -- and now he adds:
                      Actually, I should rephrase that. In reality, the choice is rarely between a /bad/ product on budget and on time vs a /good/ project late and overbudget. More typically, it's a choice between a /decent/ product on time and within budget vs a /top-notch/ product over budget and overtime.
                      ---- 
                    • Jon Meads
                      Alain, You interpreted it correctly. Improved usability is often more important than saving implementation time. For example, a project we had a few years ago
                      Message 10 of 27 , Sep 1, 2005
                      • 0 Attachment
                        Message
                        Alain,
                         
                        You interpreted it correctly. Improved usability is often more important than saving implementation time.
                         
                        For example, a project we had a few years ago redesigning the UI for customer service support for a major service provider. If a project manager were to have cut back on usability to keep the project from going $100,000 over in development cost, he would have been fired. The reason - the company has 3000 to 5000 customer service reps on duty at any time (24/7). Reducing the time of the average support call by a single second saves that company $800,000/year. By putting adequate time into the usability of that project (most of it done before any coding was started), we were able to reduce the average time for a particular type of call that was about 30% of all calls by 40 seconds. That's $9,600,000 of savings per year. Cutting usability to save implementation time would have been a loser in this case.
                         
                        Another example, suppose good usability can eliminate a particular problem with a software package that would have caused 10% of customers to make a support call. Support calls cost from $6 to $60 each depending on the organization and type of call. An average cost of $20 per call is reasonable. Suppose your product is only mildly successful and sells only 1M copies. At an average cost per call, that usability problem would cost $2,000,000. I'd say there would be good reason to go over budget and schedule a small bit for that.
                         
                        Now if you are developing a UI that will be used by 3 people 5 times a year and usage problems might cost $50,000. Well, hell, going over budget or schedule may not be worth it.
                         
                        But [Larry Marine, UTEST Email, 31 Jan 2003]:
                        We have found that if our clients budget 25-40% of their typical design and
                        implementation budget to a well practiced UCD process, they can actually end
                        up completing the project for less than the historical costs.
                        This is my experience as well. Yes, improved usability can be more important than saving implementation time. . A lot depends on the business objectives of the project, who the users are, what the impact will be. etc.  Improved usability may not always be more important than saving implementation time but it is often enough and can even reduce implementation time.
                         
                        Cheers,
                        jon


                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                        Sent: Wednesday, August 31, 2005 5:34 PM
                        To: agile-usability@yahoogroups.com
                        Subject: RE: [agile-usability] Kidnapping users

                        OTOH, good usability engineering, properly done [please note qualifiers!], can often save significant development time and cost. And, while budget and schedule are often critical parameters, getting a product out that meets the business needs is usually even more critical. I'd rather be over budget and schedule with a product of value than to produce a worthless one that is on time and under budget.
                         
                        The thing is that agile development and usability engineering are not at odds with each other. They complement each other very nicely when done right. Good usability engineering can be integrated with smart agile development so that the overall product development process is improved and the resulting product is too.
                         
                        -- Alain:
                        I agree completely. I was merely responding to this statement:
                         
                        > Add to these, the complaints that "it will take too much work to make that change" and you have good
                        > user interfaces being sabotaged to save software engineering time and money at the cost of much
                        > greater production usage time and money. 
                         
                        which, as I read carry overtones of "improving usability is more important than saving implementation time".
                         
                        I agree with you that getting a good product out late and over budget is often better than getting a bad product on time. But that decision is neither for the developpers or U* experts to make. If the people funding the project would rather get a bad product out on time and on budget for business reasons (ex: they are running out of venture capital), then it's their choice. We can try to dissuade them, but THEY should be in control of such tradeoffs.
                        ---- 
                      • Desilets, Alain
                        Alain, You interpreted it correctly. Improved usability is often more important than saving implementation time. -- Alain: With the word /often/ in that
                        Message 11 of 27 , Sep 1, 2005
                        • 0 Attachment
                          Message
                          Alain,
                           
                          You interpreted it correctly. Improved usability is often more important than saving implementation time.  
                           
                          -- Alain:
                          With the word /often/ in that statement, I find I am in total agreement. But this is something that should not be taken as a blanket statement. There are lots of situations where development time is more important, especially for small startup companies that are strapped for cash and need to get a revenu flow going quickly.
                          ----
                        • Desilets, Alain
                          For example, a project we had a few years ago redesigning the UI for customer service support for a major service provider. If a project manager were to have
                          Message 12 of 27 , Sep 1, 2005
                          • 0 Attachment
                            Message
                            For example, a project we had a few years ago redesigning the UI for customer service support for a major service provider. If a project manager were to have cut back on usability to keep the project from going $100,000 over in development cost, he would have been fired. The reason - the company has 3000 to 5000 customer service reps on duty at any time (24/7). Reducing the time of the average support call by a single second saves that company $800,000/year. By putting adequate time into the usability of that project (most of it done before any coding was started), we were able to reduce the average time for a particular type of call that was about 30% of all calls by 40 seconds. That's $9,600,000 of savings per year. Cutting usability to save implementation time would have been a loser in this case. 
                             
                            -- Alain:
                            Actually, even in a scenario like this, you still have to way usability against development costs.
                             
                            The above analysis simply means that usability issues which might generate additional service call seconds are very costly, and therefore it is worth investing a lot of development time into fixing them. But what about usability issues that are NOT likely to generate additional support calls? For those, should you blindly follow the approach that usability is more important than development cost? What if a particular usability issue is a mere annoyance to the user, but solving it would require significant development effort?
                            ----
                          • Jon Meads
                            Most small start ups are providing functionality that doesn t currently exist and of such a value that users wil put a lot of effort into learning the product
                            Message 13 of 27 , Sep 1, 2005
                            • 0 Attachment
                              Message
                              Most small start ups are providing functionality that doesn't currently exist and of such a value that users wil put a lot of effort into learning the product and putting up with usability problems just to get that functionality. When they start getting competition then usability starts to be more of an issue as it affects the total user experience and then starts to affect the brand.
                               
                              Cheers,
                              jon


                              From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                              Sent: Thursday, September 01, 2005 7:42 AM
                              To: agile-usability@yahoogroups.com
                              Subject: RE: [agile-usability] Kidnapping users

                              Alain,
                               
                              You interpreted it correctly. Improved usability is often more important than saving implementation time.  
                               
                              -- Alain:
                              With the word /often/ in that statement, I find I am in total agreement. But this is something that should not be taken as a blanket statement. There are lots of situations where development time is more important, especially for small startup companies that are strapped for cash and need to get a revenu flow going quickly.
                              ----
                            • Desilets, Alain
                              Most small start ups are providing functionality that doesn t currently exist and of such a value that users wil put a lot of effort into learning the product
                              Message 14 of 27 , Sep 1, 2005
                              • 0 Attachment
                                Message
                                Most small start ups are providing functionality that doesn't currently exist and of such a value that users wil put a lot of effort into learning the product and putting up with usability problems just to get that functionality. When they start getting competition then usability starts to be more of an issue as it affects the total user experience and then starts to affect the brand.
                                 
                                Cheers,
                                jon 
                                 
                                -- Alain:
                                I agree. I guess my world view is biased towards small startups because as a researcher, I usually deal with this kind of client.
                                ----
                              • Jon Meads
                                I don t think you understand the scenario correctly. The usability effort was directed towards the UI for the customer service representatives. The number of
                                Message 15 of 27 , Sep 1, 2005
                                • 0 Attachment
                                  Message
                                  I don't think you understand the scenario correctly. The usability effort was directed towards the UI for the customer service representatives. The number of support calls coming in would not be significantly affected by the UI we were working on.
                                   
                                  To be honest, I don't know why there is an issue on "how much" usability engineering is needed. The amount will always be dependent on a large number of factors which will be different from project to project. What is needed is the right amount to have success in attaining the business goals of the project. Understanding what that might be often requires a mature product manager.
                                   
                                  Can you have "too much" software engineering?  Of course. The most common way this occurs is when a developer comes up with a new feature that does not contribute sufficiently to the value of the product to cover the cost of supporting that feature. Again, managing the amount of software engineering needed requires a mature product manager.
                                   
                                  The other thing that is needed in both cases is a development culture that is oriented towards meeting business goals and producing value to all the stakeholders.
                                   
                                  Cheers,
                                  jon


                                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                  Sent: Thursday, September 01, 2005 8:01 AM
                                  To: agile-usability@yahoogroups.com
                                  Subject: RE: [agile-usability] Kidnapping users

                                  For example, a project we had a few years ago redesigning the UI for customer service support for a major service provider. If a project manager were to have cut back on usability to keep the project from going $100,000 over in development cost, he would have been fired. The reason - the company has 3000 to 5000 customer service reps on duty at any time (24/7). Reducing the time of the average support call by a single second saves that company $800,000/year. By putting adequate time into the usability of that project (most of it done before any coding was started), we were able to reduce the average time for a particular type of call that was about 30% of all calls by 40 seconds. That's $9,600,000 of savings per year. Cutting usability to save implementation time would have been a loser in this case. 
                                   
                                  -- Alain:
                                  Actually, even in a scenario like this, you still have to way usability against development costs.
                                   
                                  The above analysis simply means that usability issues which might generate additional service call seconds are very costly, and therefore it is worth investing a lot of development time into fixing them. But what about usability issues that are NOT likely to generate additional support calls? For those, should you blindly follow the approach that usability is more important than development cost? What if a particular usability issue is a mere annoyance to the user, but solving it would require significant development effort?
                                  ----
                                • Desilets, Alain
                                  I don t think you understand the scenario correctly. The usability effort was directed towards the UI for the customer service representatives. The number of
                                  Message 16 of 27 , Sep 1, 2005
                                  • 0 Attachment
                                    Message
                                    I don't think you understand the scenario correctly. The usability effort was directed towards the UI for the customer service representatives. The number of support calls coming in would not be significantly affected by the UI we were working on. 
                                     
                                    -- Alain:
                                    Sorry, I misread your scenario. In the scenario you actually describe, usability translates directly into saved dollars, and that's a great poster child for a type of situation where usability trumps a lot of other issues. I'm sure there are other similar situations like saftety critical UIs (ex: airplane cockpit).
                                     
                                    It thought you were talking about a different situation where improvment in the usability of a particular piece of software decreases the amount of customer support required for that product, hence resulting in dollar savings. I have often heard that argument used to make a case for usability. But there, the relationship is less direct and it's harder to quantify to what extent a particular usability issue will generate additional work for the support staff. Development time on the other hand, is directly quantifiable and that's why managers (for better or for worse) tend to focus on that more.
                                    ---- 
                                     
                                    To be honest, I don't know why there is an issue on "how much" usability engineering is needed. The amount will always be dependent on a large number of factors which will be different from project to project. What is needed is the right amount to have success in attaining the business goals of the project. Understanding what that might be often requires a mature product manager.
                                     
                                    Can you have "too much" software engineering?  Of course. The most common way this occurs is when a developer comes up with a new feature that does not contribute sufficiently to the value of the product to cover the cost of supporting that feature. Again, managing the amount of software engineering needed requires a mature product manager.
                                     
                                    The other thing that is needed in both cases is a development culture that is oriented towards meeting business goals and producing value to all the stakeholders. 
                                     
                                    -- Alain:
                                    Absolutely! And I think Agile approaches have definite advantages there. They are very good at making sure that all factors and issues are laid out in the open and shared between different parts of the team. And since the project sponsors are in control and have all the data needed to make decisions, they can make those business decisions better.
                                    ----
                                  • Jon Meads
                                    -- Alain: Absolutely! And I think Agile approaches have definite advantages there. They are very good at making sure that all factors and issues are laid out
                                    Message 17 of 27 , Sep 1, 2005
                                    • 0 Attachment
                                      Message
                                       
                                      -- Alain:
                                      Absolutely! And I think Agile approaches have definite advantages there. They are very good at making sure that all factors and issues are laid out in the open and shared between different parts of the team. And since the project sponsors are in control and have all the data needed to make decisions, they can make those business decisions better.
                                      ---- 

                                      Assuming that they are rational project sponsors :-)  
                                          -- jon  
                                       
                                    • Desilets, Alain
                                      -- Alain: Absolutely! And I think Agile approaches have definite advantages there. They are very good at making sure that all factors and issues are laid out
                                      Message 18 of 27 , Sep 2, 2005
                                      • 0 Attachment
                                        Message
                                         
                                        -- Alain:
                                        Absolutely! And I think Agile approaches have definite advantages there. They are very good at making sure that all factors and issues are laid out in the open and shared between different parts of the team. And since the project sponsors are in control and have all the data needed to make decisions, they can make those business decisions better.
                                        ---- 

                                        Assuming that they are rational project sponsors :-)   
                                         
                                        -- Alain:
                                        Heaven knows there are lots of irrational project sponsors out there!
                                         
                                        But one has to be careful about assuming that the project sponsor is irrational. The sponsor is usually a fairly high placed individual and he usually didn't get there by chance! What may look like irrational choices may just be rational choices using a different set of criteria (ex: "We have to get this out the door ASAP or the VP might cancel the project" or "We have to get a revenue stream going before we run out of seed money").
                                         
                                        Whenever you think the project sponsor is taking an irrational decision, I would encourage you to engage him in a conversation to probe more deeply for his reasons. By the end of it, one of four things will have happened:
                                         
                                        a) You will have understood his rationale, and feel comfortable with going ahead with his decision
                                         
                                        b) He will have understood your rationale, and feel comfortable with going ahead with your decision
                                         
                                        c) You will have understood each other's rationale and have come up with a different decision that takes both sides of the equation into account
                                         
                                        d) The sponsor sticks to his decision and you still feel it is irrational.
                                         
                                        Outcomes a) through c) are good. But if d) happens too often, then get transferred to a different project ASAP!
                                         
                                        Alain
                                        ----
                                      • Larry Constantine
                                        Alain wrote: Maximising usability at all costs is the wrong idea, and it is anti-Agile. Cost and time of producing the software is a very important part of
                                        Message 19 of 27 , Sep 6, 2005
                                        • 0 Attachment
                                          Message

                                          Alain wrote:

                                           

                                          “Maximising usability at all costs is the wrong idea, and it is anti-Agile. Cost and time of producing the software is a very important part of the equation for the people who commissioned the work. I have never heard a senior executives ask about a project: "How are we doing on usability?", but I ALWAYS hear them ask "How are we doing with budget and delivery time?". Maybe that's wrong and executives should be asking more about usability than time and budget, but that's the reality we live in.”

                                           

                                          Yes, of course, but nobody was waving the “usability at any cost” flag. The issue should always be total cost of ownership and cost-benefit ratio, not design/development budget/schedule alone. Indeed, upper management does need to be educated (again) on this. Multiple investigations and case studies have shown that dollars spent on improving usability come back many-fold. (And I do work with executives who, precisely for these reasons, ask about how usability is fairing.)

                                           

                                          In my experience, the most effective way to get dramatic improvements in usability without incurring high costs of redesign, recoding, re-architecting or corresponding delays in delivery is to design it right to begin with. And don’t jump on me with the hoary old BDUF shibboleth. The truth is that design can be much cheaper than coding. And agile design can be enormously cheaper. :-)

                                           

                                          --Larry Constantine, IDSA [mailto:lconstantine@...]
                                            Chief Scientist | Constantine & Lockwood, Ltd.
                                            58 Kathleen Circle | Rowley, MA 01969
                                            tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


                                        • Jon Kern
                                          enjoy: http://blogs.compuware.com/cs/blogs/jkern/ I have another post poised on the topics surrounding why we struggle -- not only at usability, but on things
                                          Message 20 of 27 , Sep 6, 2005
                                          • 0 Attachment
                                            enjoy: http://blogs.compuware.com/cs/blogs/jkern/

                                            I have another post poised on the topics surrounding why we struggle --
                                            not only at usability, but on things like reuse. Stay tuned...

                                            -- jon kern
                                          • Desilets, Alain
                                            -- Larry Constantine wrote: Yes, of course, but nobody was waving the usability at any cost flag. The issue should always be total cost of ownership and
                                            Message 21 of 27 , Sep 7, 2005
                                            • 0 Attachment
                                              Message
                                               
                                              -- Larry Constantine wrote:     

                                              Yes, of course, but nobody was waving the “usability at any cost” flag. The issue should always be total cost of ownership and cost-benefit ratio, not design/development budget/schedule alone. Indeed, upper management does need to be educated (again) on this. Multiple investigations and case studies have shown that dollars spent on improving usability come back many-fold. (And I do work with executives who, precisely for these reasons, ask about how usability is fairing.) 

                                              ----

                                               

                                              -- Alain reples:

                                              I completely agree with what you are saying above. I guess I didn't read much willingness to weigh engineering time against user time in your original post (see below, emphasis by me), nor to engage developpers and higher level stakeholders in a discussion about what the actual costs are and how they should be traded off.

                                               

                                              == Larry Constantine first wrote:

                                              It's important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code behavior to operating environment is just a total black art to the user. When a software engineer says, "It can't be done," that becomes fact for the user. "Gee if it's impossible to use radio buttons here, I guess I'll have to live with check boxes and be careful that I don't make a mistake."

                                               

                                              It's been a long time since I have done any coding but, often enough, I will find a programmer who claims it can't be done simply because they haven't figured out how to do it. Add to these, the complaints that "it will take too much work to make that change" and you have good user interfaces being sabotaged to save software engineering time and money at the cost of  **much greater**  production usage time and money. 
                                              ====
                                               
                                              But now that I read it again, I see that you were just saying that the savings in user often time greatly exceeds the cost in Engineering time. So I stand corrected.
                                               
                                              I pretty much agree with that statement, especially for software that is use a LOT by a LOT of people. In the case of an in-house development effort, the rational decision in such a situation would be to optimise usability to save user cost (but not at all cost for development of course).
                                               
                                              But if you are building shrink wrapped software, you only care about user cost in so far as it might affect sales of your software. So there is much less incentive to minimise your user cost at the expense of development cost for you. In such a situation, the rational decision (especially if you are a start up running out of seed capital) might be to implement as little as you can get away with, in order to get a revenu stream running.
                                              ----

                                               

                                               

                                              The truth is that design can be much cheaper than coding. And agile design can be enormously cheaper. :-) 

                                               

                                              -- Alain:

                                              Can you define what you mean by Agile design?

                                               

                                              Design is such an overloaded word that I find I can never agree unconditionally on any statement that talks about it.

                                               

                                              I have been on a 9 months project where Design meant 2 weeks to come up with a 5 page description of what the system is and is not about. I have been on another 9 month project where Design meant spending 6 months producing UML diagrams, which left only 3 months for implementation.

                                               

                                              You can guess which of the two projects was successful :-).

                                              ----

                                               

                                               

                                              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

                                               

                                               

                                              --Larry Constantine, IDSA [mailto:lconstantine@...]
                                                Chief Scientist | Constantine & Lockwood, Ltd.
                                                58 Kathleen Circle | Rowley, MA 01969
                                                tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


                                            • Desilets, Alain
                                              Alain, It was Jon Meads who wrote the first wrote (below) not me. -- Alain: Sorry guys, I was sure I had traced the original posting down to Larry. ... As to
                                              Message 22 of 27 , Sep 7, 2005
                                              • 0 Attachment
                                                Message

                                                 

                                                Alain,

                                                 

                                                It was Jon Meads who wrote the “first wrote” (below) not me. 

                                                 

                                                -- Alain:

                                                Sorry guys, I was sure I had traced the original posting down to Larry.

                                                ---- 

                                                 

                                                As to agile design (and agile modeling), I think of it as design and modeling consistent with an agile philosophy. Don’t model for the sake of modeling but only insofar as it speeds solution. Don’t design what you don’t have to, design what you need to. Just-in-time design, which means neither too late nor too early. Models and design artifacts that focus on the essentials. Rapid, low-tech, card-based modeling…. BUT, do get an overview, a lay-of-the-land understanding the UI and information architecture before you plunge in too far--possibly down a blind alley. We use sharply focused, efficient models to understand user roles and tasks: user roles not personas, essential use cases not scenarios, and we use goal-oriented inquiry based on exploratory modeling rather than broadly conceived ethnographic observation or wide-scope data gathering. 

                                                 

                                                -- Alain:

                                                Sounds really great. Here is a question, for which the correct answer is (I'm sure) "it depends". But could you venture a broad guestimate? Here it goes.

                                                 

                                                "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?

                                                ---- 

                                                 

                                                Using 6 months of a 3-month project timeline for UML modeling is not doing design, it is just being irresponsible and unprofessional. A good designer always keeps an eye on the clock. I am frequently amused by the teams in training, who, knowing they have only an hour for some task, spend 55 minutes arguing about an approach and then panic. A lot of good design is scaling, constantly adjusting the pace and focus of activities to fit the remaining timeframe, getting on with it, going for the core, the essentials, the high payoff activities when time is short. To me this is a matter of professionalism. 

                                                 

                                                -- Alain:

                                                Funnily enough, the project in question succeeded IN-SPITE of the fact that too much time had been spent on upfront design. That's because when it finally dawned on the project manager (who was pushing for more design all the time) that there were only 3 months left, he changed gear into what I would definitely call an Agile mode. Instead of pushing for more design, he started asking questions like "OK, what CAN we build in the remaining 3 months", "What is standing in your way right now and how can I remove those obstacles". needless to say the released product bared little resemblance to the original design.

                                                ---- 

                                              • Larry Constantine
                                                Alain, It was Jon Meads who wrote the “first wrote” (below) not me. As to agile design (and agile modeling), I think of it as design and modeling
                                                Message 23 of 27 , Sep 7, 2005
                                                • 0 Attachment
                                                  Message

                                                  Alain,

                                                   

                                                  It was Jon Meads who wrote the “first wrote” (below) not me.

                                                   

                                                  As to agile design (and agile modeling), I think of it as design and modeling consistent with an agile philosophy. Don’t model for the sake of modeling but only insofar as it speeds solution. Don’t design what you don’t have to, design what you need to. Just-in-time design, which means neither too late nor too early. Models and design artifacts that focus on the essentials. Rapid, low-tech, card-based modeling…. BUT, do get an overview, a lay-of-the-land understanding the UI and information architecture before you plunge in too far--possibly down a blind alley. We use sharply focused, efficient models to understand user roles and tasks: user roles not personas, essential use cases not scenarios, and we use goal-oriented inquiry based on exploratory modeling rather than broadly conceived ethnographic observation or wide-scope data gathering.

                                                   

                                                  Using 6 months of a 3-month project timeline for UML modeling is not doing design, it is just being irresponsible and unprofessional. A good designer always keeps an eye on the clock. I am frequently amused by the teams in training, who, knowing they have only an hour for some task, spend 55 minutes arguing about an approach and then panic. A lot of good design is scaling, constantly adjusting the pace and focus of activities to fit the remaining timeframe, getting on with it, going for the core, the essentials, the high payoff activities when time is short. To me this is a matter of professionalism.

                                                  --Larry Constantine, IDSA [mailto:lconstantine@...]
                                                    Chief Scientist | Constantine & Lockwood, Ltd.
                                                    58 Kathleen Circle | Rowley, MA 01969
                                                    tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com

                                                   


                                                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                                  Sent: Wednesday, 07 September 2005 8:20 AM
                                                  To: agile-usability@yahoogroups.com
                                                  Subject: RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

                                                   

                                                   

                                                  -- Larry Constantine wrote:     

                                                  Yes, of course, but nobody was waving the “usability at any cost” flag. The issue should always be total cost of ownership and cost-benefit ratio, not design/development budget/schedule alone. Indeed, upper management does need to be educated (again) on this. Multiple investigations and case studies have shown that dollars spent on improving usability come back many-fold. (And I do work with executives who, precisely for these reasons, ask about how usability is fairing.) 

                                                  ----

                                                   

                                                  -- Alain reples:

                                                  I completely agree with what you are saying above. I guess I didn't read much willingness to weigh engineering time against user time in your original post (see below, emphasis by me), nor to engage developpers and higher level stakeholders in a discussion about what the actual costs are and how they should be traded off.

                                                   

                                                  == Larry Constantine first wrote:

                                                  It's important to realize how much power the software engineer has over the development of a product. Much of what they do from coding environment to code behavior to operating environment is just a total black art to the user. When a software engineer says, "It can't be done," that becomes fact for the user. "Gee if it's impossible to use radio buttons here, I guess I'll have to live with check boxes and be careful that I don't make a mistake."

                                                   

                                                  It's been a long time since I have done any coding but, often enough, I will find a programmer who claims it can't be done simply because they haven't figured out how to do it. Add to these, the complaints that "it will take too much work to make that change" and you have good user interfaces being sabotaged to save software engineering time and money at the cost of  **much greater**  production usage time and money. 

                                                  ====

                                                   

                                                  But now that I read it again, I see that you were just saying that the savings in user often time greatly exceeds the cost in Engineering time. So I stand corrected.

                                                   

                                                  I pretty much agree with that statement, especially for software that is use a LOT by a LOT of people. In the case of an in-house development effort, the rational decision in such a situation would be to optimise usability to save user cost (but not at all cost for development of course).

                                                   

                                                  But if you are building shrink wrapped software, you only care about user cost in so far as it might affect sales of your software. So there is much less incentive to minimise your user cost at the expense of development cost for you. In such a situation, the rational decision (especially if you are a start up running out of seed capital) might be to implement as little as you can get away with, in order to get a revenu stream running.
                                                  ----

                                                   

                                                   

                                                  The truth is that design can be much cheaper than coding. And agile design can be enormously cheaper. :-) 

                                                   

                                                  -- Alain:

                                                  Can you define what you mean by Agile design?

                                                   

                                                  Design is such an overloaded word that I find I can never agree unconditionally on any statement that talks about it.

                                                   

                                                  I have been on a 9 months project where Design meant 2 weeks to come up with a 5 page description of what the system is and is not about. I have been on another 9 month project where Design meant spending 6 months producing UML diagrams, which left only 3 months for implementation.

                                                   

                                                  You can guess which of the two projects was successful :-).

                                                  ----

                                                   

                                                   

                                                  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
                                                   

                                                   

                                                  --Larry Constantine, IDSA [mailto:lconstantine@...]
                                                    Chief Scientist | Constantine & Lockwood, Ltd.
                                                    58 Kathleen Circle | Rowley, MA 01969
                                                    tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


                                                   

                                                • Desilets, Alain
                                                  Under pressure (which is almost always), we prefer to begin with an engineering triage to enable software design/development to proceed in parallel with
                                                  Message 24 of 27 , Sep 7, 2005
                                                  • 0 Attachment
                                                    Message
                                                     Under pressure (which is almost always), we prefer to begin with an engineering triage to enable software design/development  to proceed in parallel with initial usage-centered design activities. Collaborating with software engineers, programmers, managers, you try to identify functionality or software infrastructure that is (to a first order approximation) largely or wholly separable from the UI/presentation layer. Often you can guess pretty well and/or the implementation team does a good job of keeping things independent. In those cases where you later find as the UI architecture and the software structure become clearer that some of the work went down the wrong path, you re-factor or modify as needed. The coding need never be held up waiting for design because while the first segments were being coded, the U-CD team was finishing design work. 
                                                     

                                                    We have also found that, with good software architecture and robust coding practices, fully functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.

                                                     
                                                    -- Alain:
                                                    I like what I hear!
                                                     
                                                    When you say that:
                                                     
                                                    "functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs."
                                                     
                                                    Is usability testing included in the word "tested"?
                                                     
                                                    Also, do you find that by seeing the software running with such ad hocs UIs the UCD part of the team learns things that influence their design effort?
                                                     
                                                    Finally, don't you run into situations where the customer thinks that the the adhoc UI is perfecltly fine and wants to ship the product with it (the dreaded throwaway prototype being shipped as a final product situation)?
                                                    ---- 

                                                     

                                                    We have also found that, with good software architecture and robust coding practices, fully functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.

                                                     

                                                    As to what percent of the total budget goes into visual and interaction design, as you say, “It depends.” It depends on how complicated the UI is, what the objectives and needs of the project are in terms of usability, and how much time/money is allocated. It also depends on the development process model. If the entire UI design is developed completely incrementally, the designer(s) will have to be involved over the whole project, which as a practical matter may prove more expensive than if they had done their work up front and moved on to another assignment. It depends. :-)

                                                     

                                                     

                                                    --Larry Constantine, IDSA

                                                     


                                                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                                    Sent: Wednesday, 07 September 2005 11:03 AM
                                                    To: agile-usability@yahoogroups.com
                                                    Subject: RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

                                                     


                                                     

                                                    Alain,

                                                     

                                                    It was Jon Meads who wrote the “first wrote” (below) not me. 

                                                     

                                                    -- Alain:

                                                    Sorry guys, I was sure I had traced the original posting down to Larry.

                                                    ---- 

                                                     

                                                    As to agile design (and agile modeling), I think of it as design and modeling consistent with an agile philosophy. Don’t model for the sake of modeling but only insofar as it speeds solution. Don’t design what you don’t have to, design what you need to. Just-in-time design, which means neither too late nor too early. Models and design artifacts that focus on the essentials. Rapid, low-tech, card-based modeling…. BUT, do get an overview, a lay-of-the-land understanding the UI and information architecture before you plunge in too far--possibly down a blind alley. We use sharply focused, efficient models to understand user roles and tasks: user roles not personas, essential use cases not scenarios, and we use goal-oriented inquiry based on exploratory modeling rather than broadly conceived ethnographic observation or wide-scope data gathering. 

                                                     

                                                    -- Alain:

                                                    Sounds really great. Here is a question, for which the correct answer is (I'm sure) "it depends". But could you venture a broad guestimate? Here it goes.

                                                     

                                                    "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?

                                                    ---- 

                                                     

                                                    Using 6 months of a 3-month project timeline for UML modeling is not doing design, it is just being irresponsible and unprofessional. A good designer always keeps an eye on the clock. I am frequently amused by the teams in training, who, knowing they have only an hour for some task, spend 55 minutes arguing about an approach and then panic. A lot of good design is scaling, constantly adjusting the pace and focus of activities to fit the remaining timeframe, getting on with it, going for the core, the essentials, the high payoff activities when time is short. To me this is a matter of professionalism. 

                                                     

                                                    -- Alain:

                                                    Funnily enough, the project in question succeeded IN-SPITE of the fact that too much time had been spent on upfront design. That's because when it finally dawned on the project manager (who was pushing for more design all the time) that there were only 3 months left, he changed gear into what I would definitely call an Agile mode. Instead of pushing for more design, he started asking questions like "OK, what CAN we build in the remaining 3 months", "What is standing in your way right now and how can I remove those obstacles". needless to say the released product bared little resemblance to the original design.

                                                    ---- 

                                                     

                                                  • Desilets, Alain
                                                    Alain asked: For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what
                                                    Message 25 of 27 , Sep 7, 2005
                                                    • 0 Attachment
                                                      Message
                                                      Alain asked:

                                                       

                                                      "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?”

                                                      ---

                                                       

                                                      -- Larry replied:

                                                      Zero. And zero. (Ha, surprised you!)  

                                                      ----

                                                       

                                                      -- Alain re-replies:

                                                      Oh and BTW, you DID surprise me... But I don't know if you really meant to be that extreme or if you were being facetious, because you later said:

                                                      ----

                                                       

                                                      This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess. 

                                                       

                                                      -- Alain:

                                                      And surely getting the UI architecture requires more than zero hours of work (although I am sure it can be done fairly rapidly).

                                                       

                                                      Oh, I think I see...  while developpers are working on the basic infrastructure, the UCD part of the team works out the basic UI architecture, is that right?

                                                       

                                                      That brings up another question. I personally find that when I  write the backend infrastructure in complete isolation from the front-end, I almost inevitably end up over-engineering the backend. How do you avoid this trap?

                                                       

                                                      My way of avoiding it is to religiously follow the YAGNI (You Aint Gonna Need It) and BuildTheSimplestThingThatCouldPossiblyWork principles. But that assumes I have a basis for deciding what I am NOT going to need and what the simplest thing that COULD possible work is. And to do that, i need to build the front end at the same time (or at least have some understanding of what the front end is going to actually require from the backend).

                                                       

                                                      Here is a typical example. A few years ago, I started working on a tool that would allow children to collaboratively create hypertext stories on the web. I decided that Ward Cunningham's Wiki was a good starting point. When I looked at the code I was shocked to see that it did not include any file locking mechanism. As a result, if two people try to edit the same page at the same time, the changes of the first person to save will be LOST! I thought this was pure madness and was highly tempted to go ahead and implement file locking. But having just been in XP training, I resisted the urge and worked on other features which I KNEW I needed (ex: translating all dialogs because the kids who were going to use it were French). Well, the bottom line is that Ward was right. For the vast majority of contexts where Wikis are used, file locking is not necessary and in fact it might cause more problem than it's worth (ex: page being left accidentally locked forever). I have installed my lock-less clone on twenty different sites, and concurrent editing has never been a problem.

                                                      ---- 

                                                       

                                                      As to what percent of the total budget goes into visual and interaction design, as you say, “It depends.” It depends on how complicated the UI is, what the objectives and needs of the project are in terms of usability, and how much time/money is allocated. It also depends on the development process model. If the entire UI design is developed completely incrementally, the designer(s) will have to be involved over the whole project, which as a practical matter may prove more expensive than if they had done their work up front and moved on to another assignment. It depends. :-) 

                                                       

                                                      -- Alain:

                                                      My main concern about the U* gury turning into a pumpkin after the start of the project, is that at some point, the design of the UI may have to be changed because of say, time and budget constraints. If the U* guy is not available anymore to make decisions about how to change the design, what happens is that the developpers take matters into their own hands. And that's when UI butchering happens...

                                                      ----

                                                    • Larry Constantine
                                                      Alain asked: For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what
                                                      Message 26 of 27 , Sep 7, 2005
                                                      • 0 Attachment
                                                        Message

                                                        Alain asked:

                                                         

                                                        "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?”

                                                        ---

                                                         

                                                        Zero. And zero. (Ha, surprised you!) Under pressure (which is almost always), we prefer to begin with an engineering triage to enable software design/development  to proceed in parallel with initial usage-centered design activities. Collaborating with software engineers, programmers, managers, you try to identify functionality or software infrastructure that is (to a first order approximation) largely or wholly separable from the UI/presentation layer. Often you can guess pretty well and/or the implementation team does a good job of keeping things independent. In those cases where you later find as the UI architecture and the software structure become clearer that some of the work went down the wrong path, you re-factor or modify as needed. The coding need never be held up waiting for design because while the first segments were being coded, the U-CD team was finishing design work.

                                                         

                                                        We have also found that, with good software architecture and robust coding practices, fully functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.

                                                         

                                                        As to what percent of the total budget goes into visual and interaction design, as you say, “It depends.” It depends on how complicated the UI is, what the objectives and needs of the project are in terms of usability, and how much time/money is allocated. It also depends on the development process model. If the entire UI design is developed completely incrementally, the designer(s) will have to be involved over the whole project, which as a practical matter may prove more expensive than if they had done their work up front and moved on to another assignment. It depends. :-)

                                                         

                                                         

                                                        --Larry Constantine, IDSA

                                                         


                                                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                                        Sent: Wednesday, 07 September 2005 11:03 AM
                                                        To: agile-usability@yahoogroups.com
                                                        Subject: RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

                                                         


                                                         

                                                        Alain,

                                                         

                                                        It was Jon Meads who wrote the “first wrote” (below) not me. 

                                                         

                                                        -- Alain:

                                                        Sorry guys, I was sure I had traced the original posting down to Larry.

                                                        ---- 

                                                         

                                                        As to agile design (and agile modeling), I think of it as design and modeling consistent with an agile philosophy. Don’t model for the sake of modeling but only insofar as it speeds solution. Don’t design what you don’t have to, design what you need to. Just-in-time design, which means neither too late nor too early. Models and design artifacts that focus on the essentials. Rapid, low-tech, card-based modeling…. BUT, do get an overview, a lay-of-the-land understanding the UI and information architecture before you plunge in too far--possibly down a blind alley. We use sharply focused, efficient models to understand user roles and tasks: user roles not personas, essential use cases not scenarios, and we use goal-oriented inquiry based on exploratory modeling rather than broadly conceived ethnographic observation or wide-scope data gathering. 

                                                         

                                                        -- Alain:

                                                        Sounds really great. Here is a question, for which the correct answer is (I'm sure) "it depends". But could you venture a broad guestimate? Here it goes.

                                                         

                                                        "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?

                                                        ---- 

                                                         

                                                        Using 6 months of a 3-month project timeline for UML modeling is not doing design, it is just being irresponsible and unprofessional. A good designer always keeps an eye on the clock. I am frequently amused by the teams in training, who, knowing they have only an hour for some task, spend 55 minutes arguing about an approach and then panic. A lot of good design is scaling, constantly adjusting the pace and focus of activities to fit the remaining timeframe, getting on with it, going for the core, the essentials, the high payoff activities when time is short. To me this is a matter of professionalism. 

                                                         

                                                        -- Alain:

                                                        Funnily enough, the project in question succeeded IN-SPITE of the fact that too much time had been spent on upfront design. That's because when it finally dawned on the project manager (who was pushing for more design all the time) that there were only 3 months left, he changed gear into what I would definitely call an Agile mode. Instead of pushing for more design, he started asking questions like "OK, what CAN we build in the remaining 3 months", "What is standing in your way right now and how can I remove those obstacles". needless to say the released product bared little resemblance to the original design.

                                                        ---- 

                                                         

                                                      • Larry Constantine
                                                        ... When you say that: functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. Is
                                                        Message 27 of 27 , Sep 7, 2005
                                                        • 0 Attachment
                                                          Message

                                                          Alain wrote:

                                                          ---

                                                          When you say that:

                                                           

                                                          "functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs."

                                                           

                                                          Is usability testing included in the word "tested"?

                                                           

                                                          Also, do you find that by seeing the software running with such ad hocs UIs the UCD part of the team learns things that influence their design effort?

                                                           

                                                          Finally, don't you run into situations where the customer thinks that the the adhoc UI is perfecltly fine and wants to ship the product with it (the dreaded throwaway prototype being shipped as a final product situation)?

                                                           

                                                          ---

                                                           

                                                          No, usability testing is intended to find remaining usability problems in the UI as designed, not in a functional mockup or proof-of-concept prototype.

                                                           

                                                          I would not say we never change our design based on running prototypes, but it is not the normal experience, in part because the UI of the POC prototype is, as to be expected, not very good. We are more likely to refine our ideas after genuine usability testing of the final UI.

                                                           

                                                          We try to head off the last problem by carefully managing what and when we show clients. In particular, we avoid as much as possible showing clients early design concepts or prototypes. We want the first look to be pretty much what they will get. You can also manage this problem by making sure that a POC prototype does not look TOO good nor work TOO well. (E.g., leave visual components unaligned, don’t optimize access times, etc. Keep saying, “This is just a prototype, the real system will be much better.”) Think about a bread-boarded prototype in electronics. No one in their right mind would think of shipping that to consumers.

                                                           

                                                          --Larry Constantine, IDSA

                                                           


                                                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                                          Sent: Wednesday, 07 September 2005 11:46 AM
                                                          To: agile-usability@yahoogroups.com
                                                          Subject: RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

                                                           

                                                           Under pressure (which is almost always), we prefer to begin with an engineering triage to enable software design/development  to proceed in parallel with initial usage-centered design activities. Collaborating with software engineers, programmers, managers, you try to identify functionality or software infrastructure that is (to a first order approximation) largely or wholly separable from the UI/presentation layer. Often you can guess pretty well and/or the implementation team does a good job of keeping things independent. In those cases where you later find as the UI architecture and the software structure become clearer that some of the work went down the wrong path, you re-factor or modify as needed. The coding need never be held up waiting for design because while the first segments were being coded, the U-CD team was finishing design work. 

                                                           

                                                          We have also found that, with good software architecture and robust coding practices, fully functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.

                                                           

                                                          -- Alain:

                                                          I like what I hear!

                                                           

                                                          When you say that:

                                                           

                                                          "functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs."

                                                           

                                                          Is usability testing included in the word "tested"?

                                                           

                                                          Also, do you find that by seeing the software running with such ad hocs UIs the UCD part of the team learns things that influence their design effort?

                                                           

                                                          Finally, don't you run into situations where the customer thinks that the the adhoc UI is perfecltly fine and wants to ship the product with it (the dreaded throwaway prototype being shipped as a final product situation)?

                                                          ---- 

                                                           

                                                          We have also found that, with good software architecture and robust coding practices, fully functional software can be developed and tested with ad hoc UIs which are later reworked to conform to emerging UI designs. This assumes that you get the basic UI architecture right so that it is a matter of changing individual screens, not re-architecting the whole bloody mess.

                                                           

                                                          As to what percent of the total budget goes into visual and interaction design, as you say, “It depends.” It depends on how complicated the UI is, what the objectives and needs of the project are in terms of usability, and how much time/money is allocated. It also depends on the development process model. If the entire UI design is developed completely incrementally, the designer(s) will have to be involved over the whole project, which as a practical matter may prove more expensive than if they had done their work up front and moved on to another assignment. It depends. :-)

                                                           

                                                           

                                                          --Larry Constantine, IDSA

                                                           


                                                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                                                          Sent: Wednesday, 07 September 2005 11:03 AM
                                                          To: agile-usability@yahoogroups.com
                                                          Subject: RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

                                                           


                                                           

                                                          Alain,

                                                           

                                                          It was Jon Meads who wrote the “first wrote” (below) not me. 

                                                           

                                                          -- Alain:

                                                          Sorry guys, I was sure I had traced the original posting down to Larry.

                                                          ---- 

                                                           

                                                          As to agile design (and agile modeling), I think of it as design and modeling consistent with an agile philosophy. Don’t model for the sake of modeling but only insofar as it speeds solution. Don’t design what you don’t have to, design what you need to. Just-in-time design, which means neither too late nor too early. Models and design artifacts that focus on the essentials. Rapid, low-tech, card-based modeling…. BUT, do get an overview, a lay-of-the-land understanding the UI and information architecture before you plunge in too far--possibly down a blind alley. We use sharply focused, efficient models to understand user roles and tasks: user roles not personas, essential use cases not scenarios, and we use goal-oriented inquiry based on exploratory modeling rather than broadly conceived ethnographic observation or wide-scope data gathering. 

                                                           

                                                          -- Alain:

                                                          Sounds really great. Here is a question, for which the correct answer is (I'm sure) "it depends". But could you venture a broad guestimate? Here it goes.

                                                           

                                                          "For a nine month project, how much time do you typically spend on the initial UCD stuff before the first line of code is written. And what percentage of the UCD stuff (in terms of total effort) happens before a single line of code is written?

                                                          ---- 

                                                           

                                                          Using 6 months of a 3-month project timeline for UML modeling is not doing design, it is just being irresponsible and unprofessional. A good designer always keeps an eye on the clock. I am frequently amused by the teams in training, who, knowing they have only an hour for some task, spend 55 minutes arguing about an approach and then panic. A lot of good design is scaling, constantly adjusting the pace and focus of activities to fit the remaining timeframe, getting on with it, going for the core, the essentials, the high payoff activities when time is short. To me this is a matter of professionalism. 

                                                           

                                                          -- Alain:

                                                          Funnily enough, the project in question succeeded IN-SPITE of the fact that too much time had been spent on upfront design. That's because when it finally dawned on the project manager (who was pushing for more design all the time) that there were only 3 months left, he changed gear into what I would definitely call an Agile mode. Instead of pushing for more design, he started asking questions like "OK, what CAN we build in the remaining 3 months", "What is standing in your way right now and how can I remove those obstacles". needless to say the released product bared little resemblance to the original design.

                                                          ---- 

                                                           

                                                           

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