There are a couple ways to approach contract design work ( a studio
or agency working from the outside of the firm or client) and thus
protoyping.
In the first, you actually put the client, or someone from the client
firm on the design team as a product manager and as a proxie
contributor for the client. In this case, you will typically share
rough ideas, sketches and less defined prototypes with them. This is
by far the better approach (IMO) if you have the chops, the staff and
the ability to present. Also... there are clients out there for whom
this will not work.
The other approach is more agency-ish. The approach takes the
position that we (the designers) are the experts. We will show you
finished product... we will not bother or indulge you with our
process or the in process steps. This is a very high risk approach...
it leverages posturing, reputation and market position... and send
you a long ways down the road of solution with out client check in.
With this approach... deliverables are crucial. Let me say that
again... deliverables are crucial... your account relationship will
live or die based on delivery of prototypes, presentation materials,
documentation, standards and such. They must be very slick, very
polished and all of the details must have been really thought out an
executed. You can easily get way down the road on a solution that is
out of sync with the client. Account management skills become very
important.... potentially more important that design skill. This is
also a very expensive approach and (again IMO... and experience) does
not typically render optimal design solutions.
I have participated and directed design in both approaches. My
preference is obvious... mostly because I prefer to slightly
understate and way over deliver.
Mark
On Mar 1, 2009, at 3:02 PM, Todd Zaki Warfel wrote:
I think one of they keys here is that Andrei's perspective on
prototyping is very different from the majority. That's not to say
it's strictly right or wrong, but I find it a bit myopic, narrow,
and shortsighted. It seems to be very 37signals—this is the way we
do it and it's really the only way that matters.
Full disclosure—almost every prototype my company produces is a
hand-coded XHTML/CSS/JavaScript prototype that is production level
code. In fact, probably very similar in fidelity to what Andrei's
company produces. However, that is fairly unique in the field and
not required. We do it, because it's typically part of the goal
that's established at the beginning of the project.
However, we do some very advanced paper prototyping a few times a
year, typically when a client hands us a pre-existing set of
wireframes. Additionally, when all the client has is a few
photoshop comps and wants to test some basic flows with that, we'll
either use PPT, or stitch them together with HTML—far from fully
functional, but very effective for testing what we need and
accomplishing the goal.
When I speak on or teach prototyping, I do let people know that we
typically build production level prototypes, but that that is not
the norm and not required to be an effective prototyper and I can
back that up with data.
So, realistically, I can say with certainty that Andrei's
perspective, or at least the one that's being communicated here, is
not the standard and does not represent prototyping. That's not my
opinion, that's something that I can back up with dozens upon
dozens of examples.
Out of curiosity, Andrei, where would you put tools like Axure,
iRise, or Catalyst for prototyping? Waste? Beneficial? Where do you
draw your line?
Cheers!
Todd Zaki Warfel
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
