Prototyping tools resources

28 Feb 2009 - 9:49am
5 years ago
16 replies
438 reads
Jeremy Kriegel
2009

Interesting chart, but I think it is a gross oversimplification of the
utility and applicability of tools. There are valid situations where
the reality is diametrically opposed to your evaluation.

Having been one for many years, I know that there is a tendency
towards 'certainty' in consulting. It's reassuring to clients, who
may get nervous with an 'it depends' approach.

-jer
www.methodSANSmadness.com

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39316

Comments

28 Feb 2009 - 2:54pm
Andrei Herasimchuk
2004

On Feb 28, 2009, at 6:49 AM, Jeremy Kriegel wrote:

> Interesting chart, but I think it is a gross oversimplification of the
> utility and applicability of tools. There are valid situations where
> the reality is diametrically opposed to your evaluation.

Unless you have something specific in retort, then I think you just
did what you are accusing me of. I'm open to feedback or hearing
countering opinions even if it doesn't necessarily change my mind, but
making a blanket statement about what claim is a blanket statements
doesn't seem very useful.

FWIW, this chart comes from my experience as a designer running a
design services firm (Involution), a designer working inside a major
software corporation on major software products (Photoshop,
Illustrator, InDesign), a designer running a small team at a dot.com
startup (a team of 2-4 people), a designer running a medium sized
team (almost 20 or so people) and as a designer who likes to fiddle
with my own personal projects.

While it is personal opinion, it has been my experience. I encourage
you to go create a counter argument, and I'll even point to it from
the page as a countering opinion.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

28 Feb 2009 - 3:06pm
Andrei Herasimchuk
2004

On Feb 28, 2009, at 6:49 AM, Jeremy Kriegel wrote:

> Having been one for many years, I know that there is a tendency
> towards 'certainty' in consulting. It's reassuring to clients, who
> may get nervous with an 'it depends' approach.

And as a small side note: The point of the interactivity of the chart
was precisely to illustrate the "it depends" answer.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

28 Feb 2009 - 6:14pm
Adam Korman
2004

I'll try to put some concrete feedback around the basic criticism.
Because of the criteria you've chosen, the chart has a bias in favor
of prototyping using the tools that are the same (or closest) to how
the product will eventually be built. Tools that are the same or
similar to what will be used to build the final product always score
the best, and there's a drop-off whether you use more or less
sophisticated tools. By this measure, the chart shows that there's
never a good reason to create a paper prototype or click-through
screenshots. In fact, by choosing the term "Acceptable" as the middle
rating, you are suggesting that paper and click-throughs are always
unacceptable prototyping methods (because their average rating in all
cases is less than "acceptable").

I think there are two important criteria that might start to balance
things out: (a) degree of specialized skills required to develop the
prototype and (b) level of effort to build and maintain the prototype.
If you have to hire someone to build prototypes, that may not be an
acceptable investment to get "optimal" results.

That said, I still think there's a bigger problem with the slant in
favor of reusability. It's been my experience that the more time and
effort you invest in a realistic, reusable prototype, the more of a
vested interest you have in believing that you already have the right
answer. In other words, if you've spent a lot of time creating assets
(graphics, code, behavior) that you expect to reuse in the final
product, the more attached you become to those assets. When there is
no expectation that the assets for the prototype will be reused,
development of the prototype is faster and it's easier to toss things
out that are wrong or don't work as expected.

Now if you already know you're right, a hyper-realistic prototype with
reusable code and graphic assets may be useful. This brings up an
important missing piece from the chart, which is any discussion of the
goal of creating the prototype and how different mediums may be more
or less appropriate for different goals. If your goal is to test
overall concepts, I think this chart is totally misleading. If the
goal is to test if your concepts are possible given the technology,
the chart seems more reasonable.

-Adam

> On Feb 28, 2009, at 6:49 AM, Jeremy Kriegel wrote:
>
>> Interesting chart, but I think it is a gross oversimplification of
>> the
>> utility and applicability of tools. There are valid situations where
>> the reality is diametrically opposed to your evaluation.
>
> Unless you have something specific in retort, then I think you just
> did what you are accusing me of. I'm open to feedback or hearing
> countering opinions even if it doesn't necessarily change my mind,
> but making a blanket statement about what claim is a blanket
> statements doesn't seem very useful.

