Is interaction design more than skin deep?

4 Feb 2008 - 12:23pm
6 years ago
3 replies
1189 reads
Murli Nagasundaram
2007

Of course it is. I hate these kind of annoying teaser headlines that the
print and broadcast media use to get people to read a news story/watch a
program. But here's what I'm getting at:

In the beginning was Interface Design. Then it was argued that it's more
than 'just' the 'interface', which regular folk take to mean pretty looking
screens -- that it's actually 'Interaction Design'; that we are interested
in matters beyond 'merely' the 'interface', and in fact we would like to
design the entire interaction process. Further along the way, we became
interested in the entire User Experience, and not just the process of
interaction. And who knows how much more will be included in the scope of
what we claim to be our domain in a few years.

The question then is: where do we stop, if we intend to stop at all? In
another ongoing thread, I brought up the matter of Action Technologies'
Coordinator, which Chauncey Wilson on this forum has tested while at Digital
Equipment, back in the 1980's. The Coordinator (sounds a lot like 'The
Terminator' doesn't it?) was quickly dubbed 'fascistware' and nearly
universally rejected by its users. Weigh in here if you please, Chauncey,
since you actually did thorough usability testing on the product -- but even
if The Coordinator would have passed the usual gauntlet of usability tests;
even if it got two thumbs up on every ease of use measure, it still probably
would have failed. Not because it didn't serve any useful purpose, but
because, among other things, it attempted to force certain changes in
individual and social behavior.

So, from the perspective of today's User Experience professional -- where
does a UXP's responsibility end? Does a UXP's responsibility today
encompass everything that traditionally was the domain of the folks who
gathered requirements and wrote the specs. So, for instance, if somebody
were to think of embarking on a project like The Coordinator today, would
the UXP, even while such a project was being mooted, raise red flags and
suitably modify the goals of the project?

Since one or more threads right now are devoted to trying to define the
field, it might be useful to work from the outside in -- where do we draw
the line (if at all we draw a line) and say that anything beyond the line is
(mostly) outside the scope of UX?

-- murli

Comments

4 Feb 2008 - 1:57pm
Fred Beecher
2006

On 2/4/08, Murli Nagasundaram <murliman at gmail.com> wrote:
>
>
> So, from the perspective of today's User Experience professional -- where
> does a UXP's responsibility end? Does a UXP's responsibility today
> encompass everything that traditionally was the domain of the folks who
> gathered requirements and wrote the specs. So, for instance, if somebody
> were to think of embarking on a project like The Coordinator today, would
> the UXP, even while such a project was being mooted, raise red flags and
> suitably modify the goals of the project?

Good question, Murli. That's something I've been thinking about since I had
a very interesting experience with my Netflix queue. <geek> My wife and I
were happily watching our way through all 10 seasons of Stargate: SG-1 when,
somewhere around season 7, the next disc was listed as having a "Very Long
Wait." So instead of sending us the disc *after* the delayed disc, Netflix
sent us the first disc of the next *series* in our queue, Stargate:
Atlantis. </geek>

I've been wondering for weeks now whose decision or insight that was. Was
user research conducted, leading to an insight that led to this modification
of business process? Or is there someone at Netflix who is separately
responsible for designing business process in a customer-centric way? This
is the sort of thing that toes what I perceive to be a nebulous line between
something called "user experience" and something else called "customer
experience."

In my mind, which obsessively classifies things, I have defined "UX" to
refer to experiences a user directly has with a product, while "CX" refers
to experiences a user has surrounding their acquisition and ownership of a
product *or service*. Taking it a step further, I see UX as an *element* of
CX. If you've created a crappy product, that's going to have a negative
impact on the customer's perception of your company, no matter how helpful
and smiley your sales & tech support staff are.

So in my Netflix example, something like rearranging my queue or finding a
(good) sci-fi movie I actually *haven't* seen would be an example of user
experience. My joy at not having to be lost or suffer plot spoilers after
missing 4 episodes of SG-1 would fall under customer experience.

As to whose responsibility this is? Well, I'm going to take a cop-out by
saying that while UX is definitely the UXD's responsibility, CX is the
responsibility of the entire product development team, possibly the entire
organization.

In large organizations, I've seen them split off the research, UXD, and
usability testing functions to different individuals. Research communicates
their findings to UXD, who then implements a design based on those findings.
Usability then evaluates the design and suggests revisions. In the way that
responsibility for UX is shared in this situation, I see CX as simply
encompassing more roles/individuals... BA, product managers, executives,
marketing, etc.

So to finally answer your question, Murli, I'd say that the UXD's *primary*
responsibility ends at the user's interaction with the actual product.
However, due to their unique and detailed knowledge of customer
needs/desires/contexts/etc., business process or CX design should be a
secondary responsibility. At the very least, UXDs in a given organization
should have some defined avenue toward influencing decisions that will
affect CX.

Thoughts?

- Fred

4 Feb 2008 - 3:49pm
Jeff Howard
2004

Fred wrote:
> This is the sort of thing that toes what I perceive
> to be a nebulous line between something called "user
> experience" and something else called "customer
> experience."

I see Netflix is an example of "service design." It's often
referenced along with exemplars from car rental, banking, airlines,
coffee houses and package delivery as a classic example of the
discipline.

It brings together touchpoints from many different disciplines:
interface design (the site), graphic design (the mailers), system
design (how your queue works) along with the more human side of the
interactions like customer service and support and integrates
everything with business strategy.

Service designers don't create all this in isolation. It's
conceived as an incredibly collaborative discipline that works
directly with stakeholders to co-create the service experience.

Here are a couple firms to look at in this area:

Engine
http://www.enginegroup.co.uk/

Live|Work
http://www.livework.co.uk/

// jeff

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

5 Feb 2008 - 8:37am
Andrew Thelwell
2008

My first post, and I'll try to keep it short (I'm entering the dying moments of my lunch hour, so succinctness is key).

I think job titles, in and of themselves, are nothing more than a central marker -- a pin, let's say -- in the overall 'map' of a person's professiona tasks, roles and responsbilities.

Therefore, in my opinion, it's a matter for the individual and their organisation to agree where the boundaries of responsibility lie. If a person is especially versatile or knowledgable, and has an excellent 'big picture' view of the project or product on which they are working, then it stands to reason that their opinion should be given high regard. I don't believe, however, that this is the kind of thing that can be considered in absolute terms; it all depends upon the make-up of the team and the organisation as a whole.

Syndicate content Get the feed