One of the unexpected but incredibly valuable discussions that came out of the “protoFarm” workshop we put on a few months bask was the debate about decisions about prototype fidelity. My take on it, as I stated in my earlier post about lightweight prototyping is….. it depends. You should be asking yourself that question while keeping several things in mind:
.Define your goals
Where are you at in the project cycle? Delivering wireframes, testing the UI, conveying transitions, etc? Whatever the goal is, the point is to think about what you need to convey to the client or to your dev team and focus on the best solution for the milestone in front of you.
.But…. what tool? There’s so many to choose from
I tend to use clickable prototypes built in Adobe InDesign for expediting wireframe review and providing developers with and interactive design spec. There’s a slew of other options including HTML, Flash, Axure, iRise, Fireworks, OmniGraffle and wait for it……good ol’ pen & paper.
Do you need a platform that generates specifications from the prototype and provides built-in collaboration? If so, then perhaps Axure is the tool for you.
If you don’t need those integrated features, then you can look at thinner solutions like InDesign, Fireworks or OmniGraffle.
If you’re kicking off a project then nothing works better than pen, paper and a healthy supply of your favorite caffeinated beverage.
Regardless of the tools I’ve listed and missed, the point is that you should set a goal for yourself to understand your project and client well enough that you have a good feel for, at a baseline:
A) Context
B) Your skill set
C) Budget
D) Client Type
People & Things Interacting with Stuff 
November 12, 2009 at 5:41 pm
I love the fact that the number one thing to consider when talking tools is context. When putting together a team for a project, questions like who knows photoshop, axure, fireworks, whatever don’t really matter. Prototyping is prototyping, and it’s best to use a tool that supports both the environment (technical and/or corporate) and context the project exists in.
Awesome post!
November 12, 2009 at 5:59 pm
Thanks Brad!
November 12, 2009 at 7:55 pm
Totally agree with you, Chris. Prototyping is a very important phase of the project lifecycle and the level of prototyping really depends on the project size, level of project risk and most important, what type of client are you working with. If your client uses key phrases like. ” I need it to wiz across the screen”, its better to create a light-weight prototype that shows that behavior of his vision to help clearly demonstrate that you and client are on the same page. And to do this before the development team wastes 100s of hours building the real app before getting client feedback. From many recent experiences, change behavior logic is not trivial and takes hours and hours of refactoring.
My opinion is, now that interaction is so prevalent in the apps we are building, prototypes need to be leveraged to illustrate the vision to a client before 100% of the development has been finished. When we development Adobe WorkflowLab, this was exactly what Doug Winnie at Adobe provided all of us (you included). A simple prototype in Flash Catalyst (that only took him a few hours) that conveyed his vision for interacting with tasks. It wasn’t full featured, but it showed tasks moving, resizing, and selection. One look at the prototype and we (the development team and you the designer) got his vision.
November 12, 2009 at 8:09 pm
I feel the key here is your section on defining goals. Understanding your target audience’s needs (albeit the budget stakeholder, your design team, your development team, etc.) is critical. Fidelity for a functional reference prototype is not nearly as important as fidelity for a holistic style prototype used to reflect the clients new/updated ascetics. With the functional reference example, you are attempting to prove the feasibility of a technical challenge, so using an unskinned or wireframe based UI is perfect. Yet, for something that is driving future design interactions, look and feel with a polished look is critical.
Another other issue to keep in mind about your target audience, when making these kinds of choices, is their level of “expertise”. I don’t mean this in solely a technical way, but more around the level of understanding they have. When defining interactions, you may have a development team that understands your notes that say “it swooshes in from here” or you may need to take the extra time to fire up Flash and create the interaction to demonstrate your vision. This also applies to clients, they may need to see the candy bar beauty to get your ideas, or they can look at a roughed out IA wireframe and see your vision clear as day.
Although, too much fidelity can become a huge problem with prototypes. The main issue I have seen over the years with high fidelity prototypes is that the final deployment may not meet the customer’s vision that was established early on. On one project the design had full screen HD video in the background and it look amazing in the prototype. The client loved it and was sold. The issue was that it wasn’t technically feasible to have the video, plus interactions, data loading, etc. all at the same time. Another example is the demo prototype interactions running like a champ on the desktop, but once ported to the actual deployment device (in this case a mobile phone) the processor just couldn’t make the effect work. Yet the client expected the effect and the team had to spend a lot time setting client expectations around the changed experience.
Fidelity is a tough one to judge due to all the possible inputs/outputs required for the success of the prototype. Definitely good food for thought Chris!
November 13, 2009 at 4:38 pm
Enjoyed your post, as a professional prototyper, I look to use the tools that get the prototype built fastest. However, part of understanding of what you need to build quickly is an important component. One of the keys in good prototyping is understanding the true goals of the client and of the prototype. Granted, these may not always be easy to discover or understand, but are critical to the success of the prototype. Let me illustrate some of these: One issue that I find that happens during prototyping is the pressure to make the prototype unnecessarily ‘real’. But does the task that you are exploring require it? If the answer is no, then it does not belong in the prototype. The other key to a successful prototype is understanding where changes can occur. This is where good engineering can come into play, coding good “spaghetti code” to allowing the designer the ability to explore. But if you don’t, the areas of interest or the why the interest, you can code yourself into a corner.
But so often that simple prototype has quickly turned into a full-fledged simulation, thus negating rapid exploration of new ideas and concepts. Now simulations have their place: user testing, prototyping longer complex tasks, sales demos, and even reference implementations. These higher fidelity simulations carry that risk that James points out of “Oh, this looks done, lets ship it!”
For me it still comes back to finding the right tools for the right task at hand.
November 13, 2009 at 9:38 pm
Hi Chris!
I see three basic goals that a prototype can help you accomplish: exploration, validation, & communication. And to me, fidelity is the aspect of a prototype that has the most impact on what types of goals a given prototype can help you achieve. But here’s the thing, fidelity is multi-dimensional.
The two main dimensions of fidelity are visual & functional. Varying the fidelity of a prototype along one or both of those dimensions can make a prototype more or less useful for a given goal in a given situation. I can literally talk for hours about this sort of stuff, so I’ll save you the novel & just like to the Boxes & Arrows article. : )
http://boxesandarrows.com/view/integrating
F.