Archive for February, 2010
The Creative Habit, by Twyla Tharp, is probably the best reference I’ve come across for learning how to “sketch” in the performing arts. It’s a reflective look at her career as a choreographer and the lessons she’s uncovered for sparking creativity.
There are many systems of dance notation but that’s not what this post is about. For sketching we’re more concerned with techniques for generating and exploring ideas and it turns out that graphic methods aren’t a good fit.
Choreography reflects physical interactions between people and their environment. Early in her book Ms. Tharp notes that “you can prepare, order, organize, structure and edit your creativity in your head, but you can’t think your way into a dance.” You have to move. You have to feel your way through. She’s describing the limits of rational analysis; the need for an intuitive approach. For service designers the obvious parallels are informance and bodystorming, two approaches to physical brainstorming developed by Interval Research in the mid nineties.
The techniques involve improvising design solutions in context. Interval Research introduced the idea in a brief paper called Actors, Hairdos and Videotape [PDF 360K] at CHI 1994. The book Design Research, edited by Brenda Laurel, includes a more recent overview of informance by Eric Dishman, formerly of Interval Research, for more background. It’s more of a theatrical technique, so I’ll go into more detail later.
In the context of choreography, Ms. Tharp calls her improvisational style “scratching:”
When I’m scratching I’m improvising. Like a jazz musician jamming for an hour to find a few interesting notes, a choreographer looks for interesting movement. … It’s a habitual routine to keep you going.
It always seemed to me that one of the hardest things about sketching a dance would be remembering the ideas you generated out on the stage. Tharp addresses that point through the work of a Harvard psychologist named Stephen Kosslyn. There are four steps involved in the development of an idea:
With paper sketching it’s easy. The act of sketching on paper is directly tied to the act of saving those sketches. It’s a trivial matter to return to past sketches, inspect them and select the most promising for further development.
But with choreography, as with service design, the interactions are ephemeral. They exist only in the moment. Ms. Tharp originally tried to teach herself to switch into “capture mode” when she stumbled across an interesting step but that was inefficient because the process of continually evaluating her own movement and deciding what to save interfered with the concentration necessary to generate those ideas in the first place.
Her solution was a video camera. She tapes her improvisation sessions and then inspects the footage afterward to glean the most interesting steps. A little like the process a movie director uses to review dailies after a shoot.
For service design, I see promise in a team-based solution along the same lines. Two members of the team function as an ad hoc documentary crew, while everyone else works through a bodystorming session. The observers focus on capturing ideas that bubble up from the improvisation. Whenever they recognize something that’s worth coming back to, they jot it down or snap a photo (or if videotaping, note the timecode). Then afterward the team can review and rotate other team members into the role. This frees the team “onstage” to focus on pure idea generation without losing any of the insights.
I think my favorite aspect of Ms. Tharp’s philosophy is her concept of the “spine” of a performance. She describes it as the toehold that gets you started; the motivating idea. This kernel of an interaction is something that gradually builds as the rest of the performance takes shape. It’s not always apparent in the final analysis; more of an underlying structure. For me this notion of the “spine” of a performance seems to fit nicely with concept of a customer journey. I use a similar idea in interaction design — crafting one particular flow through a process that resonates with me and then branching out from that solution and allowing it to inform the balance of supporting interactions.
Another structural insight that I’ve found in several domains is the importance of sketching at multiple scales. Ms. Tharp calls this “zooming out.” When she’s learned all she can at the core of a piece, she pulls back and becomes detached enough to really understand it. For service design, the need to develop a holistic perspective is another reason to consider rotating members of the team into the role of observer during ideation. As you zoom out you start to understand the service encounter in context — both the spine of the performance onstage and the customer journey as a whole. That way the design works at multiple scales.
Finally, an insight won from painful experience. The human aspect of performance makes sketching with people inherently more difficult than sketching with paper or clay. People have feelings and that makes the decision to alter a scene or cut a part fraught with political consequences. In service design the same sort of idea applies. There are a whole series of motivations and incentives built into a service encounter that can’t always be pushed aside. If the solution to a problem involves designing someone out of a job there’s going to be some friction. It’s something for service designers to keep in mind.
Choreography has always seemed like a natural metaphor for service design. Both focus on the interaction of people and environments and when it comes to sketching a performance they share the same core principles.
. . .
This article is part of a series on how to sketch a service based on techniques from the performing arts.
Last October I visited the School of Design at CMU to give a talk on service design, exploring ways to “sketch” a service. It’s something I’ve been thinking about since Nick brought it up last year. Over the past few months I’ve been refining the ideas in that lecture and thinking about how to present them here.
The basic outline revolves around the idea that services are performances rather than artifacts and service design sketching can’t be approached like sketching in the graphic and industrial arts. If sketches are performances, then maybe we should instead look to the performing arts. What can we learn from choreography, theater, film and music?
The foundation of this exercise is Bill Buxton’s excellent book Sketching User Experiences. His investigation focuses on interactive digital experiences but the book outlines fundamental principles about sketching that apply to any discipline. For our purposes, the most important idea is that the value of sketching lies in the activity, not the artifact. The activity itself facilitates exploration, above and beyond the recording of ideas. In short, sketches are tools for thought.
Buxton identifies several qualities of good sketches. Attempts that are too well defined can be counterproductive during the early stages of a design process because they make it appear that the relevant details are already worked out. Rather than seeking to show, tell, explain or convince, sketches should:
According to Buxton, good sketches are also quick, timely, inexpensive, disposable, plentiful and ambiguous. These qualities are the guiding principles for my investigation.
Over the next few weeks I’ll work on translating ideas from the performing arts along with some relevant sketching techniques from screenwriting and a catalog of existing methods from the history of interaction design.
. . .
This article is part of a series on how to sketch a service based on techniques from the performing arts.
If you’re in San Francisco this week and interested in service design I’d like to encourage you to check out service design drinks this Thursday night. CMU alum Jamin Hegeman is organizing the event at Bar 821 on Divisadero in the Western Addition.
Service design faces an uphill battle here in the States and honestly Silicon Valley is the last place I would expect it to thrive given the area’s relentless focus on technology.
But let’s give it a shot.
Irene Ng’s new weblog from the University of Exeter offers some fantastic business perspective into services. Her recent post on systems thinking, service and business schools reads like a call for service design:
Who is responsible for customer experience? The answer is, of course, everyone and every discipline, but we know what happens when we say everyone — it basically means no one. Just like public goods. No ownership means no one will do anything about it. Business Schools haven’t even come round to discussing this yet — simply because no discipline owns the problem, the problem doesn’t exist right?
I really love the voice on her blog. The posts are extensive and rich with insight. It’s shaping up to be a must-read, particularly for those of us without MBAs.
I tried Zipcar for the first time this weekend and took the opportunity to examine the customer journey. It’s a great service in most respects, but I noticed a few quirks when I went to refuel the car. Hidden inside the fuel door was a blue sticker with instructions from Flexcar, a now-defunct rival car sharing service. Zipcar acquired them a few years ago and the instructions are apparently an artifact of Flexcar’s sticker-happy ways. The steps are pretty basic and while they don’t conflict with the Zipcar process they don’t inform it very well either.
Pumping gas isn’t supposed to be rocket science but the interaction design for payment seemed a little cryptic. When I inserted the Zipcar fuel card at the pump the interface simply displayed the word “DRIVER” in the top left corner. After a couple cycles in which the process timed out without activating the pump I realized that it wanted me to identify myself as a Zipcar member. The problem is that Zipcar assigns members both a “user name” and a “Zipcard number” but for some reason the interface didn’t ask for either. If the readout had used the correct terminology it would have been clear that they were asking for input, but I didn’t immediately recognize the word “DRIVER” as a prompt. Once I cracked the code the readout changed to display the word “MILEAGE.” By now I was getting the hang of the interface’s brusque interrogative style. Ideally you’re supposed to note the mileage before fueling. But it’s a six digit number and it turns out there’s actually a fair bit of rocket science before being asked to input the number. I’ve always heard that you’re not supposed to re-enter a vehicle during fueling because it increases the risk of static electricity sparks, but there wasn’t any choice so I ducked back inside only to find that the odometer on the Civic hybrid was digital and thus unreadable when the ignition was turned off. So I got back out, replaced the fuel nozzle, closed the gas cap and then restarted the vehicle. Noted the number, looked around for something to write on and, failing to find anything, scrawled the number on the palm of my hand.
Zipcar’s online gas demo makes it clear that they’re aware of the differences in terminology but in their video the fuel pump readout isn’t nearly so cryptic. Instead of “DRIVER” it says “Please enter your driver ID number then press enter,” as it should. It goes on to explain that “driver ID number” actually means “Zipcard number”. The video also shows the fuel pump asking for mileage first, a request that’s much easier to interpret. Both the phrasing and the order make a big difference, and raise the possibility that the individual gas station software at the pump might be to blame — I’ll go to a different gas station next time to investigate. Of course, that’s little consolation for beleaguered Zipcar members. If you can’t change the terminology in the interface, then at least adopt that terminology throughout the process. It’d be as simple as printing the words “driver ID” above the number on the Zipcard.
This facet of the journey illustrates the nexus of several different disciplines within a service encounter. Graphic design covers the Zipcar co-pilot manual, the renegade instruction sticker and the fuel card itself (which had helpful instructions printed on it). Interaction design informs the fuel pump interface, the call center helpline and the welcome e-mail that gave me an initial overview of the fueling process. You might even consider the potential for information architecture to establish a standardized vocabulary across touchpoints.
I can’t help thinking that the fueling process could be improved. Maybe attach a dry-erase marker or grease pencil to the sun visor and provide a spot on the back of the fuel card to note the mileage. Or maybe eliminate that step in the process altogether. I’m guessing that the driver id and mileage are for fraud prevention, but I can’t imagine how it works in cities like Portland where you’re not allowed to pump your own gas. Next time it’ll be easy but it’s tough to get over that initial bewilderment.