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

RE: [agile-usability] Kidnapping users

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.