Services and Interaction Design

3 Dec 2003 - 1:14pm
10 years ago
9 replies
552 reads
Meyer, Fred
2003

How does a service-oriented approach to business affect the design of
software products?

A current business trend is organizing software products and personnel
around services, rather than organizing around software products. For
example, ADP <http://www.adp.com> provides many software products, but
rather than focusing on their products, they focus on their services and let
the products support those services.

I am trying to understand how a service-oriented approach to business
affects the design of products and I would like to discuss a few assertions:

* Software products are a delivery mechanism for services.
The services provided by a company are paramount; without the services, the
software products are meaningless. The software products simply make the
consumption of those services faster and easier.

* A difference exists between service-based software products and
utility-based software products.
Service-based software products (such as those provided by ADP) deliver
services, while utility-based products (such as MS Word) provide
house-keeping functions. This distinction is important because service-based
products must not only focus on the services they deliver, but they must
also collaborate with other products that support those underlying services.
A traditional utility-based (silo) approach to software design can lead to
disparate products with duplicated and dissimilar features.

* It is the Interaction Designers responsibility to help define services.
If a business's services are not well defined then the quality of their
service-based software is reduced. Without a thorough understanding of the
underlying services and who those services target, it is not possible to
appropriately define software behavior or disseminate features between
products. It is therefore necessary for designers to help define the
services (especially if no on else is picking up the reins) before designing
the products.

Do these assertions hold water? Can they be improved? Are there more? Please
let me know your thoughts.

Thanks!
-Fred

****************************************************************************
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20031203/c5306e37/attachment.html

Comments

3 Dec 2003 - 3:31pm
Olly Wright
2007

it is worth mentioning that there is an entire field of study called
service design. it's not necessarily focused on designing software.
but it is absolutely something that should be considered (and that
matches your third assertion): interaction designers do have a role
in defining services, and design has a role in service strategy.*

here's one place to start. i'll add others when i find them.
http://www.designcouncil.org.uk/webdav/servlet/XRM?Page/@id=6004&Session/@id=D_lSEXAdpSVviUhH5HLp7w&Section/@id=1322

cheers,
molly

*design has a role in business that extends far beyond this, but i'm
not going to address that particular issue right now.

At 12:14 -0600 3/12/03, Meyer, Fred wrote:
>How does a service-oriented approach to business affect the design
>of software products?
>
>A current business trend is organizing software products and
>personnel around services, rather than organizing around software
>products. For example, <http://www.adp.com>ADP provides many
>software products, but rather than focusing on their products, they
>focus on their services and let the products support those services.
>
>I am trying to understand how a service-oriented approach to
>business affects the design of products and I would like to discuss
>a few assertions:
>
>* Software products are a delivery mechanism for services.
>
>The services provided by a company are paramount; without the
>services, the software products are meaningless. The software
>products simply make the consumption of those services faster and
>easier.
>
>* A difference exists between service-based software products and
>utility-based software products.
>
>Service-based software products (such as those provided by ADP)
>deliver services, while utility-based products (such as MS Word)
>provide house-keeping functions. This distinction is important
>because service-based products must not only focus on the services
>they deliver, but they must also collaborate with other products
>that support those underlying services. A traditional utility-based
>(silo) approach to software design can lead to disparate products
>with duplicated and dissimilar features.
>
>* It is the Interaction Designers responsibility to help define services.
>
>If a business's services are not well defined then the quality of
>their service-based software is reduced. Without a thorough
>understanding of the underlying services and who those services
>target, it is not possible to appropriately define software behavior
>or disseminate features between products. It is therefore necessary
>for designers to help define the services (especially if no on else
>is picking up the reins) before designing the products.
>
>Do these assertions hold water? Can they be improved? Are there
>more? Please let me know your thoughts.
>
>Thanks!
>
>-Fred
>
>****************************************************************************
>
>This email may contain confidential
>material. If you were not an intended recipient,
>Please notify the sender and delete all copies.
>We may monitor email to and from our network.
>
> ***************************************************************************
>
>
>
>_______________________________________________
>Interaction Design Discussion List
>discuss at interactiondesigners.com
>--
>to change your options (unsubscribe or set digest):
>http://discuss.interactiondesigners.com
>--
>Questions: lists at interactiondesigners.com
>--
>Announcement Online List (discussion list members get announcements already)
>http://interactiondesigners.com/announceList/
>--
>http://interactiondesigners.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20031203/34d468f2/attachment.htm

12 Dec 2003 - 8:14am
vila
2003

