Design Fiction Workshop: Failures

Saturday October 30 05:04

I’ve been away for awhile so obviously I’m just now catching up with some notes for the events and activities of the last few weeks. One thing I want to make a note about is the fun workshop that Nicolas and I facilitated at the Swiss Design Network conference in Basel Switzerland late last month. The workshop was largely Nicolas’ organization and we took advantage of the conference theme of “Design Fiction” to consider the topic of failure in design — failure as a guide and approach and provocation together with the considerations that design fiction can offer.

Saturday October 30 02:02

Nicolas has posted the notes from the workshop

It was a relatively short workshop — a couple of hours in total. Initially I was nervous that there would be not enough guidance to allow the participants to grab onto the material enthusiastically. That proved to be wrong. After an initial presentation that went over the topic of design fiction and failures that Nicolas had prepared, we broke the approximately 30 or so participants into groups of four or five individuals. There were three assignments that we had prepared that each group was meant to conduct. After completing each assignment — which lasted from 20-25 minutes each — the group turned inward and shared some summary insights, results and conclusions. They didn’t know all the assignments ahead of time.

Saturday October 30 02:24

The first assignment was to consider where and when failure happens in design. Without a specific definition of what constitutes failure, the assignment was meant to warm things up by creating a debate and set of examples as to what failure was and when and how it occurs. From Nicolas’ notes (my notebook has escaped me temporarily):

  • #Wrong hair color, not the one that was expected
  • #Help-desk calls in which you end up being re-reroute from one person to another (and getting back to the first person you called)
  • #Nice but noisy conference bags
  • #Toilet configuration (doors, sensors, buttons, soap dispensers, hand-dryers…) in which you have to constantly re-learn everything.
  • #Super loud and difficult to configure fire alarms that people disable
  • #Electronic keys
  • #Garlic press which are impossible to clean
  • #On-line platforms to book flights for which you bought two tickets under the same name while it’s “not possible” from the company’s perspective (but it was technically feasible).
  • #Cheap lighter that burn your nose
  • #GPS systems in the woods
  • #Error messages that say “Please refer to the manual” but there is not manual
  • #Hotel WLAN not distributed anymore because hotel had to pay too many fines for illegal downloads
  • #Refrigerators that beep anxiously to indicate the door is open, but do so even when you’re busily loading groceries.

This assignment was useful to begin the thinking about failure. The goal was less about creating a definitive or definitional list and more about thinking beyond and using examples as motivators and things to think with.

Saturday October 30 02:39

The next assignment was essentially the first but to create examples that one might anticipate as a typical failure in the future — the design fiction failures. Things that could occur given that everything fails to meet our highest expectation or (as I’m particularly interested in) the highest of the hype that surrounds new designed stuff. Epic failures, or just routine annoyances were all open for consideration. How might the cloud computing promise fail in both the major disaster ways — as well as the small, wtf!? sort of ways.

Again, from Nicolas’ notes:

  • #Identity and facial surgery change, potentially leading to discrepancies in face/fingerprint-recognition,
  • #Wireless data leaking everywhere except “cold spots” for certain kind of people (very rich, very poor),
  • #Problems with space travelling
  • #Need to “subscribe” to a service as a new person because of some database problem
  • #People who live prior to the Cloud Computing era who have no electronic footprint (VISA, digital identity) and have troubles moving from one country to another,
  • #3D printers accidents: way too many objects in people’s home, the size of the printed objects has be badly tuned and it’s way too big, monster printed after a kid connected a 3D printer to his dreams, …
  • #Textiles which suppress bad smells also lead to removal of pheromones and it affects sexual desire (no more laundry but no baby either)…
  • #Shared electrical infrastructure in which people can download/upload energy but no one ever agreed on the terms and conditions… which lead to a collapse of this infrastructure
  • #Clothes and wearable computing can be hacked so you must now fly naked (and your luggage take a different flight)

I was particularly taken by the 3D printer example. There’s of course lots of excitement about the possibilities of 3D printers in the home so that everyone makes their own stuff that they need. But, making stuff is hard and inevitably open to all kinds of crazy failures such as described here. Also — what do people do with the materials when they mess something up? How is the plastic (or whatever it ends up becoming — maybe noxious nasty stuff) get recycled? Will there have to evolve an entire system of rematerializing the goop? What about the equivalent of the print failures we often experience where one document ends up printing one letter per page, after page after page and we don’t notice until fifty sheets of paper have been used? Or when we scale something wrongly and the machine blindly goes ahead and prints something at 3 meters when we meant 3 millimeters? All these sorts of things will happen — can we use these insights to help make decisions about what and how to design? Can we start to communicate these failures as a way to design not with the expectation that the world is perfect — but that the results of designs have chinks and kinks in them?

