Any Ixder's working on physical products...

4 Nov 2005 - 5:33pm
8 years ago
2 replies
479 reads
Jim Leftwich
2004

Most of my career in interaction design since 1984 has involved both
the physical aspects of hardware/devices as well as the software
aspects of displays, audio, the information systems behind them, and
the usage architectures by which they're used and the experience is
embodied.

Partly this is because I came from the product and industrial design
side of things, and also partly because much of my work has been in
unique or new device or system domains.

In my own career and approach, I've never separated the hard from the
soft in my view of what comprises the whole user experience. In fact,
the design of any interactional domain's primary elements (hardware
controls and affordances, software widgets or other informational
components and elements) constrain and shape the potential and nature
of all the interactional experience that will take place within it.

The architecting and design of an interactional domain (e.g.: a
completely new device and interaction system, etc.) is like the
creation of a new language. Not all devices or systems fall into the
category of "completely new," so there are often many known and
familiar elements and approaches that can be applied, modified, or
combined in developing a user interface/experience. But unlike
applications within a desktop OS GUI, or sites/services in the web
domain, devices often require a more unique approach, and careful study
and integration of physical controls and the informational/functional
experience they're tied to. Failure to do so leads to overly complex
and confusing products. Often this stems from the abominable
management practice of having one team doing the hardware and
industrial design, and another separate team "adding the interface."
This is a recipe for utter disaster that's been played out countless
times in the product world. At best, it leads to greatly diminished
user experience efficiency, simplicity, and ultimately overall quality
and potential.

Creation of a truly simple, learnable, efficient, extensible, and
elegantly integrated user experience with devices requires a seamless
development effort between the hard and the soft. The two cannot be
separated. Hardware shapes how a system or device can be interacted
with. Conversely the needs of the users, along with the architecture
of a system's software UI, information architecture, and functions
*must* shape how the hardware and controls are embodied. These two
efforts cannot be separated, nor can one preceed the other in a
sequential, linear fashion.

Experience design in devices and systems must be seen and approached as
a whole and iteratively explored and integrated from the start.

The design of embodied functions and applications within an
interactional domain (which comprises most design) is like writing in
that language, or working with an established set of building blocks.
Most established interactional domains, such as desktop GUIs, etc.,
have great dimensions of freedom within their constraints to fail or
succeed at the kinds of tasks and experiences they're best suited for
or matched to. But problems often occur when misguided attempts are
made to use the models and interrelationships within these familiar
domains for problems, devices, or systems that really would be best
suited to having their own, unique interactional domain and experience
architecture.

This is the old "when you have a hammer, everything looks like a nail"
pitfall.

Herein lies a significant problem in the user experience field. Very
few designers are experienced in analyzing, exploring, and developing
at the unique or new interactional domain level. Most are skilled at
the issues and methodologies pertaining to the elements and
interrelationships found within particular, already-established
interactional domains. Many devices and device-centric development
projects lie somewhat between these two poles. There may be some
familiar interactional strategies that can be legitimately and
successfully applied, but there are often other aspects that call for
fresh thinking and new approaches. Of course, newness (even
well-designed) can bring its own challenges (unfamiliarity, etc.), so
these issues have to be weighed and dealt with within the development
process as well.

Much, or perhaps the majority of interaction design (or UX, IA, et.
al), takes place on a high level within these already-established
interactional domains (i.e.: desktop/laptop GUIs, and more recently
palmtop stylus GUIs, mobile phones, and others) or web-based sites and
applications. Consequently, over the past couple of decades,
interaction design involving whole systems and devices have gotten
short shrift, primarily because they do not represent a significant
portion of design work being done. For every OS GUI, there are hundreds
or thousands of applications designed. For every generation of web
standards, there are millions of individual sites and services that
utilize them. But the impact of these efforts, because they form the
foundation of everything built atop them, is among the most crucial
architectures to get right.

Again, products and devices fall somewhat in between. There are so many
new products appearing around us all the time, but everybody is
familiar with how inherently bad many are in terms of their experience
and usage design. Often products are lauded for their "good design"
while at the same time having pretty poor user interfaces, or the user
interface is ignored completely when evaluating the industrial design.

I can point to the way in which design reviews in the traditional
design magazines have limited the definition of interaction design to
just "Media Design," while failing to adequately recognize the
experience architectures of products and systems in the tradtional
"Product Design" categories. In these venues, it's often been either
one or the other. Recognition for and discussions of designs and
strategies for integrating both have been sparse in comparison to the
predominant UX and Design discussions in the field.

