A persona is the personified representation of a user or client group. Within design thinking this persona will be centered around coherent need-statements. The persona as method has initially been developed in marketing where personas were initially used as representations of demographic segments (e.g.: personas called "dinks" - double income no kids etc.). Persona´s in design thinking are distinctively different because they are not built around demographic or socio-economic attributes but around needs - the design thinking persona does not represent the 32-Year old married woman, but represents people who need something, e.g. sth. they can consume with one hand and without getting their hands dirty, while strolling the textile market (because they are not only hungry/thirsty, but also want to touch the textiles and can't do that with occupied or dirty hands).
“A design thinking persona is the personified representation of a need-statement.”
We might put a name and face and age and family background to the persona, that represents all these people, because that will make it easier to relate to the need-statement in the process of designing a solution that fits their need-statement. But the common characteristic is not the age or marital status - Imagine the following two persons:
You might have both of them, Fred and Veronica represented by the same persona. You might decide to depict this persona as a 35-Years old pan-sexual transvestite in an open relationship. Why can the 35-Year old represent both the teen and the granny? Because it´s not about age or marital status, the persona is centered around the clean-free-hand-hungry-&-thirsty-need-statement.
JOIN MY WEEKLY MAILS
About a year back, the U.S. Department of Defense published their guide for detecting Agile BS. Within their guide they included a graphic I thought was so inspiring that I re-created it:
Although I remain sceptical about the explicit language used, I find the graphic to be extremely helpful.
Nassim N. Taleb once said:
“If you see fraud and do not say fraud, you are fraud.”
Nassim Nicholas Taleb, Author of the Incerto Series
Encouraged by his words, I am in favour of calling a spade a spade, and calling out BS. So by rephrasing what the DoD said about Agile, I arrived at my own statement for the Design Thinking context. I share it below in written and graphical form to enable detecting Design Thinking BS:
Design Thinking is a buzzword of innovation management, and currently many product-, process- and even strategy-development-projects are, almost by default, declared to be using Design Thinking.
Running projects using a lot of Design Thinking buzzwords but not reframing the problem to a human centered design perspective and therefore mainly producing sunk costs.
The following questions and the below graphic provide guidance to program executives and acquisition professionals on how to detect projects that are really using Design Thinking versus those that are simply pretending to do so (what I like to call “design sinking”, because it mainly produces sunk costs).
Therefore the following questions can be posed to the program leadership:
For a team working based on Design Thinking, the answer to all of the above questions should be “yes”. If not - you may be running a successful project, but - you are not doing design thinking and there is a high risk, that you are wasting time & effort on what I call design-sinking.
So keep the above questions at hand whenever you enter a negotiation around Design Thinking. While it is totally fine to refrain from doing Design Thinking, let´s be honest about whether or not we are actually doing it.
Let me know what you think about this and your experiences so far in the comments below.