I am interested in the subject but I don't very well understand the gist
of this message. Isn't a service an underlying mechanism provided to
software developers to help them produce products more quickly (as in
Web service)? As such, where does interactive design come in? Or do you
mean service in the general sense, as in Pizza delivery service?

Francis

12 Dec 2003 - 12:43pm
Sean Lawrence
2003

I believe what they are referring to is a service in the form of an
action that is performed ie. a batch of financial data is processed, a
design function has been provided, customer relations are tracked rather
than an object being delivered as in a CD or even an executable files.

vila wrote:

> I am interested in the subject but I don't very well understand the
> gist of this message. Isn't a service an underlying mechanism provided
> to software developers to help them produce products more quickly (as
> in Web service)? As such, where does interactive design come in? Or do
> you mean service in the general sense, as in Pizza delivery service?
>
> Francis
>
>
> Fred wrote :
>
>
> How does a service-oriented approach to business affect the design of
> software products?
>
> A current business trend is organizing software products and
> personnel around services, rather than organizing around software
> products. For example, _ADP_ <http://www.adp.com> provides many
> software products, but rather than focusing on their products,
> they focus on their services and let the products support those
> services.
>
> I am trying to understand how a service-oriented approach to
> business affects the design of products and I would like to
> discuss a few assertions:
>
> **** Software products are a delivery mechanism for services.*
>
> The services provided by a company are paramount; without the
> services, the software products are meaningless. The software
> products simply make the consumption of those services faster and
> easier.
>
> **** A difference exists between service-based software products
> and utility-based software products.*
>
> Service-based software products (such as those provided by ADP)
> deliver services, while utility-based products (such as MS Word)
> provide house-keeping functions. This distinction is important
> because service-based products must not only focus on the services
> they deliver, but they must also collaborate with other products
> that support those underlying services. A traditional
> utility-based (silo) approach to software design can lead to
> disparate products with duplicated and dissimilar features.
>
> ** I**t is the Interaction Designers responsibility to help define
> services.*
>
> If a business's services are not well defined then the quality of
> their service-based software is reduced. Without a thorough
> understanding of the underlying services and who those services
> target, it is not possible to appropriately define software
> behavior or disseminate features between products. It is therefore
> necessary for designers to help define the services (especially if
> no on else is picking up the reins) before designing the products.
>
> Do these assertions hold water? Can they be improved? Are there
> more? Please let me know your thoughts.
>
> Thanks!
>
> -Fred
>
> ****************************************************************************
>
>
> This email may contain confidential
> material. If you were not an intended recipient,
> Please notify the sender and delete all copies.
> We may monitor email to and from our network.
>
> ***************************************************************************
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Interaction Design Discussion List
>discuss at interactiondesigners.com
>--
>to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
>--
>Questions: lists at interactiondesigners.com
>--
>Announcement Online List (discussion list members get announcements already)
>http://interactiondesigners.com/announceList/
>--
>http://interactiondesigners.com/
>

16 Dec 2003 - 10:31pm
James M. Szuch
2003

Services and Interaction DesignI think that there are a number of things driving this service-oriented approach to software products. One driver is the recognition that a service approach provides an excellent opportunity for a business that is otherwise a purveyor of an easily-replicated technology to differentiate itself. There are any number of businesses and business models built on the notion that differentiating along a service dimension can provide an opportunity for (a) improved customer longevity; (b) increased market share and (c) inreased profits. The service model also provides an opportunity to provide more strategic value than mere utility.

More interesting to me is the similarity between digital products and services. Key among these is the fact that both services and digital products are to a significant extent experience goods, which implies that the experience itself can become a key component of the value proposition. Which in turn implies that the design of the experience -- or the interaction -- can be positioned as a key differentiator.

Back to your assertions, I think that we can really combine #1 and #2: We can define two categories of software, a utility category and a service category. The service category consists of those software products that are mechanisms for delivering services. That sounds somewhat circular, but I think that we can expand on the notion of what a "service" is in this context and not define it in terms of itself. If we then add a new assertion that a key element in the delivery of (or definition of ) a service is the interaction of the customer and the service provider (human or software), then I think a variant of the expression of your third assertion follows: Interaction Designers design the interactions that define the services.

One of the things that I like about this approach is that it helps expand the Interaction Designer from the "UI" domain into the domain of the customer and the problem. You view the software product as a component in the delivery of a service, and the Interaction Designer as an architect of the entire customer interaction. Makes you wonder what our experiences as consumers of services would be like if the services themselves were designed with the assistance of a good Interaction Designer.

