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

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

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