Thanks to all of you who have engaged in this thread -- it is growing
into what I find to be a very interesting collective reflection on
the nature of professional design knowledge.
There were two quotes in particular that I would like to pick up on.
Andrei:
Maybe. I've been designing software for almost two decades now...
and I still find a lot of utility in building it, no matter similar
the problems are from product to product.
What I find are that I can cut through the easier problems faster,
and as one builds a library of work to start from, it makes it
easier to try bigger and bolder things in the prototyping phase.
Adamya:
My position on this is slightly different. An ability to code is
important but not a 'must'. What's really important is an
'understanding' of the material. Requiring ability to code is a bit
like saying you must know rules of grammar to write moving poetry. You
don't.
We have found that (in our context) it is faster to 'explore' by
quickly sketching on whiteboards while talking through the
interaction. Sure, we could make a prototype. But that takes time.
Since, we know what is possible, the extra value that a prototype adds
is marginal.
I read these as saying that building proficiency in design involves
developing what design theorists would call a repertoire, a
collection of guiding or exemplary ideas that the designer
internalizes throughout her practice and then "leafs through" by
visualizations or purely mental envisioning when faced with a new
design situation.
In terms of the repertoire concept, my position becomes simply that:
- Interaction design has its own material and thus its own
repertoires. (Duh!)
- Building a repertoire can certainly be done in several ways, as
Adamya points out, but in my experience as teacher and designer, the
most efficient and innovation-conducive way seems to be to work
exploratively in the actual material ("mess around with experimental
code").
It is interesting to reflect on Adamya's point that hands-on can
gradually be replaced with more sketchy and indicative visualizations
as the designer (or the design team) builds a workable repertoire
within the genre in question. My spin on this would be that in such
situations, the quick sketches can serve as shorthand symbols evoking
richer repertoire elements, both in the case of the individual
designer having a "conversation" with her sketches and in the case
where a team collaborates around, e.g., a whiteboard.
Finally, I apologize to Jeff if I came across as saying that only
interaction design concerns itself with interactive experience. I am
very well aware of how architecture and product design has dealt with
the issues for many years, through full-scale modelling,
envisionments and enactments, mockup-based bodystorming, and more.
Interaction design can learn a lot from these practices, and it is my
impression that in the last 10 years or so, we have started to learn.
I still maintain, though, that our material is more temporal than the
traditional materials of architecture and product design. This
follows from the mutability and malleability of digital information.
To be specific, I believe that the detailed look-and-feel of an
innovative, moderately complex, interaction technique normally cannot
be designed and judged properly unless it is implemented in
experimental code and/or hardware.
Regards,
Jonas Löwgren
________________________________________________________________
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