There are numerous sub-topics that can be explored, regarding the
design of device-based interactional architectures. The "button-laden"
(e.g. typical remote controls) approach vs. the "drivable" (e.g.: a few
interelational controls that can be "driven" without searching for
specific buttons to press) interface, etc.. Design for different types
of environments and activities. The special issues related to the
interactional constraints encountered in extremely small displays. The
issues encountered when designing devices that will be part of
interactional/informational "ecologies." Issues involving tradeoffs
presented by component prices and associated differences in
capabilities/resulting variances in the overall user experience, etc..
And the list goes on and on. My own projects over the years have
encompassed dozens of unique, yet archetypal interaction issues, and
strategies for dealing with and integrating them into wholistic
solutions.

The easiest way to discuss and study these issues is via examples and
lessons learned in these kinds of real world projects. I often wish I
could pause my career and engage in a more formal analytical
documentation and teaching of these many unique interaction design
issues. But unfortunately that's not yet been possible. It's
difficult to take the time necessary to properly examine and address
these issues in today's world of sped-up development schedules and
increasing practitioner-related pressures. But it's something that
really needs to be done, as so much could benefit from these lessons
already encountered and explored.

Jim

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
James Leftwich, IDSA
Orbit Interaction
Palo Alto, California
jleft at orbitnet.com
http://www.orbitnet.com/

> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On
> Behalf Of Mark Canlas
> Sent: Thursday, November 03, 2005 11:11 AM
> To: 'Vishal iyer'; discuss at ixda.org
> Subject: Re: [IxDA Discuss] Any Ixder's working on physical
> products inthegroup?
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
> Most Ixd discussions in this group are related to web/desktop
> applications. Wondering if anyone working with design of physical
> product is here? Looking to start a general dialogue
> specifically in this area.

Comments

7 Nov 2005 - 8:28am
Vishal Subraman...
2005

> Often this stems from the abominable
> management practice of having one team doing the hardware and
> industrial design, and another separate team "adding the interface."

I agree with you. The way I see it, is the Ixd team would work with a
content expert team create the product. For Eg. say a decision to make a
washing m/c top

> Creation of a truly simple, learnable, efficient, extensible, and
> elegantly integrated user experience with devices requires a seamless
> development effort between the hard and the soft. The two cannot be
> separated.

I wonder how many companies subscribe to this theory? As an Ixd'er I
would not like to bother if I'm creating a s/w or s device. Our job
should be to define the interactions in whatever we create. That for me
is the biggest diff between and Ixd'er and say a Interface Designer or
an Information Architect. So much so that I think a s/w dev team should
have both an interface designer/ info architect and a Ixd'er (Jim, I
just finished reading your mail...I do realize that you've already said
this in different words)

Notice that as we go up in the level of abstraction, Ixd could be viewed
as a business practice. Jim, do you happen to work in IDEO? They promote
a lot the theories you speak about (BTW anyone studio in NY that works
on these principles?)

> I can point to the way in which design reviews in the traditional
> design magazines have limited the definition of interaction design to
> just "Media Design," while failing to adequately recognize the
> experience architectures of products and systems in the tradtional
> "Product Design" categories.

Corollary: Industrial design kudos goes mostly to looks/ coolness as
opposed to interface. Anyone read Norman's criticism of the IDSA awards
(atleast how they present it to be)?

Vishal
http://vishaliyer.com

