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
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
