CPH127

I think it really boils down to staging experiences. An experience staged over time is rarely achieved with just one product or touch point. Constructing a service around an idea, concept or product may limit the ways you can develop that service, or stage the experience, or it may simply lead to failure. To me it seems more attractive to develop a service idea and think of possible touch points, products or physical and digital artifacts as the service idea evolves.

During Christmas of 1999 many online stores were unable to deliver orders on time. This lead to disappointed children and in turn to angry customers. The morale of the story being that you can have a great idea such as selling products online, but if the service, or some aspects of it, have been added on, such as handling logistics and returns, you run the risk of failure, in this case the incapacity to deliver such a great amount of packages on time.

I think historically a business might have considered a product and service as separate things. For instance, the marketing department might have been responsible for developing the online service of selling a product, whereas a product team would have been developing the product elsewhere.

I think a design process can help greatly in defining interactions and experiences a customer/consumer might have with the artifact or service, beyond that what a marketing process could. And instead of asking to complicate it by suggesting two different approaches (not that you were) we should allow for depth in areas where it is needed to explore and design different interactions.

But there is going to be a need to have separate processes for the cases like Didier brings up. For instance, Amazon doesn’t make the products it sells, so it uses a type of design process to develop its services - whereas Pottery Barn does and so perhaps it uses a broader and more all-encompassing one to conceive, make, manufacture and sell it’s products. The question then becomes, where does brand, business, marketing and design come into it?

I believe that, in a perfect or at least clever organization all efforts and initiative should start with the definition of value a given initiative should create for the customer/consumer and other stakeholders (to determine what kind of value would be valued by these parties the clever company could apply design research methodology…).
Once the value the organization wants to create is defined, the organization can look at the means (i.e. products, services, experience) that can deliver that value. The choice of service before products and vice versa will then be determined by the value the total offer wants to deliver.
This might only be feasible in the perfect world even though alot of companies are starting to get the customer-first angle but I think that you get the most out of product/service/experience integration if you start with a question at the right level of abstraction e.g. “what value does our customer want us to deliver?” rather than “how should the experience of this product be?”

I agree with all of you on these points, and im glad this post has brought up a number of issues, i also think that the value of your business or your experience is key to the emotional attachment users will have.

I also wonder what the effect of starting from a completely abstracted idea of value have on the design output. Right now, i and say this based on my own experience, most value is post-rationalised , its more about “how can i imbue cusomer value in this service or that object”. I wonder if this is the right approach or that something new might come out of starting from an idea of value, and might this open new doors…

so many questions…rant rant rant…

What’s important to remember is that services are systems, and that each component exists as a part of an overall system. As Didier pointed out, a service (a system) is only as good as its weakest point.

I’m going to take the fuzzy “third way” and say that your design ideas should never be too precious to modify in the face of reality. In other words, I think these two approaches are a bit “chicken or the egg”-ish, and that the real issue isn’t about which approach you use. I believe there is such a constant interplay between the touch points and the overall system design that it’s impossible to cleanly separate the two.

More specifically, if your approach is product-centered, you need to make sure you’re not sacrificing service sustainability for the sake of form or fashion. Likewise, you may have to adapt your service concept to take into account certain realities of user-expectations and usage patterns. Sure, you can begin with one of those two approaches, but I believe it quickly becomes a moot point — service design needs to constantly reevaluate each component in the context of the larger system.

Being interested in “services” as a phenomenon for some time, I realized recently that nobody actually knows what “service” is.

I mean, while approaching the intriguing field of service management (and design, of course), one should ask the following questions:
- Is there any difference between “manufacturing” and “service” businesses?
- How can we define this difference? Would it be possible to select ONE general way in this differentiation to encompass most or all the other ways?
- Can understanding of this distinction help us set up more appropriate management of “services”?

Analysis shows that all existing definitions of “service” cannot help us to answer the above questions. In scientific sense they should comply with “necessary” and “sufficient” conditions to be valid – but no one is. Things changed with the introduction of the Unified Services Theory by Scott Sampson in the late 90-s which defines customer content as a necessary and sufficient condition for a business process to be a Service business process.

I earnestly advise everybody here to read an introduction to the UST here http://craigfroehle.com/pom_wpd/detail.php?title=Foundations%20and%20Implications%20of%20a%20Proposed%20Unified%20Services%20Theory and hope on further discussion.