28 Feb 2009 - 10:25pm
Todd Warfel
2003

On Feb 28, 2009, at 2:54 PM, Andrei Herasimchuk wrote:
> While it is personal opinion, it has been my experience. I encourage
> you to go create a counter argument, and I'll even point to it from
> the page as a countering opinion.

I can't say I personally agree with a number of your assessments,
especially the grading of methods like Paper, Static click throughs,
and Flash on how much they add/remove from the overall timeline.

This is not only based on my on personal experience of 6 years of
having run a design research and product development studio
(Messagefirst), working as a lead designer for 3 product companies in
Boston (4 years), work as a design lead at an ad agency (1.5 years)
and working for an international company providing design services for
small to fortune 500 companies (2 years).

Additionally, it doesn't line up with the recent survey results I ran
evaluating how well 6 different tools performed for 13 different
characteristics, many of which overlap yours, and to which over 100
people responded. I'll be including these results in my book, which
will be out later this year. And yes, I'll make them public before
that as well.

Now, that being said, I do applaud you for taking the time to put this
together. I think the fundamental flaw in the grading, however, is
that it lacks context and dimension. Stating that paper prototyping
doesn't save time, but can often add time to the overall timeline is
something I cannot agree with at all. The mere fact that you're
prototyping at all shaves time and effort off the overall development
process, unless you're really screwing something up.

A proper assessment would be to have a control group and a number of
additional groups using various methods, then outside those methods
have them all use exactly the same development model to accurately
assess the overall cost savings of time and effort. But I don't think
that's very realistic.

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

28 Feb 2009 - 10:27pm
Todd Warfel
2003

On Feb 28, 2009, at 6:14 PM, Adam Korman wrote:

> Now if you already know you're right, a hyper-realistic prototype
> with reusable code and graphic assets may be useful. This brings up
> an important missing piece from the chart, which is any discussion
> of the goal of creating the prototype and how different mediums may
> be more or less appropriate for different goals. If your goal is to
> test overall concepts, I think this chart is totally misleading. If
> the goal is to test if your concepts are possible given the
> technology, the chart seems more reasonable.

Adam, this is an excellent point. One of the values of prototyping is
to work your way through a design and and evaluate a number of design
solutions. However, if you only evaluate the one, then you're missing
one of the most valuable assets of prototyping.

Damn, I really better get those last two chapters finished....

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 12:16am
Andrei Herasimchuk
2004

On Feb 28, 2009, at 3:14 PM, Adam Korman wrote:

> Tools that are the same or similar to what will be used to build the
> final product always score the best, and there's a drop-off whether
> you use more or less sophisticated tools. By this measure, the chart
> shows that there's never a good reason to create a paper prototype
> or click-through screenshots. In fact, by choosing the term
> "Acceptable" as the middle rating, you are suggesting that paper and
> click-throughs are always unacceptable prototyping methods (because
> their average rating in all cases is less than "acceptable").

When compared to the other methods for the purpose of making a product
prototype, those methods are of lesser value. That's no different in
any other design profession for what it's worth, so I'm not sure why
there's some value judgement needed in that regard.

Now, are those methods "bad" or "wrong." No. They are merely
acceptable. I use them all of the time. Are you suggesting that
testing the behavior of a slider control with a paper prototype is
better than a fully interactive one done on JavaScript?

> I think there are two important criteria that might start to balance
> things out: (a) degree of specialized skills required to develop the
> prototype and (b) level of effort to build and maintain the
> prototype. If you have to hire someone to build prototypes, that may
> not be an acceptable investment to get "optimal" results.

Why is balance needed? They are just prototyping methods. The methods
themselves don't have any need to feel balanced, they are simply tools
and means to help design and build products.

And hiring someone to build a prototype is partly the purpose of the
chart. If you want to convince your managers and CFOs that you need
the budget to hire people to build prototypes to get all those things
I've listed, I've given you the tool top do so. If your execs want the
things listed in the chart and be able to see and iterate and work
faster, then yes, you will absolutely have to hire if you don't have
the skills in-house. Why is that bad thing?

More, get the budget to get time to retrain yourself on newer coding
methods and whatnot. Again, writing code and making stuff with your
own hands is fun. It's why I got into design instead pushing paper at
a desk.

