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

Re: Prototyping Tools

Expand Messages
  • machappy553
    ... Oh yes. Couple fronts. For roughly the same amount of designer time (really), you can have something the moves and feels alot like your application (or
    Message 1 of 43 , Jan 15, 2008
      --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>
      wrote:
      > Could you talk a bit more about where/why you've found Axure better
      > than paper prototyping?

      Oh yes. Couple fronts. For roughly the same amount of designer time
      (really), you can have something the moves and feels alot like your
      application (or parts of it) to send up to product owners and to put
      in testing.

      We have found prototypes show us interaction problems and poor button
      placements and missed expectations alot better. Users can actually try
      out an Axure prototype vs. staring and speaking about a paper one.
      This moves testing up WEEKS and WEEKS sometimes...so we have a chance
      of getting big problems into future iterations or even sometimes
      dismissing them ahead of development.

      When our UX group gets directives from product owners, it's pretty
      vague. The Axure prototypes allow us to spend an hour or two
      translating whiteboard conversations with them into a prototype and
      sending back up so the product owner can feel what they are requesting
      or what you are suggesting...it completely removes the churning ball
      of fish that was previously sent into engineering for development (and
      then sent back up much later in the game when product owners flinch
      over making big changes).

      Then, we've had very positive response from engrs on them. Big nasty
      spec (or trickles of documentation within sprints) vs. moving, mostly
      working prototype? They actually ask for a prototype now over
      documentation and you get smurfy questions like "I know you want it
      work move like this, but our controls permit...what do you think
      about..." over "*flips pages*...so how did you want this to work
      again?"

      I still do documentation (Axure has a "getting better" mechanism for
      this) - but it's alot less and more in response to
      iterations/revisions.

      The bottomline is that we get ALOT more feedback from working
      prototypes than paper ones and we have alot more visibility into the
      major issues in design. We also cut alot of the waffling and revisions-
      in-engring off.

      I am sure there are other tools (product owners were looking into 5
      digit documentation systems when we were pushing for Axure), but we
      found the price point something we could move through and the tool
      quick enough to use in an iterative manner with a very small UX team
      (there's <> 3 of us and > 30 engrs, so we cannot be decided to a
      single project in an iteration).



      > Could you talk a little bit about why being several sprints ahead of
      > engineering is useful?
      >
      > Adrian
      >

      I think someone already responded to this in the same way I would
      (Jeff - could posts down). Depending on the size of the product, we
      try to work ahead on the *major* stuff. (we did try to start desing
      and engr in the same sprint several times and UX felt they had to make
      hasty decisions and engr just generally hated it and got through alot
      less).

      Working ahead (if only slightly) allows product owners, UX, engineers,
      and assorted stakeholders to be on the same page about the big picture
      before it goes into engr. The "move this here and try this there" has
      been lifesucking to engrs in my experience and so if we have the
      general idea (and it has been tested) prior to engineering, we get
      alot more traction on the iterations we do need and get alot more
      features in vs. waffling on interface (and interation) opinions. Then
      in interactions, we can do smaller bits of testing on single features
      and actually get traction on those vs. still testing for proof of
      concept.
    • Brian Weiss
      First off, I d just like to say I love reading all the opinions out there as I m on an island here... So have we reached violent agreement yet? :D Considering
      Message 43 of 43 , Jan 17, 2008
        First off, I'd just like to say I love reading all the opinions out there as I'm on an island here...
         
        So have we reached violent agreement yet? :D
        Considering there are myriad ways to present wireframes and flows...whatever works for you, well, works for you. So far, at this place I'm at, user studies done with Flex/Flash based prototypes that look close to a branded/finished product have worked very well. The feedback has been excellent and it seems quicker to me to get the users focused and into the scenarios. That said, and again for me, the paper wireframes have been better at getting business requirements on the table with Stakeholders and other internal partners as they get hung up on the interface of the prototypes too much. The nice thing about alternatives is you can try them all...
         
        We all did get a good laugh out of the Flex "paper" skin Frédéric Monjo mentioned: http://fleksray.org/skins/edding/Edding.html and actually might try it out.
        And if a Stakeholder asks "Is this what we're getting?" I've decided to say "Yes. Yes it is."
         
        -Brian

        ----- Original Message ----
        From: Fred Beecher <fbeecher@...>
        To: agile-usability@yahoogroups.com
        Sent: Tuesday, January 15, 2008 3:39:08 PM
        Subject: Re: [agile-usability] Re: Prototyping Tools


        On 1/15/08, thomas lissajoux <thomas@systemesagil es.com> wrote:

        I think we're getting back to what Brian Weiss mentioned at
        the beginning of this thread : having hi-fi prototypes too often
        leads to stakeholders pointing to differences and details in
        production work.

        So this leads me to some other question ?
        What does prevent user experience testing to be conducted with
        paper prototypes (+ trend boards + visual identity sketches) ?

        My own opinion : not much.

        If you're doing a highly interactive site with a lot of rich interactions, you're missing a whole lot. If you're just doing a standard Web page where you click from page to page, then you wouldn't be missing much.

        Interactive (notice how I didn't say "high fidelity"... I'll get to that in a bit) prototypes yield much more accurate information in user testing of Web sites that rely on rich interactions. Why? Well, it's all about context. Paper is NOT the context rich interactions are meant for, and people will correspondingly be confused. For simple Web sites, it's close enough. If you really want to know whether a rich interaction is usable or not, it needs to be in an interactive format if you want to get reliable, actionable data from user testing.

        Responding to your musings about hi-fi prototypes.. . I think that fidelity is only *one* aspect of a prototype. *Interactivity* is the other. You can have a lo-fi interactive prototype, which is typically what Axure produces... essentially interactive wireframes. You can also have hi-fi prototypes that are low on interaction, such as printed JPGs. In my experience, I've found that stakeholders respond to lo-fi interactive prototypes pretty much as they do wireframes. I have been in some situations, however, where the interactivity was communicated much more effectively than in wireframes, which led to constructive feedback from stakeholders *pre* development.  

        - Fred



        Never miss a thing. Make Yahoo your homepage.
      Your message has been successfully submitted and would be delivered to recipients shortly.