service design notes: tools, not services · 2007-04-11 07:15

I’ve been thinking about the differences between a service and a tool.

I hit this a few weeks ago – I bought a Nike+ pedometer, as I’m always pretty interested in quantifying my life. I wanted to use it just as a pedometer, recording my steps all day. Unfortunately, this is misusing the Nike+ service.

It’s all meant to be smooth – install the radio transmitter in your shoe (I had official shoes, so at least I didn’t have to hack that), plug the receiver into your iPod (nano only), run, then plug your iPod into the computer, and iTunes will upload the data to the Nike+ website (after setting up an account with lots of tedious marketing questions), where you can track how far you’ve run, etc.

I don’t run.

And that means I can’t play. I’ve been designed out of the service.

The Nike+ controls on the iPod try hard to make you use a playlist rather than albums, but worst of all, if you stop moving for 5 minutes, it stops recording and stops the music. You have to manually restart it using the centre key, which, to be sleek, is impossible to feel the difference from the click wheel.

The website is all about runs, which I could forgive, but for all the pretend science of graphs (they don’t even have scales), there’s not much useful information for serious runners.

I can see the persona on the flipchart now; aspires to run, started running recently (maybe in the January fitness drive), has an iPod nano – not a shuffle or a full iPod, willing to spend £20 / $30 on running technology, but not the 99 bucks or so for a low-end Polar watch. The moodboard would be young thing sweaty things running in sunny places.

Experience design dogma tends to teach designing for one person – if it’s good, it will draw in others. This might apply for niche services and products, but for the mass-market, I have changed my mind: it’s bullshit.

Designing for one person creates tight end-to-end services. But few companies control the complete end-to-end, and in fact, customers (people!) are wary – it’s normally an excuse to bleed more money out of people more regularly (“we can sell a product and a subscription!”) and to lock people in (how do you get your data our of Nike+?).

We want tools, not services.

And thinking about tools helps us design better services.

One of the hardest things when creating a service is telling people what it does, and how it fits into their life. This isn’t just a strapline, or a USP, though those help focus the thinking. It’s that moment of fear and confusion when you hit a service’s webpage for the first time and how well the designers alleviate that.

Tools, as usability 101 teaches, have affordances that display both the usefulness of the tool, and how to use it. This basic principle has been slightly misformed in digital services; you are generally shown what can be done at one point in time. Unfortunately, this is normally just sign up on the first visit to a site, then sign all your friends up. This is more text adventure game than tool behaviour. Formalities over the real usefulness.

Tools aren’t autonomous: they work with something else. Bank accounts, for example, are a tool to help navigate the money cycle. It needs the card machines, the merchants, the check cycle, and the cash machines to work. As bank accounts moved from being end-to-end services to tools, connected far and wide, they increased their usefulness exponentially.

Tools work with other tools. On the web, this tends to translate to backend pluggable mechanics; RSS, Atom, APIs. Being able to pipe information in and out are vital for digital tools. Twitter works because it piggybacks on email, IM and SMS – and people have already learnt of ways to deal with these communication mechanisms. Little new to learn, other than what comes out where.

Matt said that one of the questions posed at the beginning of designing Dopplr was “can we make a web service you never visit?” – and this is tool thinking. It’s deferential, subservient and polite; normal web services are arrogant (you have to visit them, they never come to you – if they do email you, it’s just a link to get sucked back into the service), and overbranded – do you really need sweaty young things on the Nike+ website that you’re meant to use several times a week? As an aside, this kind of ur-user imagery often excludes the target market rather than being aspirational. Dopplr doesn’t have some wallpaper*esque international jetsetters on the home page – it has pictures of your friends.

Tools are zuhanden – ready to hand. They should disappear in use, they aspire to be forgotten, but are absolutely necessary and useful. There’s money in tools. Tools can be used by more people for more purposes. Tools will be bent and misused – which means you sell even more. And you don’t have design in the usefulness – just find the useful functionality and package it up in an open-enough way to show possibilities.

I just received an email from the past – I set Backpack to remind me of something a year ago. I’m not using Backpack in earnest at the moment, but continue to pay for just this kind of magic that I’d forgotten I’d set up. And this is the big advantage of digital tools over physical ones – they can communicate, or signal when necessary. It’s unclear if the first products that blur the digital and physical boundaries – chumby, nabaztag – have taken the right lessons from tool design and service design.

comments

<< previously home furthermore >>

© Chris Heathcote, 2002-2010. I write for me, not for them.
CSS styling from plasticbag.org