A Service Design Principle to set the right expectations
Imagine this. Your partner asks you to write a birthday card, for the birthday that you are attending tomorrow.
So you go out. You buy a beautiful card, with a puppy on it. And you start writing a few words. Later when your partner is back, you hand the card to her. And then your partner says:
"What is this? I wanted a birthday card!"
And you are wondering:
"But this is a birthday card! It's a card, there are some words that say happy birthday."
And then your partner says:
"No! That's not a birthday card! A birthday card is something that is one meter large"!
And then she explains all the details of what she really thinks is a birthday card.
This story sounds very strange, right? But that's exactly the types of interactions that we often have at work.
Someone asks you to create a prototype or something. In your mind, you're already quite clear what this type of thing is. So you just create it. And then you show it to the person who asked for it. And the person says:
"That's not what I wanted!"
Whenever we use a term to describe what we expect, we should not just use the term, but also give an example of what we mean with that term.
And it can be even stronger if we show counter examples.
If you ask a teammate to create a prototype for you, you might say:
"Please create a prototype. What I mean with "prototype" is a shitty draft that you don't spend more than 30 minutes to build, but just shows very roughly what the idea is. And what I don't expect is something that is super finished and where you have spends a day or two working on it."
And whenever someone asks us to do something for them, we should do exactly the same:
We should ask for an example, and a counter example.
When are moments in your workplace or in your service where people could benefit of you sharing examples and counter examples?
This is a first draft of a principle that might end up in a book of the "Service Design Principles" series.