What is the Service Design vocabulary?

As an educated software engineer (designer?) I’m sometimes intrigued at how well that field is at working with a common vocabulary compared to the (service) design field. To illustrate this I’ve put the two fields side by side in a simple diagram. I’m putting this diagram up here to open the conversation. What your take is on the service design vocabulary.

The main reason why I’ve started this experiment is that I have a gut feeling that the service design field can learn a thing or two from how software engineers work and think. Once you have some common ground in place very valuable things like design patterns, SDK’s, refactoring, frameworks and API’s start to appear. I’m curious how these concepts translate to the field of service design. There’s already an ongoing attempt to describe Service Design Patterns so why not think how (the concept of) API’s translates to physical services.

In the process of making this diagram I’ve asked myself why is it so much harder to define the design vocabulary. Difference in creativity clearly isn’t the cause here, as you need loads of creativity to solve problems using code. It might have something to do with the fact that it’s much harder to say “it works” in the design field. Code is objective as design deliverables are subjective.

Marc Fonteijn

Marc Fonteijn

Als medeoprichter van 31Volts houdt Marc zich bezig met het verleggen van grenzen binnen service innovatie. Marc helpt organisaties om waarde te creëren voor hun klanten door middel van design.

Leave a Comment

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

3 reacties

  • Comment by Greald

    Marc is right if he says that Service Design can learn a thing of two from Software Design. There are many fields where developers stumble into the same types of problem and have come up with comparable solutions, all with another name.

    To my opinion they all boil down to a few basic issues:
    1 to formulate the design problem
    2 to find solutions
    3 to select from these solutions
    already extensively discribed by Herbert Simon in ‘Sciences of the Artificial’.

    Apart from the fact that “physical designs, like code, are objective as design deliverables are subjective”,
    there’s another disturbing factor, I think, which depends on the nature of the subject field (in this instant Software vs Service).
    Software developers, but also electrical, mechanical, industrial designers etc. (engineers) have at least one capability that service designers and developers in other human oriented fields apparently don’t have.
    In my 8-years experience as a university teacher in ‘business development’ (which was taken as the whole of product development and marketing development) I’ve noticed that e.g. the ‘black-box’ approach for process analysis could not be made understandable for most of the students. It just doesn’t fit to their mind frame.

    If we would like to come to an integration of design tools and vocabularies we would have to take this difference in consideration.

  • Comment by Marc Fonteijn

    Very interesting to read your experiences as a teacher. I’m not sure if I agree with the statement that “human oriented workers” don’t have a defined capability. Most of the people I work with fall into the t-shaped people spectrum (or I-shaped according to Bill Buxton). Most of them have degree in a certain field (eg. graphic design or software engineering) and combine that with a human oriented philosophy/mindset. So it’s rather a combination of well defined “hard” capabilities with soft capabilities.

    I have the same experience with students, both as interns and also with projects. Creativity is a big challenge for them. Schools teach students to reproduce and master a standard procedure. Thats not what is required in business development or service design for that matter. Freedom in the process is scary ;)

  • Comment by Greald

    That’s right Marc,
    people may be ‘I-shaped’, ‘–shaped’ as well as ‘T-shaped’ in their orientation. (Could this have some equivalence with procedural vs episodic learning preferences?)
    The point is, if you want the “service design field [to] learn a thing or two from how software engineers work and think”, just ‘I-shape’ methods translating into ‘–shape’ ones will not be sufficient. (With this I assume you don’t want to exclude purely ‘–shaped’ oriented people from the process, neglecting the undeniable values they have to offer.)

    Taking into account the rich procedural/episodic learning literature, without any obvious solution, I’m afraid we are facing a serious problem. Which, however, does not have to withhold us…

31Volts [Service Design]