> That said, I still think there's a bigger problem with the slant in
> favor of reusability. It's been my experience that the more time and
> effort you invest in a realistic, reusable prototype, the more of a
> vested interest you have in believing that you already have the
> right answer.

That is entirely 180 degrees the opposite of my experience. On all
projects I've built and designed where more realistic and accurate
prototypes have been part of the process, iteration has far exceeded
any other means. The main reason is that very large interaction
problems become extremely obvious and are exposed far earlier in the
schedule.

In fact, it is without more robust prototypes where teams dig in
because they run out of time and decisions have to stick for shipping
and everyone just waits and see how the final product tests in the
field instead of changing things during the design process.

The reusability metric is how the way I make it palpable to people who
pay the checks. I find that means of communicating the value of the
prototype (along with time savings and iteration) works well.

> In other words, if you've spent a lot of time creating assets
> (graphics, code, behavior) that you expect to reuse in the final
> product, the more attached you become to those assets.

Absolutely not. And people who do that tend to do that regardless of
prototyping methodology. That's a problem inherent with someone who
hasn't been trained properly on how to iterate fast and throw away a
lot of design work generally speaking.

> When there is no expectation that the assets for the prototype will
> be reused, development of the prototype is faster and it's easier to
> toss things out that are wrong or don't work as expected.

See above.

> Now if you already know you're right, a hyper-realistic prototype
> with reusable code and graphic assets may be useful. This brings up
> an important missing piece from the chart, which is any discussion
> of the goal of creating the prototype and how different mediums may
> be more or less appropriate for different goals. If your goal is to
> test overall concepts, I think this chart is totally misleading. If
> the goal is to test if your concepts are possible given the
> technology, the chart seems more reasonable.

Again... 180 degrees from my experience. In fact, this past week we
had one of those scenarios where creating a prototype had to be done
with real code to get a true sense of the thing we wanted to do. We're
designing a new email marketing product for a client. The team had
been brainstorming all sorts of models and means to create structural
layouts, and on paper, the idea we had wanted to try wasn't reading
very well, even to ourselves. So we built a quick JQuery based version
of the idea -- something that took all of one afternoon -- so we could
try it out. We then showed that to the client, and they could now see
the interaction live and in person and see for real what the idea was.

Now we're moving forward with that direction, one that we could never
have done with paper prototyping, click-throughs etc. And it's
probably going to be a decision that sticks. Given a 16 week schedule
to design and build something from scratch that is production ready,
that's a very big deal.

One of the things I think tends to happen in this field is people
conflate "prototyping" with "sketching." In all of the discussions
I've had, it seems to me that paper prototyping is one of those
horribly misnamed design activities. It probably should have been
called "interactive sketching." I was in fact going to leave it off
the diagram for that very reason, in that I think it's a poorly named
thing and not a prototype at all. But to do so I imagine I would have
gotten more flack.

Further, for a field that calls itself "interaction design" I think it
is high time people start to truly embrace the means and methods that
will allow you to design... Interaction. Interaction design is not
workflow diagrams. And if it ever was, it was only so on websites in
the late 90s and now early 00s. Now that all this web and mobile stuff
is finally starting to behave with the richness found in desktop
clients from the 80s and 90s, it's high time to take back the design
of the interaction by using something like JQuery to prototype the
idea, not scissors, paper, glue.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

1 Mar 2009 - 4:17am
Adrian Howard
2005

On 1 Mar 2009, at 05:16, Andrei Herasimchuk wrote:

[snip]
> Now, are those methods "bad" or "wrong." No. They are merely
> acceptable. I use them all of the time.

Why? According to your scale paper prototypes - for example - are
_always_ worse than HTML/JS. alternatives. Are there other dimensions
not on the chart that make them better in some contexts?

> Are you suggesting that testing the behavior of a slider control
> with a paper prototype is better than a fully interactive one done
> on JavaScript?
[snip]

Depends what the context and the goals are. Depends on what dimension
you're drawing "better" on.

Because it... erm.. depends :-)

Building a distributed test for a web application that I need to run
with geographically distributed group of users - I'll certainly be
reaching for HTML/JS as a good solution for testing that slider control.

