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

Re: [scrumdevelopment] Re: Usability tests

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