Jim Leftwich wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Most of my career in interaction design since 1984 has involved both
> the physical aspects of hardware/devices as well as the software
> aspects of displays, audio, the information systems behind them, and
> the usage architectures by which they're used and the experience is
> embodied.
>
> Partly this is because I came from the product and industrial design
> side of things, and also partly because much of my work has been in
> unique or new device or system domains.
>
> In my own career and approach, I've never separated the hard from the
> soft in my view of what comprises the whole user experience. In fact,
> the design of any interactional domain's primary elements (hardware
> controls and affordances, software widgets or other informational
> components and elements) constrain and shape the potential and nature
> of all the interactional experience that will take place within it.
>
> The architecting and design of an interactional domain (e.g.: a
> completely new device and interaction system, etc.) is like the
> creation of a new language. Not all devices or systems fall into the
> category of "completely new," so there are often many known and
> familiar elements and approaches that can be applied, modified, or
> combined in developing a user interface/experience. But unlike
> applications within a desktop OS GUI, or sites/services in the web
> domain, devices often require a more unique approach, and careful study
> and integration of physical controls and the informational/functional
> experience they're tied to. Failure to do so leads to overly complex
> and confusing products. Often this stems from the abominable
> management practice of having one team doing the hardware and
> industrial design, and another separate team "adding the interface."
> This is a recipe for utter disaster that's been played out countless
> times in the product world. At best, it leads to greatly diminished
> user experience efficiency, simplicity, and ultimately overall quality
> and potential.
>
> Creation of a truly simple, learnable, efficient, extensible, and
> elegantly integrated user experience with devices requires a seamless
> development effort between the hard and the soft. The two cannot be
> separated. Hardware shapes how a system or device can be interacted
> with. Conversely the needs of the users, along with the architecture
> of a system's software UI, information architecture, and functions
> *must* shape how the hardware and controls are embodied. These two
> efforts cannot be separated, nor can one preceed the other in a
> sequential, linear fashion.
>
> Experience design in devices and systems must be seen and approached as
> a whole and iteratively explored and integrated from the start.
>
> The design of embodied functions and applications within an
> interactional domain (which comprises most design) is like writing in
> that language, or working with an established set of building blocks.
> Most established interactional domains, such as desktop GUIs, etc.,
> have great dimensions of freedom within their constraints to fail or
> succeed at the kinds of tasks and experiences they're best suited for
> or matched to. But problems often occur when misguided attempts are
> made to use the models and interrelationships within these familiar
> domains for problems, devices, or systems that really would be best
> suited to having their own, unique interactional domain and experience
> architecture.
>
> This is the old "when you have a hammer, everything looks like a nail"
> pitfall.
>
> Herein lies a significant problem in the user experience field. Very
> few designers are experienced in analyzing, exploring, and developing
> at the unique or new interactional domain level. Most are skilled at
> the issues and methodologies pertaining to the elements and
> interrelationships found within particular, already-established
> interactional domains. Many devices and device-centric development
> projects lie somewhat between these two poles. There may be some
> familiar interactional strategies that can be legitimately and
> successfully applied, but there are often other aspects that call for
> fresh thinking and new approaches. Of course, newness (even
> well-designed) can bring its own challenges (unfamiliarity, etc.), so
> these issues have to be weighed and dealt with within the development
> process as well.
>
> Much, or perhaps the majority of interaction design (or UX, IA, et.
> al), takes place on a high level within these already-established
> interactional domains (i.e.: desktop/laptop GUIs, and more recently
> palmtop stylus GUIs, mobile phones, and others) or web-based sites and
> applications. Consequently, over the past couple of decades,
> interaction design involving whole systems and devices have gotten
> short shrift, primarily because they do not represent a significant
> portion of design work being done. For every OS GUI, there are hundreds
> or thousands of applications designed. For every generation of web
> standards, there are millions of individual sites and services that
> utilize them. But the impact of these efforts, because they form the
> foundation of everything built atop them, is among the most crucial
> architectures to get right.
>
> Again, products and devices fall somewhat in between. There are so many
> new products appearing around us all the time, but everybody is
> familiar with how inherently bad many are in terms of their experience
> and usage design. Often products are lauded for their "good design"
> while at the same time having pretty poor user interfaces, or the user
> interface is ignored completely when evaluating the industrial design.
>
> I can point to the way in which design reviews in the traditional
> design magazines have limited the definition of interaction design to
> just "Media Design," while failing to adequately recognize the
> experience architectures of products and systems in the tradtional
> "Product Design" categories. In these venues, it's often been either
> one or the other. Recognition for and discussions of designs and
> strategies for integrating both have been sparse in comparison to the
> predominant UX and Design discussions in the field.
>
> There are numerous sub-topics that can be explored, regarding the
> design of device-based interactional architectures. The "button-laden"
> (e.g. typical remote controls) approach vs. the "drivable" (e.g.: a few
> interelational controls that can be "driven" without searching for
> specific buttons to press) interface, etc.. Design for different types
> of environments and activities. The special issues related to the
> interactional constraints encountered in extremely small displays. The
> issues encountered when designing devices that will be part of
> interactional/informational "ecologies." Issues involving tradeoffs
> presented by component prices and associated differences in
> capabilities/resulting variances in the overall user experience, etc..
> And the list goes on and on. My own projects over the years have
> encompassed dozens of unique, yet archetypal interaction issues, and
> strategies for dealing with and integrating them into wholistic
> solutions.
>
> The easiest way to discuss and study these issues is via examples and
> lessons learned in these kinds of real world projects. I often wish I
> could pause my career and engage in a more formal analytical
> documentation and teaching of these many unique interaction design
> issues. But unfortunately that's not yet been possible. It's
> difficult to take the time necessary to properly examine and address
> these issues in today's world of sped-up development schedules and
> increasing practitioner-related pressures. But it's something that
> really needs to be done, as so much could benefit from these lessons
> already encountered and explored.
>
> Jim
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> James Leftwich, IDSA
> Orbit Interaction
> Palo Alto, California
> jleft at orbitnet.com
> http://www.orbitnet.com/
>
>
>
>
>>-----Original Message-----
>>From: discuss-bounces at lists.interactiondesigners.com
>>[mailto:discuss-bounces at lists.interactiondesigners.com] On
>>Behalf Of Mark Canlas
>>Sent: Thursday, November 03, 2005 11:11 AM
>>To: 'Vishal iyer'; discuss at ixda.org
>>Subject: Re: [IxDA Discuss] Any Ixder's working on physical
>>products inthegroup?
>>
>>[Please voluntarily trim replies to include only relevant
>>quoted material.]
>>
>>Most Ixd discussions in this group are related to web/desktop
>>applications. Wondering if anyone working with design of physical
>>product is here? Looking to start a general dialogue
>>specifically in this area.
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