Want to quickly run an idea I have past Peter in marketing and the dev
team - I'll certainly be reaching for a paper prototype.

Different contexts. Different goals. Different needs. Different
dimension for better.

Also - some of the stuff in your chart doesn't match my experiences at
all. For example, paper prototypes can have marginal/minimal speed for
all platforms. In my experience they're the fastest and easiest way to
iterate over solutions I know. That's why I use them. Now obviously
you lose some things because of that. Fidelity for example. But if you
can't iterate through many paper prototype solutions quickly - you're
doing it wrong!

> And hiring someone to build a prototype is partly the purpose of the
> chart. If you want to convince your managers and CFOs that you need
> the budget to hire people to build prototypes to get all those
> things I've listed, I've given you the tool top do so. If your execs
> want the things listed in the chart and be able to see and iterate
> and work faster, then yes, you will absolutely have to hire if you
> don't have the skills in-house. Why is that bad thing?
>
> More, get the budget to get time to retrain yourself on newer coding
> methods and whatnot. Again, writing code and making stuff with your
> own hands is fun. It's why I got into design instead pushing paper
> at a desk.

I *love* code. I code. I wish more designers could code. My personal
work patterns, the team that I work with, and the work that I do means
that we move to code very, very early in the process.

The media/platform we pick for prototypes depends on our needs and
goals. Not on any fear of coding or lack of resources.

>> That said, I still think there's a bigger problem with the slant in
>> favor of reusability. It's been my experience that the more time
>> and effort you invest in a realistic, reusable prototype, the more
>> of a vested interest you have in believing that you already have
>> the right answer.
>
> That is entirely 180 degrees the opposite of my experience. On all
> projects I've built and designed where more realistic and accurate
> prototypes have been part of the process, iteration has far exceeded
> any other means. The main reason is that very large interaction
> problems become extremely obvious and are exposed far earlier in the
> schedule.

My experiences match Adam's.

Personally I have found that large interaction problems are spotted
just as well by lo-fi prototypes in the majority of cases. The length
of time it takes to develop hi-fi prototypes slows iteration and moves
discover later in the schedule. Making it less likely that there are
time and resources available to fix the issues.

There are - of course - exceptions. Places where lo-fi testing and
exploration doesn't work well. I can't imagine doing much paper work
when developing a UI with a touch/gestural interface. I'll certainly
reach of JS/HTML prototypes when I have a tricky bit if hide/reveal
functionality to show.

But code is not always better. Where the limits of the media/platform
don't get in the way - lo-fi generally beats hi-fi for speed of
iteration in my experience.

> In fact, it is without more robust prototypes where teams dig in
> because they run out of time and decisions have to stick for
> shipping and everyone just waits and see how the final product tests
> in the field instead of changing things during the design process.

Since we spotted those big problems early in the process with lo-fi
prototypes that's not been an issue for me.

> The reusability metric is how the way I make it palpable to people
> who pay the checks. I find that means of communicating the value of
> the prototype (along with time savings and iteration) works well.
>
>> In other words, if you've spent a lot of time creating assets
>> (graphics, code, behavior) that you expect to reuse in the final
>> product, the more attached you become to those assets.
>
> Absolutely not. And people who do that tend to do that regardless of
> prototyping methodology. That's a problem inherent with someone who
> hasn't been trained properly on how to iterate fast and throw away a
> lot of design work generally speaking.

It's not just the designer. It's the client too.

1) If they're seeing a lot of expense developing resources only to see
them thrown away I think they have a right to complain loudly unless
you're showing a lot of value for that expense. In my experience that
value is rare.

2) Setting client expectations is harder. Half a day of paper
prototype work is obviously throw away. Half a day producing a single
mockup on a real computer - with real interaction - less so. Yes - you
can explain it to the client. But I find it harder. Yet another
dimension.

