Spikes*

[* attention-conservation notice: long, somewhat self-indulgent post ahoy… sorry!]

From the latest Cooper design newsletter: The high risk of low-risk behavior by Wayne Greenwood, Chief Design Officer.

“Companies often speak of innovation in their brochures, only to engage in what they consider to be low-risk business practices when developing a new product. Instead of innovating, they build a product very similar to their competitors’, only marginally better or cheaper, perhaps with a few more features. There’s a sense of comfort at many companies in this middle of the pack mentality. It seems safe-certainly safer than sticking your neck out and doing something different.

But is this really a safe practice? Not for companies in the software business.”

Welcome reading. A lot of people linked to Alan Cooper’s debate with Kent Beck on User-Centred Design (is it capitalised yet?) and Xtreme Programming. It’s something I had thought about [ PPT presentation, 76k ] and left somewhat unresolved a while ago.

In writing the presentation, I talked to a few coder friends and colleagues about their experiences of XP. It seemed a lot more fun than UCD/IA practice!!!

Many features of the methodology seemed to encourage innovation, chance, and the taking of risks; such as paired coding– where two coders shared a keyboard/workstation to figure stuff out in tandem, and the practice of creating “Spikes”. These are effectively many, many guesses at potential solutions, roughly implemented to assess their fitness for purpose.

It’s that expansive, divergent, daring drive to spike the project – to keep opening things up – to sustain the maximal set of possibilities for as long as possible in order to find the most promising path that appeals.

Maybe it’s just post-holiday blues, but lately I’ve been bored stiff by best practice. User-centred design and information architecture seem stifiling right now. Various factors have conspired. Watching the Larry Page lecture, and his commentary on Googles practice of watching the technological landscape for inspiration; reading subversive, mind-corroding comic books; and getting inspired by artists who play with technology just to see what might happen – have all left me feeling a little straightjacketed by the dogma of “Don’t make me think!”.

A big dark cloud descended on me last night. In the morning I’d been jamming with a mate on some technology / product problems. Absolutely product/tech-riven ideas. Lunatic nonsense. Potentially ungraspable apart from by us and maybe a geeky, early-adopter percentile of our audience. Fun! Spent the afternoon confronted by (unrelated) realities of accesibility, compatibility, appropriateness and implentation… the morning felt like a guilty pleasure I had to consign to a secret chamber of my mind and shackle there. I had a come-down as profound as a drug experience! It was horrible!

Shook it off – realised a way through the problems of the afternoon, and let the fun of the morning bubble back into the brain a little… Then came the dark cloud. What was it about UCD that felt so reductive? I’d rambled negatively about it before in order to reason it out, maybe get it out of my system; but that hadn’t worked – obviously.

Went to the Paul Klee Exhibition at the Hayward gallery after work. Good fun, although I find much of his earlier work unprepossessing… but hey, I’m no art critic – as will become apparent in the next sentence, but stay with me. Striking though was the way he seemed to try and create “spikes” for himself… varying technique, approach and analysis of the creative act, in order to get closer to the things he was trying to resolve.

I want to make some mistakes. I want to frustrate people. Make them think. Let a thousand interactive flowers bloom, or maybe just take a piss in the herbacious borders of UI. I want to make something that is driven purely by technology, looks absolutely bloody beautiful and confounds the hell out of everyone – leaving them guessing why the hell it might be useful to them, but knowing absolutely that they want one.

Of course the trick would be to have this desirability bourne atop a platform of stability and appropriateness. Ol’ Vitruvius’s triangle of Commoditas, Firmitas and Venustas.

But I don’t think you can do that every time.

When you do you are damn lucky. Sure – you’ve got as close as you can to making your own luck through your approach and the teamwork of the people around you – but you still need that luck, that creative act, that leap, that spike to get you there.

Sometimes I guess it seems that we IA/ID/UCD types as a community strive so hard to drive the useful and usable into our work and the work of our colleagues in other disciplines, that we don’t leave room for that.

Some of the pre-eminent voices in our field of practice seem to be questioning this now, and that’s welcome.

So anyway, now is probably not the greatest time every to ask one’s bosses or clients to let mistakes be made, let risks be taken. I’m probably going to have to make the mistakes I need to make happen on my own time and in my own little sandbox – but hey – I’m going to slip ’em a copy of the Cooper newsletter and see what happens…

0 thoughts on “Spikes*

  1. Thanks for the inspiring post! Very interesting ideas – especially for someone like myself just starting out in the field. I think I’ll slip my boss a copy of the Cooper newsletter as well.

  2. I read the Cooper/Beck article and laughed my head off. It seems like each one of them was protecting their own turf without trying it out.

    I’m an interaction designer who has been using XP methodology for the past three years. I pair up with a programmer and we spit out one release after another. The beauty of the system is that we can do user-testing at EVERY release and get immediate feedback. During these tests the programmer focuses on the functional acceptance while I look at the user acceptance. The client sees constant work, not “design” then “prototypes” then “release one”.

    The biggest problem I find is users will react differently to each visual we see (paper, mockup, actual). By always showing them the actual interface (be it HTML or Java) we get them to make real constructive critism. We can implement the visuals early so we don’t have to use the words “imagine it to be” or “please focus on this” or anything else to make them forget their current mode of thinking.

    At first it’s going to be hard to implement. Stick with it. It’s well worth it.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.