8 Nov 2005 - 12:10pm
Jim Leftwich
2004

You raise some interesting points, Vishal.

On Nov 7, 2005, at 5:28 AM, Vishal iyer wrote:

> I agree with you. The way I see it, is the Ixd team would work with a
> content expert team create the product. For Eg. say a decision to make
> a washing m/c top

This particular example caught my attention. In general, in the
development of products or devices that have physical controls, there
needs to be a close relationship between the interaction/experience
designer(s) and the industrial designer(s).

But the example of a washing machine provides an excellent opportunity
to discuss another variety of device/system/process
activity/interaction, which is configuration/mediation. And
furthermore, an opportunity to discuss how sometimes the best
interaction design goal is to get rid of the need for interaction
altogether.

Configuration/mediation is the interaction involved with "setting up
the parameters of an operation" and/or "monitoring and mediating an
operation once in progress."

Take a look at a traditional washing machine interface and associated
controls. Obviously there are no standards, but essentially such
interfaces include the means to choose a particular operational
modality based on the type of clothing or items (fabric, colors, etc.)
and these modalities generally correspond to things such as "normal,
gentle, etc." Without getting into the specifics, we can see that
there are often several parameters and things that the user sets or
configures. Most home-based washing machines also require the user to
add detergent each time, according to what's being washed, etc.
Thankfully, once configured and in operation, most washing machines do
not require ongoing mediation (though most of us I'm certain have
opened up clothes dryers to check on whether the load is still damp,
and often extend the drying cycle - this is a form of "operation
mediation.")

Why am I bringing up these two aspects of process/operation
interaction? Because one way in which interaction design can approach
these are to simplify how each is approached and handled by a human
user. But I also maintain the following principle:

"The most successful interaction design is ridding the product/system
of the interaction altogether"

When I read Bart Kosko's excellent 1993 book, "Fuzzy Thinking" (which I
highly recommend to all here), the notion of getting rid of many
interfaces altogether (or reducing them to simple "START" buttons)
became apparent. The following excerpt from an Encyclopedia.com entry
on Fuzzy Logic mentions the application in devices and systems:

- - - http://www.encyclopedia.com/html/f1/fuzzylogi.asp - - -
Fuzzy logic theory was developed by Lofti A. Zadeh at the Univ. of
California in the mid 1960s. However, it was not applied commercially
until 1987 when the Matsushita Industrial Electric Co. used it in a
shower head that controlled water temperature. Fuzzy logic is now used
to optimize automatically the wash cycle of a washing machine by
sensing the load size, fabric mix, and quantity of detergent and has
applications in the control of passenger elevators, household
appliances, cameras, automobile subsystems, and smart weapons.
- - -

In Kosko's book, he describes the washing machine with fuzzy logic in
detail. It senses the weight and detects the color of the clothes,
monitors the clarity of the water throughout the process, and adds just
as much or as little detergent as is necessary. The result is a
machine that requires nothing more than a button labled "START." Such
a process is also far more efficient than one configured in a singular,
rough guess manner by the user. It uses no more detergent or water
than is necessary, but as much as is needed to get the clothes clean.
This is truly intelligent product design, not merely simplifying
unwieldy configuration/mediation interaction.

So the point I want to make is that developing smart, self-configuring
and self-mediating/regulating systems is every bit as much of a valid,
if not superior, form of interaction design to the more familiar
approach of mere simplification. While industrial and interaction
designers are not fuzzy logic programmers, they are often the front
line product definers, and as such where possible, should explore
aspects of products and systems where such automation can free users of
the need to interact altogether.

Sorry for what may seem like something of a tangent, but this was an
excellent opportunity to point out this often overlooked principle.

> Notice that as we go up in the level of abstraction, Ixd could be
> viewed as a business practice. Jim, do you happen to work in IDEO?
> They promote a lot the theories you speak about (BTW anyone studio in
> NY that works on these principles?)

I live and and have my consultancy in the same city (Palo Alto) as
IDEO's main headquarters, and earlier this year was a consultant on a
project to a corporate client where IDEO was doing the industrial
design. I should also mention that I first heard the term "interaction
design" in around 1987 in conjunction with the work and writings of
Bill Moggeridge and Bill Verplank of the design firm, IDTwo, which
later along with David Kelley Design and Matrix Design merged to become
IDEO in the early 1990s. They were pioneers early on in integrating
interaction and experience design along with industrial design.

Jim

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
James Leftwich, IDSA
Orbit Interaction
Palo Alto, California
jleft at orbitnet.com
http://www.orbitnet.com/

Syndicate content Get the feed