prototypes are software and belong to engineers?

13 Feb 2008 - 4:19pm

Last reply:
7 years ago

35 replies

910 reads

Dave Malouf

2005

I was reading that transcript that Gabriel pointed to earlier today: (link:
)

here is the last question's answer:
"Coop[er]: Bad idea. Prototypes are software. I believe that there's a role
for prototypes in interaction design, but I believe it's a very small and
limited role. It's primarily done as a narrative, not as software. The risk
of doing interaction design in a medium of code is much greater than the
benefits yield for you. We as competent craftspeople should be able to
communicate with great precision and clarity what we intend the software to
do without resorting to code.

Code is a sledgehammer here. Prototypes are code that has not achieved
released. Snippets of disposable code are great tools for design engineers,
but they don't play a large role for interaction designers."

Alan since I know you're here. ;) i wonder if you can expand on this a bit.
I trust you have good reasons and experience for this, but it goes counter
to my own both in IxD and in ID. Maybe I'm reading to much in certain spots.
But I'll posit that doing interaction design w/o creating interactions in
some form is akin to doing visual design w/o using color (but expecting
color in the final solution, saying that the printer will handle it). Now
that I put that out there, I'm curious.
What I'm not interested in, is the education component. I'm assuming that
tools are or will be easy enough and good at hiding real code that the
skills to acquire this craft is not an issue.

Comments

13 Feb 2008 - 4:32pm

Christopher Fahey

2005

David Malouf wrote:
> But I'll posit that doing interaction design w/o creating> interactions in> some form is akin to doing visual design w/o using color (but> expecting> color in the final solution, saying that the printer will handle it).

I hope this doesn't re-open the old 'debate' with Andrei Herasimchuk
over what constitutes a "prototype".

It sounds like Alan and Andrei would both be in the "a prototype is a
deeply functional version of the final product" school, whereas you,
David, might be more thinking that a prototype can be a dumb, flat
simulation of the final product -- perhaps with some interactivity,
but not enough actual coding to warrant, say, a hard core programming
team.

Which is to say a prototype to test the user experience, not a
prototype to test the engineering challenges.

>>> I hope this doesn't re-open the old 'debate' with Andrei Herasimchuk> over what constitutes a "prototype".

Only if you want it to by invoking my name when I was actually going
to let it go... 8^)

I can tell you this: The talk given by Jonathan Arnowitz and crew at
the BayCHI/IxDA talk at Google last month using the example of using
Microsoft Excel to "draw" screens is not a prototype. Their talking
points about prototyping were fine, but the means they used to show
"prototyping" was way off base imho. If anyone in the Bay Area wants
me to give a talk on what I mean by prototyping -- going into full
detail the various fidelity levels, ease of construction, use a
design tool, inexpensiveness, iteration, etc. -- I'd be more than
happy to do so.

Beyond that, I'm also waiting to hear Alan's explanation of the same
excerpt that Dave posted. I read the transcript yesterday and I was
kind of shocked to read that last bit. My only guess is that Alan is
referring to the traditional engineering use or definition of a
prototype, where code is written by engineers and used to exercise
functional aspects of a product before full engineering commences on
the feature. If Alan is thinking of or referring to that sort of
thing, then I would absolutely agree with him.

But there are levels of very high fidelity prototypes in the software/
web world that are design prototypes; fast to build, easy to iterate
on, extraordinarily useful in making detailed, final design
decisions. These are more akin to the kind of prototyping Henry
Dreyfuss describes in "Designing for People."

> It sounds like Alan and Andrei would both be in the "a prototype is> a deeply functional version of the final product" school, whereas> you, David, might be more thinking that a prototype can be a dumb,> flat simulation of the final product -- perhaps with some> interactivity, but not enough actual coding to warrant, say, a hard> core programming team.

I can't speak for Alan, but what I gathered from his keynote is that
anything short of the final shipped piece is a prototype, and I'm
inclined to agree. Although, I've seen companies ship prototype
software as the product piece, but that's another story.

> [...] We as competent craftspeople should be able to communicate> with great precision and clarity what we intend the software to do> without resorting to code.[...]

The operative word here is "should." In the 15 years I've been
designing interactions, most of it has been done w/o writing a single
line of code. I've been able to show and describe most interactions w/
o coding.

In practice, however, that's recently changed. I probably still could
do it w/o writing any code, but I haven't been. In the past 9 months,
I haven't done a single wireframe. That's right 0. Instead, I've been
prototyping.

Agreed but whether you choose to prototype or wire frame will ultimately be
defined by your needs, workflow, audience, project or application and of
course, time.

I spent a lot of time wire framing and generating annotated specs. Yet,
that's completely dictated by the type of projects I work on now, our
internal workflow and the scant time I usually have available.

However, at my last job, I found myself spending more times doing prototypes
because I had smaller projects, more time available and my audience was
primarily non-technical folks who found it easier to understand how things
worked by having something they could play with.

As for writing code - it shouldn't be necessary unless you're doing
functional prototypes using a tool or application that requires it. For ex:
using Flash to simulate interactivity vs. an application that can simulate
one, etc.

> Here's the key piece I took away from this:>> > [...] We as competent craftspeople should be able to communicate> > with great precision and clarity what we intend the software to do> > without resorting to code.[...]>> The operative word here is "should." In the 15 years I've been> designing interactions, most of it has been done w/o writing a single> line of code. I've been able to show and describe most interactions w/> o coding.>> In practice, however, that's recently changed. I probably still could> do it w/o writing any code, but I haven't been. In the past 9 months,> I haven't done a single wireframe. That's right 0. Instead, I've been> prototyping.>>> Cheers!>> Todd Zaki Warfel> President, Design Researcher> Messagefirst | Designing Information. Beautifully.> ----------------------------------> Contact Info> Voice: (215) 825-7423> Email: todd at messagefirst.com> AIM: twarfel at mac.com> Blog: http://toddwarfel.com> ----------------------------------> In theory, theory and practice are the same.> In practice, they are not.>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://www.ixda.org/unsubscribe> List Guidelines ............ http://www.ixda.org/guidelines> List Help .................. http://www.ixda.org/help>

