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

RE: [agile-usability] Usability Cost-Benefit (was: Kidnapping users)

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.