Reflections on a day at the d.School Part Two
I can split this up into 3 general categories:
Booty Calls of Design
An Ode to Modularity
For today we’re we’re looking at the second.
During the afternoon sesh on saturday we had a very interesting storytelling experience. One of the fab’s put on “Destination Earth” and looped the song Andrew by Jonwayne. From a zine we retrieved 4 pictures, put them in a random order, and told a story withe them.
As your fearless narrator, I made some grade A bullshit about a tall dark and handsome man who’s actually a dinosaur in a frog princess ripoff of a fairytale. I knew it was bullshit and so did the group–but interestingly this was exactly the point. My story was bullshit, and so are many of the stories put out by companies.
When we try to incorporate stories, its occasionally done as an afterthought as my story was to these four pictures. Called in at the last minute to leave a deep and complex void, these are the booty calls of design.
During the session we directly explored storytelling. Often enough, we make a brilliant product or service and right before needing to sell it we go oh shit I need a story. That’s the booty call. Clearly, the product should have been designed with the story in mind the whole time.
Those who like to quote might call this starting with the end in mind.
The problem with adding the story at the very end is that it implies that the end user isn’t the focus. Yes its definitely possible to do customer discovery but not build out a story until the very end–however, by engaging customers in depth with how they feel and interact, we get their stories and can construct one out of those.
Quite simply, when designing empathetically, the story basically writes itself.
Another booty call of design that I had the opportunity to experience today (monday) is in the stakeholder map. The teaching staff for Design for Extreme Affordability told us that when they see others try to do something similar–particularly when partnering with NGOs–the stakeholders are nearly an afterthought that gets slapped on when you need a real mission.
When I write it out this way, it feels painfully obvious that not thinking about the stakeholders is ridiculous, and I have to ask who are you even designing this for then?
The way this manifests itself in class creation seems to be that people have this great and wonderful idea of something they can make students do. BUT, instead of figuring out who can benefit from it, they ask how can others benefit the class. Strategic partnerships with NGOs for example, end up being sources of ideas, instead of a platform through which to connect with the end user, and a group to whom the deliverables are for.
To remedy this, the DEA teaching staff had us make a stakeholder map for a hypothetical course. I found this particularly beneficial because I had no ideas for a new UD class, so instead of thinking how can I twist my idea to fit criteria, I could think about the honest needs of different people and make a hypothetical class that meets those needs.
This sounds surprisingly similar to the validated problem concept from something like the lean startup. It sounds like a shift that’s already been made in many entrepreneurial circles, just not experienced by less entrepreneurial groups.
There are a few other booty calls but they end up having similar results to these two–think about the customer (stakeholders) by validating problems and designing empathetically.
If you aren’t making something for those stakeholders, who are you making it for?