>> When there is no expectation that the assets for the prototype will
>> be reused, development of the prototype is faster and it's easier
>> to toss things out that are wrong or don't work as expected.
>
> See above.
>
>> Now if you already know you're right, a hyper-realistic prototype
>> with reusable code and graphic assets may be useful. This brings up
>> an important missing piece from the chart, which is any discussion
>> of the goal of creating the prototype and how different mediums may
>> be more or less appropriate for different goals. If your goal is to
>> test overall concepts, I think this chart is totally misleading. If
>> the goal is to test if your concepts are possible given the
>> technology, the chart seems more reasonable.
>
> Again... 180 degrees from my experience. In fact, this past week we
> had one of those scenarios where creating a prototype had to be done
> with real code to get a true sense of the thing we wanted to do.
> We're designing a new email marketing product for a client. The team
> had been brainstorming all sorts of models and means to create
> structural layouts, and on paper, the idea we had wanted to try
> wasn't reading very well, even to ourselves. So we built a quick
> JQuery based version of the idea -- something that took all of one
> afternoon -- so we could try it out. We then showed that to the
> client, and they could now see the interaction live and in person
> and see for real what the idea was.
>
> Now we're moving forward with that direction, one that we could
> never have done with paper prototyping, click-throughs etc. And it's
> probably going to be a decision that sticks. Given a 16 week
> schedule to design and build something from scratch that is
> production ready, that's a very big deal.

And that's cool. I've had similar experiences myself.

How was the value of the rest of the paper based work? Did you throw
all of it away? Could you have avoided all of it and just done
everything in HTML/JQuery? Could you have done it as fast?

I'm not saying paper prototyping is always better. I'm saying it
depends :-)

> One of the things I think tends to happen in this field is people
> conflate "prototyping" with "sketching." In all of the discussions
> I've had, it seems to me that paper prototyping is one of those
> horribly misnamed design activities. It probably should have been
> called "interactive sketching." I was in fact going to leave it off
> the diagram for that very reason, in that I think it's a poorly
> named thing and not a prototype at all. But to do so I imagine I
> would have gotten more flack.

It's not just the paper-prototype vs everything else that I find
confusing on your charts for example. Other comparisons don't make a
huge amount of sense to me either. To pick one more the different
values comparing click-through screen shots and click-through HTML
don't make much sense to me either. It depends what you're putting on
each of them. It depends what information you're looking for.

It does rather sound like different definitions of "prototype" is
where the discussion really lays.

> Further, for a field that calls itself "interaction design" I think
> it is high time people start to truly embrace the means and methods
> that will allow you to design... Interaction. Interaction design is
> not workflow diagrams. And if it ever was, it was only so on
> websites in the late 90s and now early 00s. Now that all this web
> and mobile stuff is finally starting to behave with the richness
> found in desktop clients from the 80s and 90s, it's high time to
> take back the design of the interaction by using something like
> JQuery to prototype the idea, not scissors, paper, glue.

I'll work with anything that gets me a better product. As somebody who
is very happy with the coding side I still find scissors, paper and
glue (and whiteboards, and sticky notes, and index cards, and talking,
and moving very quickly into live development, and many other things)
give me more value than hi-fi prototypes in many contexts.

I do, like you, wish that more designers had coding skills. Although
that's as much to break deeply broken stereotypes that many have about
coders and coding as it is to allow them to develop things themselves :)

Cheers,

Adrian

1 Mar 2009 - 8:14am
Todd Warfel
2003

On Mar 1, 2009, at 12:16 AM, Andrei Herasimchuk wrote:

> Are you suggesting that testing the behavior of a slider control
> with a paper prototype is better than a fully interactive one done
> on JavaScript?

More effective? That depends. I can build an interactive slider
control with less time and effort than you or anyone else could in
real JavaScript. That's actually one of the methods I teach during my
paper prototyping workshops. And yes, I teach more methods than just
paper.

One of the things you're missing, again, is context. If the goal of my
prototype is to work through a design idea or to communicate the
concept to another team member, then a method like paper is quite
good. If on the other hand, you're pitching it to the CEO, or trying
to sell the customer on a feature, then paper probably won't cut it.

> One of the things I think tends to happen in this field is people
> conflate "prototyping" with "sketching." In all of the discussions
> I've had, it seems to me that paper prototyping is one of those
> horribly misnamed design activities. It probably should have been
> called "interactive sketching."

Sketching is part of the prototyping process. A sketch isn't a
prototype. But a prototype is merely the outcome of the process. There
are a number of activities that occur along the prototyping process,
like sketching, communicating, critiquing, iterating, etc.

> Further, for a field that calls itself "interaction design" I think
> it is high time people start to truly embrace the means and methods
> that will allow you to design... [...] it's high time to take back
> the design of the interaction by using something like JQuery to
> prototype the idea, not scissors, paper, glue.

