>> Now, there's one statement Andrei H. made that I have to not simply >> disagree with, but claim outright disproof of: >> >>> What I can tell you is that a prototype can't be simple wireframes >>> or flow diagrams or the like. >> >> In over twenty years, and dozens of successful and complex projects, >> ranging from room-sized machines, to OS GUIs, to handheld and >> wearable devices, to medical systems, military devices and systems, >> financial software, interactive television systems, and more, >> ninety-nine percent of my design work and iterative tools have >> consisted of just storyboarded thumbnails and wireframe diagrams. > > 99%? So you delivered no final artwork, icons, spec'd layout or > documentation on how the product works ever? I think you're being coy > with me, Jim. 8^)
The key phrase in my post were "design work and iterative tools," not
final implementational resources and specifications. That is, the
full-scale, implementable resources, interactional functional specs,
and everything necessary to program it all down to every single unique
interaction and patterned behavior. Those I do concurrently, but are
separate from the smaller, thumbnail storyboards (which are still
full-detail) and wireframe flow diagrams.
This isn't theory. I have dozens and dozens of volumes, both of the
iterative development itself as well as the final documentational
architecture and final resources.
> By the way, I'm not sure how what I said translates to not using > wireframes and storyboards. Far more preferable tools by me than other > tools. All I did was set parameters for a prototype is not in the > context of my message. IOW, if you use just wireframes and > storyboards, great, go right ahead... Just don't call them a prototype > while I'm in the room because I'll disagree with you in front of > everybody. 8^)
I use them as shorthand to speed up iterative exploration, and to more
efficiently discuss the larger-scale patterns in my interactional
architecture. I'm not really one for labels, and generally, there are
parts of the actual product or system being designed by halfway through
the design process, so we're beginning to see portions of the
architecture in action, but within the actual environment itself. The
discussions between myself and the engineers (and others), then
generally takes place around the printed documentation, which is quite
dense and detailed, both in terms of the interactional elements, but
also in terms of my notes and reasoning.
>> I couldn't count the number of projects where I didn't have an >> opportunity to physically interact with the system until it was >> manufactured.... and then went on to win numerous design awards for >> its design and usability, and great economic and usability success in >> the global marketplace. > > Ok... seriously. I think I know what you are saying, but this > statement makes it sound like you basically let someone else do all > the final design work for you. I know that's not what you mean, so > maybe you might want to clarify it a bit more?
In the vast majority of my projects, I've done everything all the way
to the final implementable graphic resources (or shared some of that
work with a partner), and in some instances the layout and ergonomics
of the physical device form. What I meant is that in many products,
particularly those where the developmental cycles were extremely
compressed, I never had an interactive prototype in my hands prior to
getting back first article case shots, and loaded with the first
electronic components off the line.
>> Also, I have the ability to envision and play out interaction in my >> head. I guess this isn't a universal capability, but I'm certain >> that many have that ability because I've met them. > > Define "many."
Well, given that field-wide dogma continually repeats the factoid that
it's *impossible to begin with*, almost any number would be "many"
comparitively speaking. I wouldn't be surprised if 20% could use this
approach, if educated via apprenticeships (as opposed to "schooled" in
methodologies). They would have to do the same complete mappings of
their interaction on paper, however, in order to work with the
This may illuminate a difference between areas where an interactive
prototype is much closer to the actual product itself (i.e.: a
website), than the type of physical products and systems I generally
work on. In the product world, many times designers or design groups
will produce an interactive prototype, but *fail* to really get down
into the specific details of the interaction. In other words, it's not
a fully-refined prototype, but rather one used to "get across" the
nature of the interaction (either so they can grasp it themselves, or
so they can test their assumptions, or communicate). While a valid
approach, it's not the only approach. And it's not the most powerful
tool for making certain that in the end, the final embodiment is *as
close as possible to exactly as the architect designed it.* That's
what I'm after, and have been able to achieve in a wide range of
software and products.
>> Bottom line here is that I mostly object to people saying something >> "can't be done" or "has to be done this way." I'm not claiming that >> everybody can design the way I do, but I am saying that it's >> possible, and have proof of its advantages and successes. > > To lighten the mood... I'm not claiming that people should design the > way I do or it has to be done a certain way. However, I will claim > that if we go head to head with an employer or a contract job, and > they see how my process works as opposed to what you've just > described... I'm willing to bet I'll win the contract. 8^)
Ahahaha! Lighten the mood, indeed. Can we have a rimshot here?!
Seriously though, I doubt we're competing for the same type of
projects, or at the same level. I do sometimes lose out to consultants
with lower rates though, so don't give up hope. 8^)
>> Some would say that interactive mockups are necessary as persuasion >> tools. This may hold for some, or even most people. Personally, I >> just push it through with my own force of personality. > > Imagine how large that cult of personality would be with a well formed > prototype behind it. Having had drinks with you, I know both our egos > can easily fill the room. I'll just be packing a larger gun than you.
You like to talk the talk. Have you walked the walk? I know you were
at Adobe. After 17 years, I'm able to use their software a *little bit
easier and more powerfully* than was possible originally. How long
have you been consulting? How many projects have you completed, and
documented the results of? What range of projects have you covered,
Andrei? Maybe I'm just not familiar with your entire oeuvre.
I don't exactly know what the point of continuing this thread would be.
I'm sure everyone else has grown bored long ago. I just wanted to
make a proven statement about what *is* not only possible, but has been