Re: Prototyping Tools
- --- In email@example.com, Adrian Howard <adrianh@...>
> Could you talk a bit more about where/why you've found Axure betterOh yes. Couple fronts. For roughly the same amount of designer time
> than paper prototyping?
(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
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
I still do documentation (Axure has a "getting better" mechanism for
this) - but it's alot less and more in response to
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-
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 ofI think someone already responded to this in the same way I would
> engineering is useful?
(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
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
- 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? :DConsidering 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@...>
Sent: Tuesday, January 15, 2008 3:39:08 PM
Subject: Re: [agile-usability] Re: Prototyping ToolsOn 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
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.