I'll partially agree here. I suspect we're going to see, or should
expect to see, more and more interaction designers getting their hands
dirty with things like XHTML, JQuery, and Catalyst in the future. And
there's really no better time than the present, especially considering
the increasingly competitive nature of the industry considering the
global economic scare.

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 8:19am
Todd Warfel
2003

On Mar 1, 2009, at 8:17 AM, Todd Zaki Warfel wrote:

> On Mar 1, 2009, at 12:21 AM, Andrei Herasimchuk wrote:
>
>> The tools these days by and large are still crap. Further, so many
>> people in this field refuse to learn how to draw or spec type, so
>> I'm not sure how well a survey of the field is going to measure
>> anything useful when building prototypes requires skills that so
>> many people in this field seem to lack in the first place.
>
> Agreed that many of the tools these days are crap. However, that
> survey did include hand coded HTML and JavaScript.
>
> And most of the people in this field actually have the necessary
> skills to create prototypes. I see it regularly in my workshops, in
> the talks I do, in the conversations I have, in the interviews I've
> done. They might not be able to hand code HTML/CSS/JavaScript, or
> write C++, but they can create fully effective paper, PPT, Visio,
> and slap and map (static click throughs), that do a bang up job. And
> they've had great success with them.

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 8:21am
Todd Warfel
2003

Another thing that's not being considered here is that prototyping
happens with or without an Interaction Designer. There are Product
Managers, Business Analysts, Visual Designers, Usability Engineers,
etc that are prototyping and doing it very effectively without writing
a single line of HTML.

In fact, I've got a number of case studies in my book that will show
huge ROI with prototypes that do not meet the classification Andrea is
putting on "what constitutes a prototype."

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 8:24am
Todd Warfel
2003

Adrian, well said.

On Mar 1, 2009, at 4:17 AM, Adrian Howard wrote:

> [..]

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 2:54pm
Todd Warfel
2003

On Mar 1, 2009, at 1:54 PM, Andrei Herasimchuk wrote:

> Sorry... I'm just going to have to disagree. The skills are
> specifically hand coding HTML/CSS/JavaScript and if not C++, then
> things like ActionScript.

Then in your opinion, no prototype other than one that involves coding
should be considered a prototype?

I've personally seen probably over a hundred prototypes that were
created w/o a single line of HTML/CSS/JavaScript, C++, or
ActionScript, which performed perfectly well to achieve their goal of
either selling the concept internally, communicating an idea
internally/externally, working through a design, or perform usability
testing with a client.

And I've personally worked with dozens myself, first hand, either
created by my firm, or a client and used for usability testing.

> I've seen all those types of prototypes as well. They are simply not
> good enough. When I show people the kinds of prototypes we build
> these days, especially execs and CEOs, they explicitly state how
> much better it is to work with those than with Visio or click-
> throughs.

I won't deny that many times fully functional prototypes can
communicate better, but if you're saying they're not valuable for
communicating to CEOs, then I think you're really off the mark w/that
one. Perhaps your own experience shows this, but mine is much
different as is others. For example, I know a number of companies who
do fantastic things with Fireworks, creating a great deal of
interaction w/o writing a single line of code—Fluid Interactive is one
company in your neck of the woods doing just this.

It seems your view of prototyping and prototypes is rather myopic.

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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 3:02pm
Todd Warfel
2003

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
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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

1 Mar 2009 - 3:34pm
Mark Schraad
2006

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
>

1 Mar 2009 - 10:20pm
Dave Malouf
2005

I'm staying out of the fray of this really stupid thread and sticking
with the first question.

Andrei, for embedded computing please also consider adding arduino
and similar board-level prototyping methods. But often embedded
software interacts with non software interfaces. So being able to
prototype those is actually pretty required, which means you also
need to add in SLA and wax and appearance models that include
snapdomes and the like. Even IAs farm out this level of high-fi
stuff, BUT they do it!

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39316

1 Mar 2009 - 10:42pm
Dave Malouf
2005

A timely piece by David Cronin of Cooper for Adobe:
http://tr.im/gUM6
(Shhh! its on prototyping!)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39316

Syndicate content Get the feed