Saturday October 30 02:39

The final activity was to think about possible taxonomies for designed failures — what are the types and kinds of failures as we’ve discussed them in the previous two assignments?

  1. #Short sightedness/not seeing the big pictures
  2. #Failures and problems that we only realize ex-post/unexpected side-effects
  3. #Excluding design
  4. #Bad optimization
  5. #Unnoticed failures
  6. #Miniaturization that doesn’t serve its purpose
  7. #Cultural failures: what can be a success in one country/culture can be a failure in another
  8. #Delayed failures (feedback is to slow)
  9. #When machines do not understand user’s intentions/technology versus human perception/bad assumptions about people (”Life has more loops than the system is able to understand”)
  10. #Individual/Group failure (system that does not respond to individuals, only to the group)
  11. #System-based failures versus failures caused by humans/context
  12. #Natural failures: leaves falling from trees considered as a problem… although it’s definitely the standard course of action for trees)
  13. #Good failures: Failure need interpretation, perhaps there’s no failure… alternative uses, misuses
  14. #Inspiring failures
  15. #Harmless failures

Why do I blog this? Well — just mostly to get some notes from the workshop up to share. I’m learning quite a bit from Nicolas on the failures theme, and perhaps its a way to answer a question that Chairman Bruce has lofted — now that we “get” the idea of design fiction and it seems to be inspirational for folks and useful in that regard — witness the theme of the Swiss Design Network conference this year. But..okay. We get it. Now what? How does the idea of design fiction either operationalize or become part of specific sorts of design practices in some informal or formal ways? It’s happening of course — all over the place and not because of this idea of design fiction itself, either how I’ve discussed it over the last 18 months or so, or how it’s been described and enacted by many people and agents. It’s not just about science fiction of course — and this was the topic of a paper at the conference that I may have the energy to describe in an upcoming post. But it is useful in very direct ways with the activities and goals of design generally speaking, that much is clear.

Design for Failure

04102008_100526

With regrets to Aaron for the blurry, noisy photo of himself..Taken in Montreal Canada at Design Engaged 2008.

For no particular reason — perhaps a salute to Nicolas who will be presenting his work on design for failure at IxDA this week — I bring you this image taken during DE2008 in which Aaron Straup Cope discusses designing engineering systems with failure contingency as the critical path.

Why do I blog this? I find this perspective intriguing — it assumes system meltdown, anticipates it and delivers appropriate data to indicate when it might happen. If I remember correctly, there is no specific interest in being exact about failure, just that it will happen and you might be told roughly how long until it happens. So the effort is to help stave it off by various means — adding more servers to spread activity loads around, optimize queries, increase caching, whatever you need to do. This makes me think of the intractability of designing for deletion. If someone wants to extricate themselves from the databases of a service or system, there is almost certainly no quick and easy way — in fact, I doubt there is anyway at all, and most services are not obligated to handle these situations. If I told Google that I wanted to check out fully and completely, even if they wanted to do this, it is doubtful they could. Would someone have to run through all the backup *whatever — tapes? — wherever they may be? It’s not just the live systems, and its not just purging caches and so on. All of our data is on its own, like orphaned snapshots of moments in our lives, somewhere. I don’t necessarily find this chilling or anything like that. I’m just curious about this notion — designing for intractable, ugly, messy circumstances, like failure or deletion. Things that run counter to the intuition — we usually design for the beautiful, full, glorious 32-bit conditions.
Continue reading Design for Failure

Anticipating Failure

Sign

I swear to GOD this is a friend’s “sig” line in her emails (she’s the hardest working IT person at a university department with lots of whining, illegal-software-downloading, computer-breaking-and-never-fixing, softdrink-drinking-right-by-fancy-computer-equipment students, so I have complete sympathy.)

Various Disclaimers:
MAD AT ME? My email load is heavy and some things end up in spam folders. If you think I have forgotten about you, re-send your email or send me an SMS.
ERRORS? I use a TabletPC. (Handwriting recognition is almost perfect.)

Why do I blog this? It occurs to me that these are all ways of anticipating failures of various sorts. Failures in the handwriting recognition software (inevitable..); failures to respond and anticipation of people getting upset because there’s no response inevitably resulting in a follow-up email with thinly veiled expressions of piss-offedness, etc. What are the ways that our technology forces anticipated failure? Does anticipating failure lessen the consequences? Can anticipated failure become part of specifications so we get out of the land of fantasy-advertised-feature-richness and get back to the pragmatics of how things actually work out in the wilds of normal, human real social practices?
Continue reading Anticipating Failure