James
----- Original Message -----
From: Meyer, Fred
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Sent: Wednesday, December 03, 2003 1:14 PM
Subject: [ID Discuss] Services and Interaction Design

How does a service-oriented approach to business affect the design of software products?

A current business trend is organizing software products and personnel around services, rather than organizing around software products. For example, ADP provides many software products, but rather than focusing on their products, they focus on their services and let the products support those services.

I am trying to understand how a service-oriented approach to business affects the design of products and I would like to discuss a few assertions:

* Software products are a delivery mechanism for services.

The services provided by a company are paramount; without the services, the software products are meaningless. The software products simply make the consumption of those services faster and easier.

* A difference exists between service-based software products and utility-based software products.

Service-based software products (such as those provided by ADP) deliver services, while utility-based products (such as MS Word) provide house-keeping functions. This distinction is important because service-based products must not only focus on the services they deliver, but they must also collaborate with other products that support those underlying services. A traditional utility-based (silo) approach to software design can lead to disparate products with duplicated and dissimilar features.

* It is the Interaction Designers responsibility to help define services.

If a business's services are not well defined then the quality of their service-based software is reduced. Without a thorough understanding of the underlying services and who those services target, it is not possible to appropriately define software behavior or disseminate features between products. It is therefore necessary for designers to help define the services (especially if no on else is picking up the reins) before designing the products.

Do these assertions hold water? Can they be improved? Are there more? Please let me know your thoughts.

Thanks!

-Fred

****************************************************************************

This email may contain confidential
material. If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.

***************************************************************************

------------------------------------------------------------------------------

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20031216/69084aea/attachment.html

17 Dec 2003 - 2:04pm
Josh Seiden
2003

James wrote:

"One of the things that I like about this approach is
that it helps expand the Interaction Designer from the
"UI" domain into the domain of the customer and the
problem. You view the software product as a component
in the delivery of a service, and the Interaction
Designer as an architect of the entire customer
interaction. Makes you wonder what our experiences as
consumers of services would be like if the services
themselves were designed with the assistance of a good
Interaction Designer. "

------------

This is actually the premise of Experience Design, as I
understand it. It certainly goes beyond the scope of
what I consider Interaction Design, which, in this
context is a specialty within ED.

Consider an e-commerce web site. There are a huge
number of business processes involved. Sourcing,
purchasing, warehousing, order taking, fulfillment. To
design these processes, one would turn to specialists
who have expertise that is equivalent to IxD in the
level of specialization, but in completely different
realms.

In a well-designed experience, the design of these
processes takes place in such a way that the needs of
the user are understood, and the designers of each
process coordinate to provide users with appropriate
visibility, control, and satisfaction.

Experience Design recognizes that the designers who
make the site beautiful are not the same people who
design good warehouse processes, are not the same
people who figure out catalog taxonomies. ED is thus a
very big tent.

In this example, Interaction Design lives within that
big tent. I believe that is it very much the job of the
IxD to define the way that the service manifests in the
digital domain. This means at the very least
*understanding* the service. It does not mean owning
the definition of the entire service--unless that
service is quite small.

So, going back to the e-commerce example, I would
expect the IxD to specify the kind of data that the
warehouse processes would make available to the
end-user facing processes, and when and in what form
that data should be available. I would not expect the
IxD to design the warehouse processes themselves.

-------

To the point of the original post, I think you need to
distinguish between services that are delivered
exclusively via software, and those in which the
software enables a meat-space service. Online technical
support, Chat, electronic payment, email might be
considered the former. Amazon, freshdirect.com might be
considered the latter.

Haven't thought much about this distinction, though.
Seems kinda slippery.

JS

17 Dec 2003 - 3:12pm
Dave Malouf
2005

"In this example, Interaction Design lives within that big tent. I believe
that is it very much the job of the IxD to define the way that the service
manifests in the digital domain."

Josh are you suggesting here that IxD is only in the digital domain?

-- dave

17 Dec 2003 - 7:54pm
Josh Seiden
2003

> "In this example, Interaction Design lives within
that big
> tent. I believe that is it very much the job of the
IxD to
> define the way that the service manifests in the
digital domain."
>
> Josh are you suggesting here that IxD is only in the
digital domain?
>
> -- dave

You'll notice that *I* didn't say "only." ;-)

I know that the group is divided on this point, but
personally, I believe that IxD addresses the challenges
of designing "digital systems." (By this shorthand, I
mean anything that has a software component, from
car-alarm key fobs to missile targeting systems to web
sites.)