I'm currently taking a welding class. To learn how to weld, I am
making lines of weld-bead on sheets of scrap aluminum. This is a very
useful pedagogic device.

After a couple of years of practice and training (assuming I were a
young person making a career out of welding), I'd go into the world as a
journeyman welder. I would never, ever make lines of weld-bead on sheets
of aluminum again, since it has virtually no practical purpose.

About two-thirds of the need for prototyping is as an equivalent,
pedagogic tool. Young interaction designer trainees need to see how
humans react to their designs, and prototypes are an excellent tool for
that. Once you've learned how humans react, you no longer really need to
actually, physically test your designs. Your experience will tell you
just as dependably.

The other third of the need for prototyping is for invention, a very
rare occurrence. Invention means pure, new, never-before-seen modes of
behavior. A couple of years ago, for example, I was working on an email
program where individual conversations (threads) were represented by
icon-like images. Those images were "orbited" by related messages,
images, files, correspondents and other relevant information. Nothing
like this had ever been done before, so prototyping was appropriate.

But please understand that invention is not the same thing as design.
Prototyping is useful in invention, but its role isn't for design as
much as it is for raw exploration of the subject matter before design is
even necessary. Such a prototype would then be used as a guide for
subsequent design (on paper, not in code).

Historically, software comes from a world rich in invention, and the
enormous egos in the software business still imagine that invention
dominates. Most programmers and most interaction designers think that
they are inventing when they are creating yet another eCommerce website.
The cries for and claims of innovation are evidence of that. But the
overwhelming quantity of what I see in the world of software today
simply isn't invention but is the basic block-and-tackle,
three-yards-and-a-cloud-of-dust form and behavior design like we all
learned in school or on the job. Their users are consumers or business
people doing simple, business or personal tasks using well established
idioms, typically implemented using off-the-shelf components arranged in
very conventional ways. Recent "innovations" such as YouTube and even
Crowdvine simply don't show any interaction innovation. Good, solid,
workmanlike design, yes; prototype worthy innovation, no.

Before interaction design gained its contemporary respect, old-school
HCI practitioners claimed emphatically to me, "I learned so much when I
did user testing!" Of course you did. You never had any design training
so it was a complete shock to you when you saw how humans reacted to
software. Today, it is unconscionable for a professional interaction
designer to NEED to user test anything but the most advanced, obscure,
never-before-seen interaction. And prototyping is very time and money
intensive, particularly so when compared to what well trained designers
can do with a couple of 90-minute interviews and a whiteboard.

Please remember that prototype code is subject to the law of fools:
they see it and they think you can SHIP IT! And then WE are stuck with a
commitment to a non-optimal strategy. Why take that risk?

You know, I don't really care anymore whether or not interaction
designers prototype or not. I took a clear and bold and absolute stand
against prototyping 15 years ago to make a point: that we can do good
design without code. This was a necessary decoupling to allow the
profession of interaction design to separate, differentiate, and elevate
ourselves away from programming.

Well, we've accomplished that goal, as Interaction08 proved beyond a
doubt. And now that we are indeed separate, different, and elevated,
there isn't a big downside to prototyping. Mainly it's like using a
sledgehammer to kill a fly. If it floats your boat, go for it!

The next big battle we are going to have to fight is the one to stay
ahead of the Agile folks. They mean well, and agile makes programmers
happy, and managers LOVE to hear that the programmers are happy. But
Agile is a terrible tool for software production, even if it's a pretty
good tool for software design engineering. We need to communicate this
indispensable difference. Let's all stay focused on the big prize.

Thanx,
Alan

__________
cooper | Product Design for a Digital World
Alan Cooperalan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential.
"Kipling was right: leaders and talkers and theorists forget how they
depend on oily hands and long apprenticeships." -Libby Purves

I was reading that transcript that Gabriel pointed to earlier today:
(link:
)

here is the last question's answer:
"Coop[er]: Bad idea. Prototypes are software. I believe that there's a
role
for prototypes in interaction design, but I believe it's a very small
and
limited role. It's primarily done as a narrative, not as software. The
risk
of doing interaction design in a medium of code is much greater than the
benefits yield for you. We as competent craftspeople should be able to
communicate with great precision and clarity what we intend the software
to
do without resorting to code.

Code is a sledgehammer here. Prototypes are code that has not achieved
released. Snippets of disposable code are great tools for design
engineers,
but they don't play a large role for interaction designers."

Alan since I know you're here. ;) i wonder if you can expand on this a
bit.
I trust you have good reasons and experience for this, but it goes
counter
to my own both in IxD and in ID. Maybe I'm reading to much in certain
spots.
But I'll posit that doing interaction design w/o creating interactions
in
some form is akin to doing visual design w/o using color (but expecting
color in the final solution, saying that the printer will handle it).
Now
that I put that out there, I'm curious.
What I'm not interested in, is the education component. I'm assuming
that
tools are or will be easy enough and good at hiding real code that the
skills to acquire this craft is not an issue.

Perhaps I am in the minority here but I think it is really important
to have models to show people. Architects have done this for years,
showing building concepts as foamcore models so people who are not
adept at reading blueprints can see the concept clearly from many
angles.

