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.