Service Design patterns

We are familiar with UX patterns but how about Service Design patterns? The other day I looked at Service Design Blueprints and 2 things I find lacking:
patterns and a data-component.

I think patterns can be helpful to quickly setup larger systems which often have repetition built in. The data component is useful for me as I primarily deal with data driven services in my teaching and when consulting startups. Here are my first steps into Service Design patterns and the inclusion of data. I will experiment and fine tune this and see what happens. This is in the spirit of my site, quick ideas which simmer for a while and either return to the fore or faint into cyber-nowhere-land.

The Blueprint components

First of all, credit where credit is due. My Service Design Blueprint is a continuation of the excellent work that has been done by Practical Service Design. I have color coded the components in what can be seen as 4 fuzzy categories:

  • white-yellow-sand is for meta text
  • dark skin color is for anything human or living
  • blue tones are for system related
  • green tones is about some remarks about the step
  • reds are notable items

This ain’t perfect and I might reshuffle them but it is pleasing to the eye and it helps me to quickly orient myself.


Data I see as an essential attribute to the Blueprint. At most imaginable touchpoints information is exchanged. A question is asked and an answer is given back in return. In system terms one can say a request-response transaction takes place.

This data exchange is in many, if not most, cases also the moment when frustration kicks in. When a customer asks a question but gets the wrong answer back or when the answer returns later than expected there is a moment of friction. Also when the policy determines that a customer should not get the information, a break in information transfer, we have frustration.


The new data attribute I can use as a hook to data models and a way to integrate machine learning and AI into service design. Most of the information exchange is digital and we interact with this information through smart phones and computers. At the same time much happens on the backstage in clouds and AI environments.

When you sign up at google for Google Alerts it is an algorithm, a function, that determines that you receive an email. You can ask Google to send you an email any time a new search result with the by you specified criteria is found. There is no interaction anymore needed unless you want to unsubscribe from this service or change the search criteria.

Similar patterns you can see in smart devices where you get a notification when for example your credits are nearly depleted, your disk is almost full or your battery is nearly empty. Data in this category is often about warnings and they need special care as bringing bad news in a good manner is an art form.

The Service Design patterns

Automated email pattern

There are plenty of services that are triggered by some event and then interact with the customer in for example the form of an email being sent. Some event could be an algorithm or in the IoT era this could be a change in refrigerator temperature.

Customer checks her account balance via her computer


Customer visits a company’s desk


Customer calls tech support


I think there are a few more patterns to be found and I am especially interested in working on the machine learning and AI side of service design.