Re: [agile-usability] Prototyping Tools
- I've been doing analysis and requirements work for a long time (since the early 90's) and dealing with mis-directed client expectations is far, far worse than dealing with developer's ideas about the GUI. Developer miscommuniocation can slow things down but clients can end the project. That is why I avoid doing or advocating polished mock-ups, wireframes or prototypes. I stick to whiteboards, pen & paper, and my favorite tool for getting a picture into a Word doc, Excel. (You can even give them the whole workbook with links between pages so they can "click" through an example and see representative transitions.)
Marjorie H. Pries
Support Manager / Utility Infielder
Brian Weiss <briandweiss@...>
Sent by: email@example.com
01/09/2008 12:36 PMPlease respond to
firstname.lastname@example.orgSubject Re: [agile-usability] Prototyping Tools
Since we're a Flex shop, making "usable" prototypes is pretty easy - almost as easy as making clickable pdf, visio or whatever. I equate Flex to something like iRise in parts. Nice thing about the Flex process is the containers are then easier to hand off to developers as living wireframes.
That said, traditionally for me, having a hi-res version has sometimes been a real drag as Stakeholders immediately assume "this is what I'm getting". It's very difficult for them to understand that "no, this is a prototype for testing and discussion only".
Balancing act I guess.
----- Original Message ----
From: Adrian Howard <adrianh@...>
Sent: Wednesday, January 9, 2008 5:12:48 AM
Subject: Re: [agile-usability] Prototyping Tools
On 9 Jan 2008, at 03:09, Bob Sarni wrote:
> Do any of you have experience or thoughts on the use of web based
> prototyping tools (Simunication, iRise, other) to create hi-fi
> prototypes as input to product backlog items, product owner,
> development team?
> Good thing? Bad thing? Will the tool constrain the team too much and
> limit their creativity?
It depends :-)
Who's creating them? Why? Why do that instead of a paper prototype,
or a whiteboard sketch, or real software?
My general experience has been that hi-fi prototypes are not the best
way to use the teams time. The extra time spent producing something
"hi-fi" doesn't actually get you better feedback or save you time.
Much more effective to get rapid feedback with things like paper
prototypes and then get a slice of the real application up and
running quickly for testing.
Very, very occasionally I'll find some piece of complex UI that needs
testing, doesn't really work as a paper prototype, and is _much_
cheaper to implement as a prototype in (say) Flash than it is to
implement in the target domain. That's the only situation where I
find hi-fi prototypes help.
In these cases I treat it in the same way as a code-spike (discuss it
with the Customer, agree a timebox for implementing the prototype and
write a spike story so we now what the goal is, do the work in the
Never miss a thing. Make Yahoo your homepage.
- 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.