To say that a prototype=code and is the domain of the developer, to
me, is to construct a rather narrow definition of the term.

If the result of that narrowness is for interaction designers to say
that they only deliver on paper, I think our ability to communicate
will be reduced. And perhaps, so will the quality of our thinking,
since sketches are often less detailed than models.

I have always found it useful to show people models of my designs.
And if I can get the models to show state, all the better.

Perhaps we should not call these models prototypes but neither, in my
opinion, should we ignore them

> Once you've learned how humans react, you no longer really need to> actually, physically test your designs. Your experience will tell> you just as dependably.

Except when the industry, technology, and humans continue to change.
Times are changing and so are human reactions. The interesting thing
about humans is that we do learn to adapt and adopt over time and so
our reactions change over time. Designs that might not have initially
worked, can work in the future. Designs that currently work now, may
not be the best design in the future.

How do you accommodate for innovation if we stop testing our designs?
Do we just do what we know works and not try anything new?

I can only partially agree with this, Alan. I would agree that we
don't need to test designs that we know work based on experience
(contextually speaking). However, I can tell you from first hand
experience that my designs today are much better than my designs a few
years ago, hell even last year, because I'm continually pushing them
rather than relying solely on what I know worked last year. And I
would bet that your design solutions today are not the same ones you
used a few years ago either.

Design evolves.

Tags—how would your experience tell you how humans interact with
something new like this? AJAX transitions in websites and web-based
applications? These new concepts, new interactions, new models need to
be prototyped and tested.

Now once you've learned from that experience, you can apply that to
new designs. However, I've personally seen changes to human reactions
to things like tags in just the last year. So, while my initial
reaction and experience would tell me "No, they don't work," I'm
starting to see cases now where they do (even though I personally
don't like them, but then again, my opinion is irrelevant when I've
got data that says otherwise).

This over simplifies the scope and complexity of software as it
continues to increases in complexity and purpose. Obviously,
prototyping to discern whether a drop down or a series of radio
buttons works best is no longer necessary, but determining work flow,
with interactions, plus user goals and context of use is not a simple
matter of the designer resourcing past experience. n to the power of
four. Can we really predict the response to this many variables?

Prototypes are no doubt created where non are needed. But all to
often assumptions and best guesses are made that need to be validated
with the user's involvement. Following this direction (certainly at
its extreme) is dangerously close to pushing designers to 'inmate'
status.

This direction as a prescription for interaction designers is
appropriate for only the most schooled and experience of
practitioners. My immediate response to this is a fear of yet more
of the same... only from the (trusted) guardians of users and ease-of-
use. A heaping helping of caution seems appropriate.

If more interaction designers were the beneficiaries of seeing and
fully understanding your work Alan, along with that of Jared, Peter,
Jesse, etc... this would be sage advice. But this profession is still
young (as are most of the practitioners) and lacking a common and
pervasive knowledge set that would allow this sort of liberty. I hope
we get there soon, but I think it will be a bit.

Still, I am glad that you are pushing.

Mark

On Feb 13, 2008, at 8:28 PM, Alan Cooper wrote:

> Dave,>> I'm currently taking a welding class. To learn how to weld, I am> making lines of weld-bead on sheets of scrap aluminum. This is a very> useful pedagogic device.>> After a couple of years of practice and training (assuming I were a> young person making a career out of welding), I'd go into the world> as a> journeyman welder. I would never, ever make lines of weld-bead on> sheets> of aluminum again, since it has virtually no practical purpose.>> About two-thirds of the need for prototyping is as an equivalent,> pedagogic tool. Young interaction designer trainees need to see how> humans react to their designs, and prototypes are an excellent tool> for> that. Once you've learned how humans react, you no longer really> need to> actually, physically test your designs. Your experience will tell you> just as dependably.>> The other third of the need for prototyping is for invention, a very> rare occurrence. Invention means pure, new, never-before-seen modes of> behavior. A couple of years ago, for example, I was working on an> email> program where individual conversations (threads) were represented by> icon-like images. Those images were "orbited" by related messages,> images, files, correspondents and other relevant information. Nothing> like this had ever been done before, so prototyping was appropriate.>> But please understand that invention is not the same thing as> design.> Prototyping is useful in invention, but its role isn't for design as> much as it is for raw exploration of the subject matter before> design is> even necessary. Such a prototype would then be used as a guide for> subsequent design (on paper, not in code).>> Historically, software comes from a world rich in invention, and the> enormous egos in the software business still imagine that invention> dominates. Most programmers and most interaction designers think that> they are inventing when they are creating yet another eCommerce> website.> The cries for and claims of innovation are evidence of that. But the> overwhelming quantity of what I see in the world of software today> simply isn't invention but is the basic block-and-tackle,> three-yards-and-a-cloud-of-dust form and behavior design like we all> learned in school or on the job. Their users are consumers or business> people doing simple, business or personal tasks using well established> idioms, typically implemented using off-the-shelf components> arranged in> very conventional ways. Recent "innovations" such as YouTube and even> Crowdvine simply don't show any interaction innovation. Good, solid,> workmanlike design, yes; prototype worthy innovation, no.>> Before interaction design gained its contemporary respect, old-> school> HCI practitioners claimed emphatically to me, "I learned so much> when I> did user testing!" Of course you did. You never had any design> training> so it was a complete shock to you when you saw how humans reacted to> software. Today, it is unconscionable for a professional interaction> designer to NEED to user test anything but the most advanced, obscure,> never-before-seen interaction. And prototyping is very time and money> intensive, particularly so when compared to what well trained> designers> can do with a couple of 90-minute interviews and a whiteboard.>> Please remember that prototype code is subject to the law of fools:> they see it and they think you can SHIP IT! And then WE are stuck> with a> commitment to a non-optimal strategy. Why take that risk?>> You know, I don't really care anymore whether or not interaction> designers prototype or not. I took a clear and bold and absolute stand> against prototyping 15 years ago to make a point: that we can do good> design without code. This was a necessary decoupling to allow the> profession of interaction design to separate, differentiate, and> elevate> ourselves away from programming.>> Well, we've accomplished that goal, as Interaction08 proved beyond a> doubt. And now that we are indeed separate, different, and elevated,> there isn't a big downside to prototyping. Mainly it's like using a> sledgehammer to kill a fly. If it floats your boat, go for it!>> The next big battle we are going to have to fight is the one to stay> ahead of the Agile folks. They mean well, and agile makes programmers> happy, and managers LOVE to hear that the programmers are happy. But> Agile is a terrible tool for software production, even if it's a> pretty> good tool for software design engineering. We need to communicate this> indispensable difference. Let's all stay focused on the big prize.>> Thanx,> Alan>>

