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

Usability tests

Expand Messages
  • acyment
    Hi everyone out there! Do you consider usability tests (e.g. paper prototyping) should be done by the team or by someone represented by the PO? Could there be
    Message 1 of 15 , Apr 25, 2007
    • 0 Attachment
      Hi everyone out there! Do you consider usability tests (e.g. paper
      prototyping) should be done by the team or by someone represented by
      the PO? Could there be a user story that specifically asks for a given
      paper prototype?

      Thanks,
      Alan
    • George Dinwiddie
      ... Alan, I look at paper prototypes as a means to define and refine stories for the backlog. I don t think it s a story in itself. As to who should do it,
      Message 2 of 15 , Apr 25, 2007
      • 0 Attachment
        acyment wrote:
        > Hi everyone out there! Do you consider usability tests (e.g. paper
        > prototyping) should be done by the team or by someone represented by
        > the PO? Could there be a user story that specifically asks for a given
        > paper prototype?
        >
        > Thanks,
        > Alan

        Alan, I look at paper prototypes as a means to define and refine stories
        for the backlog. I don't think it's a story in itself.

        As to who should do it, well.... It should be done by whomever is good
        at doing it. I know that's begging the question, for figuring out who
        that is, is still undetermined.

        I've never had the pleasure of working on a project with someone really
        trained in this area. I've dabbled at studying it, but I'm primarily a
        programmer. Larry Constantine has some really good information in this
        area--I recommend his "abstract user prototyping" techniques. Often
        I've found that the PO, or other Customer proxy does this sort of design
        whether or not they've got any knowledge or skill in the area. <sigh/>
        It's too important to leave to chance, but many organizations don't have
        the awareness to be able to make a good choice.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Michael Vizdos
        What is paper prototyping ? Why not test an increment of actual working software instead? This can involve the Product Owner and other team members. - mike
        Message 3 of 15 , Apr 25, 2007
        • 0 Attachment
          What is "paper prototyping" ?

          Why not test an increment of actual working software instead?

          This can involve the Product Owner and other team members.

          - mike
            www.michaelvizdos.com
            www.implementingscrum.com


          On 4/25/07, acyment < acyment@...> wrote:

          Hi everyone out there! Do you consider usability tests (e.g. paper
          prototyping) should be done by the team or by someone represented by
          the PO? Could there be a user story that specifically asks for a given
          paper prototype?

          Thanks,
          Alan


        • acyment
          http://www.paperprototyping.com/
          Message 4 of 15 , Apr 25, 2007
          • 0 Attachment
            http://www.paperprototyping.com/

            --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
            <mvizdos@...> wrote:
            >
            > What is "paper prototyping" ?
            >
            > Why not test an increment of actual working software instead?
            >
            > This can involve the Product Owner and other team members.
            >
            > - mike
            > www.michaelvizdos.com
            > www.implementingscrum.com
            >
            >
            > On 4/25/07, acyment <acyment@...> wrote:
            > >
            > > Hi everyone out there! Do you consider usability tests (e.g. paper
            > > prototyping) should be done by the team or by someone represented by
            > > the PO? Could there be a user story that specifically asks for a given
            > > paper prototype?
            > >
            > > Thanks,
            > > Alan
            > >
            > >
            > >
            >
          • Michael Vizdos
            Nice... will have to read more (thank you!). From their site: It s possible to conduct usability tests on real interfaces, not just paper prototypes. So...
            Message 5 of 15 , Apr 25, 2007
            • 0 Attachment
              Nice... will have to read more (thank you!).

              From their site:

              "It'spossible to conduct usability tests on real interfaces, notjust paper prototypes."

              So... back to my original question.... why not test on real software? 

              - mike

              On 4/25/07, acyment <acyment@...> wrote:

              http://www.paperprototyping.com/

              --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
              <mvizdos@...> wrote:
              >
              > What is "paper prototyping" ?
              >
              > Why not test an increment of actual working software instead?
              >
              > This can involve the Product Owner and other team members.
              >
              > - mike
              > www.michaelvizdos.com
              > www.implementingscrum.com
              >
              >
              > On 4/25/07, acyment <acyment@...> wrote:
              > >
              > > Hi everyone out there! Do you consider usability tests (e.g. paper
              > > prototyping) should be done by the team or by someone represented by
              > > the PO? Could there be a user story that specifically asks for a given
              > > paper prototype?
              > >
              > > Thanks,
              > > Alan
              > >
              > >
              > >
              >


            • Nicholas Cancelliere
              It s the role of the PO to develop the acceptance criteria for features/stories. Paper prototyping might be one of the ways in which they do this. However,
              Message 6 of 15 , Apr 27, 2007
              • 0 Attachment
                It's the role of the PO to develop the acceptance criteria for features/stories.  Paper prototyping might be one of the ways in which they do this.  However, if I was a PO, I wouldn't do this work in a vacuum.  (We want to be collaborating).  So I would treat the prototyping session as a design or estimation session and try to get someone from the team (likely a QA person or maybe a lead developer) to observe and give me input on what comes out.  I want to make sure I understand the gross estimate and I might need help with writing the acceptance tests, risks, etc... so that I know how to prioritize the feature properly.

                The PO doesn't need to include the team initially - but at some point the ideas have to be presented to them, so you might as well let them be involved from the beginning.

                Nicholas

                On 4/25/07, acyment <acyment@...> wrote:

                Hi everyone out there! Do you consider usability tests (e.g. paper
                prototyping) should be done by the team or by someone represented by
                the PO? Could there be a user story that specifically asks for a given
                paper prototype?

                Thanks,
                Alan




                --
                Nicholas Cancelliere, Austin TX
                "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
              • Robin Dymond
                Paper prototyping is a good idea to use in a project where UI considerations are significant. We are using excel to do a LoFi prototype a UI for a data entry
                Message 7 of 15 , Apr 27, 2007
                • 0 Attachment
                  Paper prototyping is a good idea to use in a project where UI considerations are significant. We are using excel to do a LoFi prototype a UI for a data entry intensive UI. It is working really well. We are not doing UI testing with it, rather using it to define the interaction design and reusability for the data sets. We actually aborted a sprint in part to specifically address this issue. The result really accelerated development, and the team.

                  I would use paper prototyping in every UI project if I could. I would recommend staying a far away from IRISE, a UI prototyping tool. I can lead you to all kinds of problems.

                  cheers,
                  Robin Dymond

                  On 4/27/07, Nicholas Cancelliere <nickaustin74@...> wrote:

                  It's the role of the PO to develop the acceptance criteria for features/stories.  Paper prototyping might be one of the ways in which they do this.  However, if I was a PO, I wouldn't do this work in a vacuum.  (We want to be collaborating).  So I would treat the prototyping session as a design or estimation session and try to get someone from the team (likely a QA person or maybe a lead developer) to observe and give me input on what comes out.  I want to make sure I understand the gross estimate and I might need help with writing the acceptance tests, risks, etc... so that I know how to prioritize the feature properly.

                  The PO doesn't need to include the team initially - but at some point the ideas have to be presented to them, so you might as well let them be involved from the beginning.

                  Nicholas

                  On 4/25/07, acyment < acyment@...> wrote:

                  Hi everyone out there! Do you consider usability tests (e.g. paper
                  prototyping) should be done by the team or by someone represented by
                  the PO? Could there be a user story that specifically asks for a given
                  paper prototype?

                  Thanks,
                  Alan




                  --
                  Nicholas Cancelliere, Austin TX
                  "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)


                • Carey, Ben
                  It s very likely that you should test with both (paper prototypes and real software). It s beneficial to show users prototypes and it s also beneficial to show
                  Message 8 of 15 , Apr 28, 2007
                  • 0 Attachment

                    It’s very likely that you should test with both (paper prototypes and real software). It’s beneficial to show users prototypes and it’s also beneficial to show users software and both result in valuable feedback. Usability testing is often a heavy process, so it’s very likely that you could do external usability testing with working software at internal release milestones or even after individual sprints. This mostly comes down to deciding if enough exists to warrant the cost and potential value of the usability testing.

                     

                    With the heavier usability testing occurring at either end of the sprints, it’s also very possible to do lighter usability testing within the sprints.

                     

                    I would also highly encourage doing usability testing outside of the PO and team members. I would think that you would want to do usability testing on the audience or customers of the software.

                     

                    - Ben Carey

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael Vizdos
                    Sent: Wednesday, April 25, 2007 8:14 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Re: Usability tests

                     

                    Nice... will have to read more (thank you!).

                    From their site:

                    "It's possible to conduct usability tests on real interfaces, not just paper prototypes."

                    So... back to my original question.... why not test on real software? 

                    - mike

                    On 4/25/07, acyment <acyment@...> wrote:

                    http://www.paperprototyping.com/

                    --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
                    <mvizdos@...> wrote:

                    >
                    > What is "paper prototyping" ?
                    >
                    > Why not test an increment of actual working software instead?
                    >
                    > This can involve the Product Owner and other team members.
                    >
                    > - mike
                    > www.michaelvizdos.com
                    > www.implementingscrum.com
                    >
                    >
                    > On 4/25/07, acyment <acyment@...>
                    wrote:
                    > >
                    > > Hi everyone out there! Do you consider usability tests (e.g. paper
                    > > prototyping) should be done by the team or by someone represented by
                    > > the PO? Could there be a user story that specifically asks for a given
                    > > paper prototype?
                    > >
                    > > Thanks,
                    > > Alan
                    > >
                    > >
                    > >
                    >

                     

                  • Ryan Cooper
                    Hi Michael; As I understand it, the primary purpose of paper prototyping is to get feedback more rapidly than is possible by building the real thing before
                    Message 9 of 15 , Apr 30, 2007
                    • 0 Attachment
                      Hi Michael;

                      As I understand it, the primary purpose of paper prototyping is to get feedback more rapidly than is possible by building the 'real thing' before getting feedback. After all, for most teams, making changes on paper is faster than making changes to a real application. This would seem to me to be congruent with agile principles.

                      On my current project, we've seen a lot of thrashing that resulted from the customer team not being happy with the UI of a given feature or page. (Luckily, we worked closely enough with them to get their feedback and refine the feature to their satisfaction within the iteration.) When we started focusing more on paper mock-ups before diving into the code, we saw less thrashing and had a happier customer team.

                      Cheers,
                      Ryan Cooper
                      http://www.onagile.com

                      On 4/25/07, Michael Vizdos < mvizdos@...> wrote:

                      Nice... will have to read more (thank you!).

                      From their site:

                      "It'spossible to conduct usability tests on real interfaces, notjust paper prototypes."

                      So... back to my original question.... why not test on real software? 

                      - mike



                      On 4/25/07, acyment <acyment@...> wrote:

                      http://www.paperprototyping.com/

                      --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
                      <mvizdos@...> wrote:
                      >
                      > What is "paper prototyping" ?
                      >
                      > Why not test an increment of actual working software instead?
                      >
                      > This can involve the Product Owner and other team members.
                      >
                      > - mike
                      > www.michaelvizdos.com
                      > www.implementingscrum.com
                      >
                      >
                      > On 4/25/07, acyment <acyment@...> wrote:
                      > >
                      > > Hi everyone out there! Do you consider usability tests (e.g. paper
                      > > prototyping) should be done by the team or by someone represented by
                      > > the PO? Could there be a user story that specifically asks for a given
                      > > paper prototype?
                      > >
                      > > Thanks,
                      > > Alan
                      > >
                      > >
                      > >
                      >



                    • Nick Xidis
                      We have used paper prototypes with some success. It was initiated by the development team as part of doing a story. In our case, we have a local partner with
                      Message 10 of 15 , May 1, 2007
                      • 0 Attachment
                        We have used paper prototypes with some success. It was initiated by the development team as part of doing a story. In our case, we have a local partner with location that allows several team members to observe behind one way glass. The observers included both the PO and dev team members. During the test session, the facilitator was from the PO's group and the "computer" was a Sr. member of the dev team.

                        Hope this helps.

                        NX

                        On 4/25/07, acyment <acyment@...> wrote:

                        Hi everyone out there! Do you consider usability tests (e.g. paper
                        prototyping) should be done by the team or by someone represented by
                        the PO? Could there be a user story that specifically asks for a given
                        paper prototype?

                        Thanks,
                        Alan




                        --
                          Nick Xidis

                          We are here to make another world. (Deming)
                      • Michael Vizdos
                        So... I could see if this actually *adds value* from the customer perspective; however, when (and it will I think) it becomes, Well we NEED to do a paper
                        Message 11 of 15 , May 1, 2007
                        • 0 Attachment
                          So... I could see if this actually *adds value* from the customer perspective; however, when (and it will I think) it becomes, "Well we NEED to do a paper prototype to show to the customer BEFORE we do anything else.... [insert bla bla bla here]" I'd go back and talk about this decision with your team.

                          - mike vizdos
                            www.implementingscrum.com


                          On 4/30/07, Ryan Cooper < ryan.p.cooper@...> wrote:

                          Hi Michael;

                          As I understand it, the primary purpose of paper prototyping is to get feedback more rapidly than is possible by building the 'real thing' before getting feedback. After all, for most teams, making changes on paper is faster than making changes to a real application. This would seem to me to be congruent with agile principles.

                          On my current project, we've seen a lot of thrashing that resulted from the customer team not being happy with the UI of a given feature or page. (Luckily, we worked closely enough with them to get their feedback and refine the feature to their satisfaction within the iteration.) When we started focusing more on paper mock-ups before diving into the code, we saw less thrashing and had a happier customer team.

                          Cheers,
                          Ryan Cooper
                          http://www.onagile.com

                          On 4/25/07, Michael Vizdos < mvizdos@...> wrote:

                          Nice... will have to read more (thank you!).

                          From their site:

                          "It'spossible to conduct usability tests on real interfaces, notjust paper prototypes."

                          So... back to my original question.... why not test on real software? 

                          - mike



                          On 4/25/07, acyment <acyment@...> wrote:

                          http://www.paperprototyping.com/

                          --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
                          <mvizdos@...> wrote:
                          >
                          > What is "paper prototyping" ?
                          >
                          > Why not test an increment of actual working software instead?
                          >
                          > This can involve the Product Owner and other team members.
                          >
                          > - mike
                          > www.michaelvizdos.com
                          > www.implementingscrum.com
                          >
                          >
                          > On 4/25/07, acyment <acyment@...> wrote:
                          > >
                          > > Hi everyone out there! Do you consider usability tests (e.g. paper
                          > > prototyping) should be done by the team or by someone represented by
                          > > the PO? Could there be a user story that specifically asks for a given
                          > > paper prototype?
                          > >
                          > > Thanks,
                          > > Alan
                          > >
                          > >
                          > >
                          >




                        • Ryan Cooper
                          Hi Michael; I definitely agree it would warrant a team discussion if it drifted into dogma, and fortunately that has not been our experience. The decision to
                          Message 12 of 15 , May 1, 2007
                          • 0 Attachment
                            Hi Michael;

                            I definitely agree it would warrant a team discussion if it drifted into dogma, and fortunately that has not been our experience. The decision to spend more time on paper mock-ups before coding the UI was a pragmatic one, and one the customer team participated in and supported. They saw value in it. We didn't do paper prototypes of all features... only when the customer team didn't have a good grasp on how they wanted the feature to work/look.

                            I admit that I don't see why this choice would be any more vulnerable to a slippery slope to dogma than any other pragmatic decision about how to work effectively. I'm interested in your insight here. Why do you think it will become "we NEED ... BEFORE"?

                            Cheers,
                            Ryan

                            On 5/1/07, Michael Vizdos <mvizdos@...> wrote:

                            So... I could see if this actually *adds value* from the customer perspective; however, when (and it will I think) it becomes, "Well we NEED to do a paper prototype to show to the customer BEFORE we do anything else.... [insert bla bla bla here]" I'd go back and talk about this decision with your team.

                            - mike vizdos
                              www.implementingscrum.com




                            On 4/30/07, Ryan Cooper < ryan.p.cooper@...> wrote:

                            Hi Michael;

                            As I understand it, the primary purpose of paper prototyping is to get feedback more rapidly than is possible by building the 'real thing' before getting feedback. After all, for most teams, making changes on paper is faster than making changes to a real application. This would seem to me to be congruent with agile principles.

                            On my current project, we've seen a lot of thrashing that resulted from the customer team not being happy with the UI of a given feature or page. (Luckily, we worked closely enough with them to get their feedback and refine the feature to their satisfaction within the iteration.) When we started focusing more on paper mock-ups before diving into the code, we saw less thrashing and had a happier customer team.

                            Cheers,
                            Ryan Cooper
                            http://www.onagile.com

                            On 4/25/07, Michael Vizdos < mvizdos@...> wrote:

                            Nice... will have to read more (thank you!).

                            From their site:

                            "It'spossible to conduct usability tests on real interfaces, notjust paper prototypes."

                            So... back to my original question.... why not test on real software? 

                            - mike



                            On 4/25/07, acyment <acyment@...> wrote:

                            http://www.paperprototyping.com/

                            --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
                            <mvizdos@...> wrote:
                            >
                            > What is "paper prototyping" ?
                            >
                            > Why not test an increment of actual working software instead?
                            >
                            > This can involve the Product Owner and other team members.
                            >
                            > - mike
                            > www.michaelvizdos.com
                            > www.implementingscrum.com
                            >
                            >
                            > On 4/25/07, acyment <acyment@...> wrote:
                            > >
                            > > Hi everyone out there! Do you consider usability tests (e.g. paper
                            > > prototyping) should be done by the team or by someone represented by
                            > > the PO? Could there be a user story that specifically asks for a given
                            > > paper prototype?
                            > >
                            > > Thanks,
                            > > Alan
                            > >
                            > >
                            > >
                            >





                          • Michael Vizdos
                            Hi Ryan, Good point about any dogmatic discussion.... it is not just related to paper prototyping. My past experience with (and statement about) cautioning
                            Message 13 of 15 , May 2, 2007
                            • 0 Attachment
                              Hi Ryan,

                              Good point about any dogmatic discussion.... it is not just related to paper prototyping.

                              My past experience with (and statement about) cautioning paper prototypes (or other artifacts) is that a team will fall into the trap of, "Well, we have always done paper prototypes or insert artifact here)."

                              Then the team may start putting up walls for delivering actual software because "we do not have a paper prototype ready, we cannot possibly deliver you working code without doing that first!".

                              That is the slippery slope I am cautioning you (and others) about.

                              Does that make sense?

                              It is kind of like, "well my mother always used this small sized pan versus the larger pan to bake this bread so I will.... and mother says I used it because it tasted better... and grandmother says I used the small pan because that is all that would fit in my wood burning oven...."

                              Thank you,

                              - mike
                                www.implementingscrum.com


                              On 5/1/07, Ryan Cooper < ryan.p.cooper@...> wrote:

                              Hi Michael;

                              I definitely agree it would warrant a team discussion if it drifted into dogma, and fortunately that has not been our experience. The decision to spend more time on paper mock-ups before coding the UI was a pragmatic one, and one the customer team participated in and supported. They saw value in it. We didn't do paper prototypes of all features... only when the customer team didn't have a good grasp on how they wanted the feature to work/look.

                              I admit that I don't see why this choice would be any more vulnerable to a slippery slope to dogma than any other pragmatic decision about how to work effectively. I'm interested in your insight here. Why do you think it will become "we NEED ... BEFORE"?

                              Cheers,
                              Ryan

                              On 5/1/07, Michael Vizdos < mvizdos@...> wrote:

                              So... I could see if this actually *adds value* from the customer perspective; however, when (and it will I think) it becomes, "Well we NEED to do a paper prototype to show to the customer BEFORE we do anything else.... [insert bla bla bla here]" I'd go back and talk about this decision with your team.

                              - mike vizdos
                                www.implementingscrum.com




                              On 4/30/07, Ryan Cooper < ryan.p.cooper@...> wrote:

                              Hi Michael;

                              As I understand it, the primary purpose of paper prototyping is to get feedback more rapidly than is possible by building the 'real thing' before getting feedback. After all, for most teams, making changes on paper is faster than making changes to a real application. This would seem to me to be congruent with agile principles.

                              On my current project, we've seen a lot of thrashing that resulted from the customer team not being happy with the UI of a given feature or page. (Luckily, we worked closely enough with them to get their feedback and refine the feature to their satisfaction within the iteration.) When we started focusing more on paper mock-ups before diving into the code, we saw less thrashing and had a happier customer team.

                              Cheers,
                              Ryan Cooper
                              http://www.onagile.com

                              On 4/25/07, Michael Vizdos < mvizdos@...> wrote:

                              Nice... will have to read more (thank you!).

                              From their site:

                              "It'spossible to conduct usability tests on real interfaces, notjust paper prototypes."

                              So... back to my original question.... why not test on real software? 

                              - mike



                              On 4/25/07, acyment <acyment@...> wrote:

                              http://www.paperprototyping.com/

                              --- In scrumdevelopment@yahoogroups.com, "Michael Vizdos"
                              <mvizdos@...> wrote:
                              >
                              > What is "paper prototyping" ?
                              >
                              > Why not test an increment of actual working software instead?
                              >
                              > This can involve the Product Owner and other team members.
                              >
                              > - mike
                              > www.michaelvizdos.com
                              > www.implementingscrum.com
                              >
                              >
                              > On 4/25/07, acyment <acyment@...> wrote:
                              > >
                              > > Hi everyone out there! Do you consider usability tests (e.g. paper
                              > > prototyping) should be done by the team or by someone represented by
                              > > the PO? Could there be a user story that specifically asks for a given
                              > > paper prototype?
                              > >
                              > > Thanks,
                              > > Alan
                              > >
                              > >
                              > >
                              >






                            • Ryan Cooper
                              That makes perfect sense. Initially I wasn t sure if it was a warning to guard against slipping into dogma in general, or if there was a particular experience
                              Message 14 of 15 , May 2, 2007
                              • 0 Attachment
                                That makes perfect sense. Initially I wasn't sure if it was a warning to guard against slipping into dogma in general, or if there was a particular experience with paper prototypes that you were alluding to. I agree that although sometimes it can be helpful to do things in a certain order, we always have to keep an eye on ourselves and make sure we only do it if and when it is helping. "Because that's the way we do things here" is always a dangerous reason for any practice. :)

                                Thanks for the clarification!

                                Cheers,
                                Ryan

                                On 5/2/07, Michael Vizdos <mvizdos@...> wrote:

                                Hi Ryan,

                                Good point about any dogmatic discussion.... it is not just related to paper prototyping.

                                My past experience with (and statement about) cautioning paper prototypes (or other artifacts) is that a team will fall into the trap of, "Well, we have always done paper prototypes or insert artifact here)."

                                Then the team may start putting up walls for delivering actual software because "we do not have a paper prototype ready, we cannot possibly deliver you working code without doing that first!".

                                That is the slippery slope I am cautioning you (and others) about.

                                Does that make sense?

                                It is kind of like, "well my mother always used this small sized pan versus the larger pan to bake this bread so I will.... and mother says I used it because it tasted better... and grandmother says I used the small pan because that is all that would fit in my wood burning oven...."

                                Thank you,

                                - mike
                                  www.implementingscrum.com


                              • Adrian Howard
                                ... [snip] Another benefit of paper prototypes is that users don t confuse it for the final product. You can get a very different kind of feedback from some
                                Message 15 of 15 , May 6, 2007
                                • 0 Attachment
                                  On 30 Apr 2007, at 22:48, Ryan Cooper wrote:

                                  > Hi Michael;
                                  >
                                  > As I understand it, the primary purpose of paper prototyping is to
                                  > get feedback more rapidly than is possible by building the 'real
                                  > thing' before getting feedback.
                                  [snip]

                                  Another benefit of paper prototypes is that users don't confuse it
                                  for the final product. You can get a very different kind of feedback
                                  from some scribbles on a piece of paper than you do from something
                                  that looks "finished".

                                  That said I do find myself doing less paper prototyping these days,
                                  and moving to real code very quickly.

                                  Cheers,

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