Last week, I was having a chat with someone. (Hello, Zuz.) We were talking about agile/Agile and service design/Service Design. More on that bit another time.
The chat ended up circling – yes, like vultures in the desert, I guess – around some case studies in the book This is Service Design Thinking. The chat reminded me of a nagging feeling when I read the case studies the first time a few years back:
Why in these cases did they choose service design as their approach? What motivated them?
It’s a common theme of missing for me, the why.
Take that trusty stead of design, personas.
As a dot-dot-dot, I want to dot-dot-dot, so I can dot-dot-dot.
My issue with personas is usually they skip this why as well.
Personas don’t tell enough of a detailed story, leave gaps, and allows the reader’s brain to fill in the gaps. Brians are very, very good at that. This means imagination comes into play, even assumptions, and devalues any empathy.
Where are the desires, the wants, the needs in these?
While we collect and build personas, while we research needs, rarely do we put the two together.
This isn’t a delcaration that personas are hackeneyed. They’re a good base. Build on them.
Move them on, from as a something to provide context, put yourself in the situation, in the person’s shoes, explore the when I am here.
When dot-dot-dot, I want to dot-dot-dot, so I can dot-dot-dot.
I used to check briefs before they went into the creative team at Brahm – and constantly asked Why?. Apparently this was annoying. I wasn’t being an awkward arse, honestly. I wanted to understand why we were doing what we were doing, why being not goals, but motivations.
“Sales are down, they need a boost.”
“Market research shows people are actually looking for this product.”
“We’ve tested these ads and we’ve got a direction on what works strongest.”
“The client just wants us to do it.”
“If we do this I will look good for my boss and get a much-needed pay rise.”
There is always a reason, there are always motivations. Recognise motivations. You can then work to solve the actual problems, the actual needs. And that’s not asking the impossible.