13 Feb 2008 - 9:35pm

Todd Warfel

2003

On Feb 13, 2008, at 8:28 PM, Alan Cooper wrote:

> About two-thirds of the need for prototyping is as an equivalent,> pedagogic tool. [...]>> The other third of the need for prototyping is for invention[...].

I agree that these are two definite roles for prototyping, but wonder
where would you put prototyping as a way to working through a design?
Is it in one of these groups? If so, which one? Where would you place
it?

I agree with just about everything Alan said (which is atypical for
me), but Charlie made me think of another aspect.

Prototypes are not always about invention, nor are they always about
proving out a design. Often, they are a communication device. They're
a way to document something otherwise difficult to describe with
static wireframes and comps.

In this era of highly interactive software, both web-based and on the
desktop, prototypes help document interaction in a way static images
simply cannot.

> Perhaps I am in the minority here but I think it is really important> to have models to show people. Architects have done this for years,> showing building concepts as foamcore models so people who are not> adept at reading blueprints can see the concept clearly from many> angles.>> To say that a prototype=code and is the domain of the developer, to> me, is to construct a rather narrow definition of the term.>> If the result of that narrowness is for interaction designers to say> that they only deliver on paper, I think our ability to communicate> will be reduced. And perhaps, so will the quality of our thinking,> since sketches are often less detailed than models.>> I have always found it useful to show people models of my designs.> And if I can get the models to show state, all the better.>> Perhaps we should not call these models prototypes but neither, in my> opinion, should we ignore them>> Charlie>>> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .> Posted from the new ixda.org>http://www.ixda.org/discuss?post=25888>>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://www.ixda.org/unsubscribe> List Guidelines ............ http://www.ixda.org/guidelines> List Help .................. http://www.ixda.org/help

14 Feb 2008 - 1:09am

Charlie Kreitzberg

2008

< Prototypes are not always about invention, nor are they always about
proving out a design. Often, they are a communication device. They're a way
to document something otherwise difficult to describe with static wireframes
and comps.>

That is how I see it. Models allow us to demonstrate behavior without the
need to actually build the underlying code. Not only is it a communication
device but it also forces the designer to design to enough completeness to
enable others to see hoe it is going to work.

The question of how detailed a model needs to be is one of those
never-ending discussions.

I keep calling these models "prototypes" but it gets us into trouble. We
either need to qualify the term (e.g. Design Prototype, Conceptual
Prototype) or use a different term like model.

Let me touch on a related and I think very important issue. Ix Design
differs from any other design field in that we have an empirical way to test
our designs. When you have a model you can test it and that serves as
validation that our designs work as anticipated. This allows us to, in a
sense, guarantee the quality of our designs and that seems like a powerful
opportunity.

Charlie

14 Feb 2008 - 11:30am

Andrew Thelwell

2008

So... aren't we just discussing the semantics of the word "prototype" here?

I mean, I would use the word in the broader sense - from early conceptual model through to semi-finished build.

Where you choose to draw the line on what is and is not classifiable as a 'prototype' is a valid discussion in itself, but I'm wondering if that is *meant* to be the nature of this discussion, or if I'm missing the point entirely?

14 Feb 2008 - 11:20am

Robert Hoekman, Jr.

2005

> I keep calling these models "prototypes" but it gets us into trouble. We> either need to qualify the term (e.g. Design Prototype, Conceptual> Prototype) or use a different term like model.

Agreed. The stuff I usually create barely qualifies as a "prototype" as I
think that term is intended. It's usually more of "interactive model". It's
a click-through PDF or a simple Flash piece that represents a single screen
or interaction within an app rather than the whole app.

I use them primarily to communicate to a developer how something needs to
behave. I almost never use prototypes to test behavior, but I have used them
for invention's sake, in cases where something has never been done before
and I therefore have no previous experience with which to gauge its quality
at the outset.

-r-

14 Feb 2008 - 11:49am

jrrogan

2005

What's the consensus here, (median agreement maybe)?

Prototypes are good and useful, in certain circumstances?
User testing is good and useful, for novices and novelties?

I use prototypes every day, (I call them prototypes, and haven't had any
misunderstanding with what they are except by inference in posts like this,
(OK sometimes clients think they actually work, but they can be educated
otherwise)).

Prototypes help me in a multitude of ways such as:
Detailing interaction of Requirements thru a GUI, (which aides the
requirements definition)
Presenting to stakeholders what they're going to get, (aides in buy in and
feedback)
Testing artifact for User testing, (User testing is good for a number of
reasons, one being that you just never know how your target user is going to
react to a design, without seeing it)
Describing to engineering what to build, (engineers like screens and
dislike long documents)
Detailing to QA what to test
Documenting what was built in a release

