Re: [agile-usability] Prototyping Tools
- Hi All,
I'm a newbie to this group but have been reading with interest the varying opinions on primarily prototyping tools. We like to think we're an Agile shop, but we're tiny and so we can't implement some of the agile methodologies, namely pair programming. However, we do test-driven development, write stories, estimate stories and let the "customer" set the priorities. We've also recently implemented usability testing and prototyping. Our main objective is to develop products in-house that we can sell/distribute, rather than do contract development work for others. So we are our own customers, but identifying the real customers and their needs is the challenge.
Where would we be without usability testing in the design process? Spending a lot of money building stuff that may or may not work!
Our other challenge is that we ourselves are distributed, not only living in separate cities but in different countries and time zones. Wow, this makes it more interesting. We also have a variety of skills from highly technical to not at all, so at first we were very attracted to the concept of paper prototyping. But they are darn hard to share and brainstorm over, fighting with technologies like scanning and faxing to move paper about. So at first we tried cutting/pasting images of controls, fields, etc., with considerable time and frustration because it's a lot of work and you need to fiddle a lot to get it right, just to change it as a result of testing. I downloaded the demo Axure Pro and to my delight managed to get a workable prototype happening in no time at all. I could very quickly create a high fidelity, interactive prototype to share with the others so they could also go out and test. And I could rework it very quickly, probably much faster than I could do on paper, and redistribute to the team. Others at the business end could undertake testing and design suggestions, and the programmer could keep tabs on what was happening and provide input as well without much overhead.
Re agile, by being able to develop quickly and easily the prototypes, we were able to "build" the front end of the system's design so we knew what was more and less important. Like a combination of market research and user testing and product design! Then when we felt we were "done" we developed the stories and prioritized them. Some were pruned back and others padded out depending upon the estimates, but the basic design remained. And we've got the confidence that we got the usability mostly right (never perfect!).
Being distributed and more comfortable with a keyboard than pen/paper led us to searching for, and finding, a high fidelity prototyping tool. But that's our particular situation and the postings on this list just go to show that different things work for different types of people and differing situations.
Ron Jeffries wrote:
Hello, Brian. On Thursday, January 10, 2008, at 1:37:36 PM, you
> In the end, I've worked with damn near every software dev
> methodolgy there is, and they all are
> the same.
Maybe you've just done one methodology and called it different
This is how I develop software.
Take the parts that make sense to you.
Ignore the rest.
- 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.