IxD techniques have developed in response to the
challenges inherent in crafting digital systems. What
are the challenges? Digital systems tend to embody
complex behaviors. The capability of software to embody
complex behaviors is an inherent property of medium.
The combination of the order of magnitude of the
complexity and the nature of the complexity make the
nature of the challenge unique to this medium.

That said, I would not rule out the possibility that
you could use IxD tools to design systems that don't
have a software component. I've just never seen it
done. And on the occasions when I see a tool like
personas used in other realms, that tool is often
adapted to the needs of the realm. So much so that I
think you might as well acknowledge that you've left
the IxD realm.

I'm not trying to be pure, just descriptive.

Let me ask the group: have you ever used IxD techniques
to design something that was not "digital" in the sense
I defined above?

JS

18 Dec 2003 - 6:13am
Olly Wright
2007

Hi all,

I mentioned this a few weeks ago, but if you move beyond the Web or even
software as the primary medium, there is a whole field of service design.
It's a sustainable design approach that moves away from products and toward
services. It is very closely related to interaction and experience design,
and frequently uses well-developed scenarios to explain the different
components of the services it describes.

I'm teaching a class next term at Interaction-Ivrea with two service
designers on social networks and service design.

In the meantime, there are some resources and a company in London
(live|work) that does service design. live|work is here:
http://www.livework.co.uk/ -- you should check out their glossary here:
http://www.livework.co.uk/glossary.html ... and the UK Design Council has
some good information:
http://www.designcouncil.org.uk/webdav/servlet/XRM?Page/@id=6047&Session/@id
=D_iJPLKgqmwp8b8ikWg3TK&Document/@id=1859

Also, you should look into the work of people like Ezio Manzini, who spoke
at the Doors of Perception conference last year on Flow, and who just did a
very nice sustainability exhibit at the Triennale in Milan.

For sustainability -- something you should really be looking at -- read
Cradle to Cradle and Natural Capitalism for starters (Cradle to Cradle is an
easier, more portable read). It's interesting to think of our work in
sustainable means -- and it's a very important thing to do.

Cheers,
molly

On 18/12/03 1:54, "Joshua Seiden" <josh at 36partners.com> wrote:

>> "In this example, Interaction Design lives within
> that big
>> tent. I believe that is it very much the job of the
> IxD to
>> define the way that the service manifests in the
> digital domain."
>>
>> Josh are you suggesting here that IxD is only in the
> digital domain?
>>
>> -- dave
>
> You'll notice that *I* didn't say "only." ;-)
>
> I know that the group is divided on this point, but
> personally, I believe that IxD addresses the challenges
> of designing "digital systems." (By this shorthand, I
> mean anything that has a software component, from
> car-alarm key fobs to missile targeting systems to web
> sites.)
>
> IxD techniques have developed in response to the
> challenges inherent in crafting digital systems. What
> are the challenges? Digital systems tend to embody
> complex behaviors. The capability of software to embody
> complex behaviors is an inherent property of medium.
> The combination of the order of magnitude of the
> complexity and the nature of the complexity make the
> nature of the challenge unique to this medium.
>
> That said, I would not rule out the possibility that
> you could use IxD tools to design systems that don't
> have a software component. I've just never seen it
> done. And on the occasions when I see a tool like
> personas used in other realms, that tool is often
> adapted to the needs of the realm. So much so that I
> think you might as well acknowledge that you've left
> the IxD realm.
>
> I'm not trying to be pure, just descriptive.
>
> Let me ask the group: have you ever used IxD techniques
> to design something that was not "digital" in the sense
> I defined above?
>
> JS
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

18 Dec 2003 - 12:16pm
Robert Reimann
2003

My feeling on this matter is that most human-human "service" interactions
are at this point mediated to some extent by digital technology anyway, so
there is plenty of overlap, even for digital design "purists".

However, there are certainly some techniques that can apply to non-digital
arenas: "pretending it's magic" (envisioning the ideal interaction
if one could ignore physical constraints) can be a powerful tool for
exploring both human-human and human-computer interaction concepts.
Similarly, "pretending it's human" (envisioning the way a polite, helpful
human would provide a service) is again just as useful for imagining
idealized human interactions as it is for imagining digital interactions.
Personas and scenarios, as Josh says, can be readily adapted as a tool
for any interaction domain, and flow diagrams were borrowed by *us* from
non-digital disciplines...

To me, interaction design is quite simply the design of behavior, but
what that really means in a domain where designed behavior can't be
deterministically engineered is an interesting question.

Robert.

Syndicate content Get the feed