Also the prototypes are used as a sales tool, and as a baseline for further
rapid prototyping. I've worked with only documentation as well, it just
doesn't seem to be as well accepted.

I can't imagine the "Most Experienced" Interaction Designer "Not" being
aided with prototyping. Who is this omnipotent individual that knows exactly
what to design, besides when designing the most trivial products, (Ok I
guess they could have equivalency with just documentation, but I still think
prototypes are often a better solution)?

Agreed with all of the below. Like you, I can't help but wonder how
the "most experienced IxD" could get by without prototyping in a very
broad sense. Perhaps this person's omniscience could enable him or her
to create great designs without prototyping, but wouldn't they still
need prototypes to communicate the design to the rest of the team and
to business stakeholders? Or have the most experienced IxD's mastered
some sort of mind melding technique that those of us who are not so
wise can only dream about? :)

Also, I wonder about the "user testing is good and useful for novices
only" bit. I'm assuming that this refers to novice designers, not
novice users?

In fact, wouldn't the level of expertise of target users need to be
taken into consideration here as well? I can't imagine that even the
most experienced designer would not want to validate their design in
some way if designing for an audience of subject matter experts in a
specialized domain.

Dmitry

On Thu, Feb 14, 2008 at 8:49 AM, Rich Rogan <jrrogan at gmail.com> wrote:
> What's the consensus here, (median agreement maybe)?>> Prototypes are good and useful, in certain circumstances?> User testing is good and useful, for novices and novelties?>> I use prototypes every day, (I call them prototypes, and haven't had any> misunderstanding with what they are except by inference in posts like this,> (OK sometimes clients think they actually work, but they can be educated> otherwise)).>> Prototypes help me in a multitude of ways such as:...

14 Feb 2008 - 1:37pm

Charlie Kreitzberg

2008

I too wonder about this.

Really good and experienced designers, I have found, are capable of
creating designs with few user problems. That's not surprising we
can employ the same process that we use in expert reviews to find
problems and fix them.

Nonetheless, usability testing is an important tool for everyone.
Here is why:

1. Every now and then, even the best designer misses something.
2. You get a lot of good feedback from it.
3. Other stakeholders feel that the design has been validated.
4. The designer can feel secure about the usability of his or her design.

I always recommend a usability testing whenever I can fit it in.

Over the years, most of my tests have become less formal. I've
abandoned the lab for all but the most persnickety clients and either
test remotely with a webcasting product or use Morae on a laptop. As a
designer I find it to be a really useful tool.

I have been to companies where there are few design skills. These
companies attempt to compensate for their lack of design by running
lots of user tests. I guess the hope is that with enough tests,
they'll figure out how to improve the design. It's a bit painful to
watch.

So, bottom line for me:

1. Usability testing is always a good idea, if only to validate the design.

I'd like to offer an alternate perspective here (and not just because
it's fun to argue with Alan).

At the outset, I should say that here at Cooper, 2 of our current major
projects involve the creation of clickable, semi-functional prototypes.
(I hate to sound defensive, but in the aftermath of Alan's comments, I
also don't want to spend the next five years explaining to people that I
actually find prototyping valuable.)

To me, "to prototype" is to create some representation of the thing you
are designing. Webster's offers a similar definition: "An original model
on which something is patterned." In this spirit, whiteboard sketches,
blocks of wood, wireframes, foam-core models, pixel-perfect state
renderings, clickable demos and functioning proof-of-concept code are
all prototypes. So we always always always prototype.

The real question then seems to be "how interactive or accurately
representative should the prototypes be." It seems like this is what the
debate is all about. From the postings I've read, it seems there are
several reasons to build a more interactive prototype:

It's absolutely true that interactive prototypes can provide a lot to
each of these aspects of the design process, AND that it is possible to
do each without an interactive prototype (I've seen it happen). It often
comes down to a cost/value calculation, and the sweet spot falls
somewhere on an continuum. The reason we're building prototypes on two
projects right now is explicitly for evaluation and communication.

For me as a designer, interactive prototyping is never part of the
ideation phase-- it's just not fast and fluid enough. I can get the
ideas out in sketches (and I can write code). But it sounds like there
are folks here who feel like it is part of their process. Great.

(I don't know what everyone is using for rendering, but I have to put a
plug in for Fireworks. I feel like the reason some designers resort to
interactive prototypes is that their tools don't handle state very well.
Between Frames and Pages, Fireworks helps do this quickly and fluidly.)

15 Feb 2008 - 1:25pm

Charlie Kreitzberg

2008

I agree with your characterization, Dave.

In the methodology I use (LUCID) I treat the "prototype" as a model
which goes through stages of refinement as the project progresses.

I start with concept sketches, these progress to wireframes, the
wireframes may then be linked together, I might add a visual design
and sometimes have it recoded as a clickable prototype or bitmaps.

The decision as to how far to go depends on the purpose and how
important it is for the customer to see the product in a form that
reflects the final product.

> The real question then seems to be "how interactive or accurately> representative should the prototypes be." It seems like this is> what the> debate is all about.

True enough.

My take on that is that the higher fidelity your prototype is, the
more accurate, detailed and final you can make your design decisions.

With this approach, you can certainly use lower fidelity prototypes
to make all sorts of design decisions at many stages in the design
process, off-loading certain high level, final decisions to be made
while engineering is happening. But if you can build a higher
fidelity prototype earlier and iterate on it, the kinds of design
decisions you can make and stick to are an order or magnitude more
reliable.

Another way to think of it: Strategy and Visionary level design
decisions or considerations can be made at the level of sketches on a
napkin or whiteboard. Detailed and Functional level design decisions
can be made with a high fidelity prototype. (High fidelity being
something that is produced well enough to act as a reasonable
simulation of the actual product, both in form and function, without
the person using it needing outside assistance to operate the
simulation.) The scale slides for everything in between.

I would like to ere on the side of Andrei on this point. Right now
I'm on a project that I did not prototype, and for various reasons
I'm getting burned during the implementation stage.

I believe that if upper management saw some of the realities of the
design instead of filling in the gaps with their lack of imagination,
I would be in a better position.

But I still go back to what Andrei told me that primarily prototypes
are for you as a design tool. What's interesting is that in that
regard, I almost lean towards Alan. That I have enough experience
with GUI design that well, I've "seen it all", or can
understand/imagine a vision for myself w/o needing it all built out.

Another reason for prototyping I didn't hear too much clamor about
is validation. Being able to do user testing on an interactive
prototype in my mind is pretty key to success of a design.

> Another reason for prototyping I didn't hear too much clamor about> is validation. Being able to do user testing on an interactive> prototype in my mind is pretty key to success of a design.

I'll pull out the Dreyfuss quote again:

"The cost of a model is more than compensated for by future savings.
It not only presents an accurate picture of the product for the
executives, but it also gives the toolmakers and production men an
opportunity to criticize and to present manufacturing problems.
Models of some products can be made for a few hundred dollars. Full-
scale models of ship or train interiors can cost many thousands of
dollars. A mock-up of a modern passenger airplane cabin may cost
$150,000 but it will be worth it, for it permits engineers and
designers to develop techniques of installation that would not be
otherwise possible. Furthermore, sales executives can bring potential
customers into a faithful, full scale fuselage to see what it offers,
long before production begins. It is far more effective to sit in a
chair than judge its comfort by a picture of it."

> Another reason for prototyping I didn't hear too much clamor about> is validation. Being able to do user testing on an interactive> prototype in my mind is pretty key to success of a design.

I'll pull out the Dreyfuss quote again:

"The cost of a model is more than compensated for by future savings.
It not only presents an accurate picture of the product for the
executives, but it also gives the toolmakers and production men an
opportunity to criticize and to present manufacturing problems.
Models of some products can be made for a few hundred dollars. Full-
scale models of ship or train interiors can cost many thousands of
dollars. A mock-up of a modern passenger airplane cabin may cost
$150,000 but it will be worth it, for it permits engineers and
designers to develop techniques of installation that would not be
otherwise possible. Furthermore, sales executives can bring potential
customers into a faithful, full scale fuselage to see what it offers,
long before production begins. It is far more effective to sit in a
chair than judge its comfort by a picture of it."

> But I still go back to what Andrei told me that primarily prototypes> are for you as a design tool. What's interesting is that in that> regard, I almost lean towards Alan. That I have enough experience> with GUI design that well, I've "seen it all", or can> understand/imagine a vision for myself w/o needing it all built out.

No offense and please don't take this the wrong way Dave, but I find
this line of reasoning to be a bit odd.

I'm now heading into designing software for nearly 20 years. I've
helped to design everything from Photoshop to Illustrator to InDesign
to cutting my teeth on designing 3D modeling, rendering and animation
software back before hardware could easily support it. I've designed
large enterprise web-based enterprise applications along the lines of
a PeopleSoft type of thing to simpler B2B verticals. I've helped on
video editing software like Premiere and AfterEffects, oversaw the
design efforts of various versions of Acrobat, and have designed my
own blog to carve out my space on the web. These days, I've been
doing all sorts of design and managing of products ranging from
browser based web site creation tools to social networking for gamers
to consumer level software products.

And even now, with all that experience, I'm still surprised at how
things play out -- even the things I've done before and have a
reasonable expectation of what it will end up like -- whenever we
build prototypes of the things I or anyone here at the studio
designs. In fact, it's the one thing that brings me the most joy:
Watching something come to life from scratch.

I'm not sure how anyone can feel they've "seen it all" in this field.
And if I ever do feel that way, I think I'd need to quit my job and
go paint in a field somewhere to fight off the depression. In fact, I
pray that I'm learning something new and seeing something new right
up to the day I stop seeing.

Just out of curiosity, what was some of the first software you worked
on 20 years (or close to 20 years) ago? I've only been on a computer
since 1990 (not counting the Commodore I tinkered with) and just
wonder why types of software applications people were using pre-1990.

I know there were apps before 90, like Visicalc (1979), but am just
curious what software apps people worked on between Visicalc and when
things like Pagemaker hit the market.

You did not ask me, and it was not quite 20 years ago, but 18 years
ago I designed a graphical interface for third wave technologies
that was developing an integrated message, calendar and contact
management software for windows. They had planned a word processing
application as well, but funding ran out.

Of course that was right about the time that visual basic was
released (thanks Alan Cooper) and most developers thought they had
everything they needed to do interface design for windows. I think it
took another three years before I got my next UI project.

Mark

On Feb 15, 2008, at 6:09 PM, Todd Zaki Warfel wrote:

>> On Feb 15, 2008, at 5:51 PM, Andrei Herasimchuk wrote:>>> I'm now heading into designing software for nearly 20 years.>> Just out of curiosity, what was some of the first software you worked> on 20 years (or close to 20 years) ago? I've only been on a computer> since 1990 (not counting the Commodore I tinkered with) and just> wonder why types of software applications people were using pre-1990.>> I know there were apps before 90, like Visicalc (1979), but am just> curious what software apps people worked on between Visicalc and when> things like Pagemaker hit the market.>>> Cheers!>> Todd Zaki Warfel> President, Design Researcher> Messagefirst | Designing Information. Beautifully.> ----------------------------------> Contact Info> Voice: (215) 825-7423> Email: todd at messagefirst.com> AIM: twarfel at mac.com> Blog: http://toddwarfel.com> ----------------------------------> In theory, theory and practice are the same.> In practice, they are not.>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://www.ixda.org/unsubscribe> List Guidelines ............ http://www.ixda.org/guidelines> List Help .................. http://www.ixda.org/help

15 Feb 2008 - 9:11pm

Andrei Herasimchuk

2004

On Feb 15, 2008, at 3:09 PM, Todd Zaki Warfel wrote:

> Just out of curiosity, what was some of the first software you> worked on 20 years (or close to 20 years) ago? I've only been on a> computer since 1990 (not counting the Commodore I tinkered with)> and just wonder why types of software applications people were> using pre-1990.

In early 1990, I dropped out of college (where I was studying set and
lighting design for theater) to help start a small Macintosh graphics
software company called Specular Int'l. We created and shipped Infini-
D, Collage, Logomotion, and Texturescape. It wasn't high-end 3D
graphics like Wavefront and Pixar work at the time, but we were part
of the crew of companies who helped push 3D graphics to the consumer
level along with companies like Strata and RayDream. Inifini-D
evolved and later got bought by Metacreations, merged code with
RayDream, and is now known as Carrera. Also, Collage was my personal
project, and shipped with dynamic layering (even in CMYK color mode)
before Photoshop 3.0, even though Collage did it at a much lower and
more basic level.

Ah the days of the Mac II, IIfx and the IIci!

Before that, I was a theater rat with a computing hobby. I actually
programmed my own Pac-Man animations in BASIC on a Timex Sinclair
that my Dad bought me when I was 12. (1K of RAM and a tape backup
storage system... gotta love it.) I also helped an older friend of
mine create an ASCII version of Donkey Kong when I was 13 on his
mother's Trash 80. He did the hard coding, I did the ASCII art and
helped with easy animation coding once he showed me how it worked.
While simple little things, I was lucky enough to get introduced to
the whole "pixel" concept way early in the 80s, which proved useful
much later on in life. And that kind of doodling in software was
always something I did growing up because I loved video games. But I
never took it seriously enough to get deep into coding beyond more
front-end oriented level concepts. (HyperCard was my favorite
software toy in the late 80s though.) Mostly interface sorts of
things, and a lot less engine or algorithm sorts of things. In high
school, since I knew my way around a computer, I used to help
teachers and seniors with programs like Wordstar and Microsoft Word,
learning concepts from those programs that still have relevance
today. I also used PageMaker 1.0 to create the theater programs for
our high school productions in 1986-87, never even thinking that one
day I'd help in the design of it's successor.

Andrei, I think there is merit to your point, but your retort was well
a bit off-base and jumped to a lot of conclusions.

First off, I think there are various states of "new". I can't talk
about what I'm working on now, but it is new, in the sense that well
it is using a technology in a novel way for a distinct user-base.

From a design tool perspective (not proof of concept of technology,
and not validating usability), I believe that my experience with
computers, technology, human beings, and interaction design gives me
a strong sense of what it is like to use something. In fact, a big
part of my research has been to find existing models of related
interaction designs, and evaluate them. Even before I begin playing
with the released products, I know so much about them, and can
readily evaluate the designs.

I'm not saying there isn't anything ever new under the sun and I
agree it would be boring if it was true, but I do think that our
skills as pattern recognizers goes a long way towards being able to
analyze our own designs without having to build them out completely.

What I do think we need is similar to the flip books of an animation
studio, where we take small pieces, and evaluate them separate from
the whole in order to make decisions. while this is a type of
prototype, it is not quite the holistic model, and definitely lower
fidelity than doing a complete prototype.

> Andrei, I think there is merit to your point, but your retort was well> a bit off-base and jumped to a lot of conclusions.

Understood. I'm just responding to the "seen it all" sentiment, which
you stated in a previous message and which I felt was a bit of an
overreach in Alan's original response, as expressed as "...once
you've learned how humans react, you no longer really need to
actually, physically test your designs."

Maybe you didn't mean it at the level of literally "seen it all" but
I'm just responding to that aspect in the thread as whole.

: Just out of curiosity, what was some of the first software youworked
: on 20 years (or close to 20 years) ago?

I was working on electronic point of sale (POS) systems using
microprocessors. I remember doing things like hand-assembling Z80
microprocessor code, keying it in on the live customer's computer to
put a fix through their entire database.

The interaction design was really, really important (although it was
years before I called it that). There was the human-computer
interaction and also the human-human interaction (sales person and
customer) to take into consideration. Mostly, the sales person had to
be able to use the POS system while still talking to the customer,
wrapping the stuff, collecting the money and so on. So you really
couldn't rely on them seeing anything on the screen.

We had an unused key on one system's installed keyboard, and more than
one sales person asked for a 'customer destruct' button. An example of
why you don't always do what users want :-)

Which sort of brings me to the coolest thing that I worked on. It was
a stock-taking system for a leading chain of department stores. It
used bespoke hand-held computers that uploaded data to bespoke
microcomputers. The cool parts were (a) performance: cut the sorting
time from several minutes to seconds and (b) we shipped it
defect-free. No reported software or hardware defects during the
entire several-year lifetime of the system - and they did really
install it and use it in several stores. We achieved an easy-to-use
interface on the hand-held devices despite the numeric-only keypad.

>> (I don't know what everyone is using for rendering, but I have to put a> plug in for Fireworks. I feel like the reason some designers resort to> interactive prototypes is that their tools don't handle state very well.> Between Frames and Pages, Fireworks helps do this quickly and fluidly.)>>

Dave,

I find that for me static states in a form & behavior document storied
out clearly communicate the action. For others this may not be the case.

In our meetings with development things are clarified inevitably, and we get
a lot of "OH...I see." Sometimes I bring up fireworks and click between
states to show them. Perhaps this is the point of meetings. However,
sometimes I do imagine that the things we are clarifying (behavior between 2
states) could have been handled by the documentation, that these things are
to me *so obvious and should be made more so in some way.* I'd rather
meetings be used to:

a) Emotionally engage. Rally the troops so to speak around the problem at
hand. Having dev in a meeting room and showing them evidence of the
problems and customer footage. Not all of our documentation, whether using
personas or not, is so real. The heart is tied to what it sees, and once
dev has witnessed some of the background research and the f&b is tied to it
they are "bought in." We have stories of dev going home on the weekend and
spending 20hrs of their own time working through the technical architecture
after these meetings.

b) Clarify edge cases and* *technical architecture issues.

So what might help? *Animation.* Even having the mouse drag across the
screen between state 1 & 2 (pre/post click) embues a feeling of liveness.
The other thing is that in an animation the visual stream is fixed so
comparison between 2 states (e.g. pre/post click) is simple. Sometimes
documentation techniques such as callouts and zoom-ins work, but I know that
animation would work better a lot of the time. In a lot of animations I
would embed callouts and overlays.

What would help me...I have the fixed states as pages/frames, what I lack
are the transitions. Take the mouse pointer bitmap from one position to
another position. Is there a simple means to do this within fireworks?
(without making a gazillion frames) Or do we have to transition to Flash?
Flash sucks because it involves manual labor of importing each frame, and
then if you edit your masters you have to redo everything.

Navid

16 Feb 2008 - 11:49am

Troy Gardner

2008

I use interactive wireframes with varying fidelity, scaled to
prototypes. but always find that having a full sitemap/storyboard/flow
is indepensible as often getting buy in on changes is connecting the
dots between two different parts, requires the static pages serve as
the dots and the user's actions as the lines.

> states) could have been handled by the documentation,

Alas, documention is only as good as it is understoood and followed.
While it's great for the person writing it, for developers it's often
skimmed in a hurry and then if it's iterative doc with many changes,
unless the changes are broadcast (like source code/wikipedia) further
iterations. Showing people, integrating it with user stories to get
emotional traction as you suggest have historically been far more
impact for to dev teams. The narrative also serves as a mnemonic,
rather than some blurb in the documentation.

> So what might help? *Animation.* Even having the mouse drag across the> screen between state 1 & 2 (pre/post click) embues a feeling of liveness.

Amen. Especiallly in dragging, this is one of the reasons I prefer
Flash to Fireworks as emulating the mouse and any moving graphics and
transitions can be done easily, either by hand or by script.

> Flash sucks because it involves manual labor of importing each frame, and> then if you edit your masters you have to redo everything.

If you know flash you will start quickly creating movieclips so you're
not working with raw assets on the timeline and thus can resuse assets
on many screens (thus changes to one propogate). Many high fidelity
prototoypes and apps I use only have a single frame, and either turn
on/off various screens in the stack, or attach them dynamically to the
stage.

Troy.

16 Feb 2008 - 12:34pm

Jim B.

2008

I'm using geoip for advanced tracking on a wordpress blog which I
paid for the city version two years ago. I think these databases
become old and a new purchase is needed to be accurate.

Todd asked:
> Just out of curiosity, what was some of the first software you worked> on 20 years (or close to 20 years) ago?

Several years before I started my Computer Science studies in 1988 (which I changed halfway into Information Ergonomics) I tinkered with a Commodore. It was the C-16 model with 16K of memory, a tapedrive, and a toilet paper roll sized printer. The 16K shriveled to 1K when you turned on the graphics mode.
Limited as it was, I still managed to earn money (no idea about fame) by writing games and tools from 1982 to 1986 (yes, I was 12 in 1982).

My favorite game was one where you flew with a helicopter through a 2D maze of caves, rescuing people along the way. It was published in a magazine where interested players had to type the code, line by line, printed on the pages of the magazine.
The most challenging game was one where I used the graphics mode to show a city being blasted to pieces by a canon that was controlled by the user. I had to change the line numbers from the usual 10, 20, 30, etc. range to 1, 2, 3, etc. to save the necessary bytes...

The tools were mostly game-maker tools; I was my own test audience. To create any game that looked interesting, you had to change the character set. I got tired of creating these on paper, then calculate the required codes and enter them by hand, so I created a tool that allowed me to create them on the C-16. The screen featured the character
Oh, and anything that allowed me to do my homework better. I think I learned French by typing and retyping and retyping the words I needed to learn into the code. The fact that the resulting program allowed me to train me was only part of the deal :-)

1. there is no doubt that getting feedback on working software is
better than a sketch (putting aside the cost of creating working
software, just saying if you could magically create it with no effort)
2. in the not too distant future tools will exist that allow us to
"sketch" working software. thermo is a step in this direction.

so, IMO, there may be a lot of arguments about whether sketching is
better than prototyping and vice versa, but they are going to get
much closer together whether people like it or not, and I think this
argument will be academic sooner rather than later.

I mean, now that people can do 3D models of architecture, and
walkthrough visualizations, is there a big constituency maintaining
that blueprints and artist renderings are the way to go?