Thought / Better experiences and Service Design

Service design seems to (still) be one of those things everybody wants and is doing. It has arrived from and to conferences, it is asked and sold to clients to diversify and enhance their brands while keeping the customers and users satisfied. So it might be time for everybody to think what Service design is. Perhaps a definition might be difficult to grasp, let alone to utter, and I might not be at the level to summarise it in a sentence, so I’ll try with an example, and as such I’d like to compare it to a product, its eternal nemesis.

A car is a product. Some car company designs it, engineers it, produces it and sells it to you. You now have one way to go from point A to point B and back, and even listen to the radio news while waiting in point C for that traffic jam to clear. When you buy the car, you’re buying transport, a means to an end, the freedom of being able to go anywhere whenever you want to. You’re also buying tyres that wore out, an engine that might break, a gear system that you have to switch in order to advance, windshield that might break, wipers that stop wiping, gas tank to be filled every now and then, and so on. Later, once you own the car, you’ll realise you need insurance, and if you crash into that fat guy while checking out that blonde, you also buy a device that might spend days in the car shop, while being disemboweled and reconstructed and then it might work again. You might find yourself in the middle of a highway while it rains cats and dogs, you might be robbed of your precious vehicle, you might lose it to a lucky double deuce on a frantic poker night.

So when you buy a car you buy a solution to a necessity (to go from A to B) together with a myriad of other problems (how to keep the solution from dying on you).

Cabs are a service. If you need to go from A to B, you raise your arm, hail one of those yellow/black/white automobiles, open the door, utter where B is, and sit back and enjoy the ride, or suffer it. You get to B, get down, pay the fare and run upstairs to your next life event. When you hail a black cabby, or a yellow cab, or a white taxi, you’re buying the ride. Which might be the same reason you’d buy a car, but this time without the blonde and the crash, no worries about missing the insurance renewal deadline and careless if your tyres are worn out.

So a service is that series of processes and events that allow you to get (and pay) for exactly and only the one thing you really need, and get it, no more and no less.

Most of us when talking about a service we imply what is called the touchpoints of such service: the teller on a bank, the credit card paypoint, the salesperson on a store, the McDonalds unresponsive teenager, the idiotic ever-broken cash machine, the screen of your cellphone or even the cellphone itself. A normal thought if we realise touchpoints are the service’s faces we deal with.

Essentially the service is all that makes your money be there when you need it, the burger to arrive to your mouth when you are hungry and the conversation with someone, countries away, to happen. Since a service is a very complex system of events most of which are invisible to us, I’ll divide it structurally into front-end (touchpoints) and back-end (framework).

Most companies have endorsed and advocated for their provided services by creating “better experiences for the user” and a million other marketable phrases of the same genre. Those companies have improved much, and we might even be glad of it, very glad indeed; but their reach might be that of just the touchpoints. Airline counter crew smiling more than Ronald McDonald, call centres where they seem to be so high a hysterical laugh might escape any minute, promises of “better support”, “seamless communication” and “improved interface”, salespeople that simply love to make a deal with you while making you feel “the master of your domain”. And a month after you find yourself on the other end of an hour-long call centre chat that suddenly drops down, or having at home seven versions of the same modem, all of which don’t work exactly in the same way; and you wonder where the bloody hell is that service they promised you.

The answer is nowhere. That service was never there. Touchpoints, all of them, were elegant, serviceable, happy as teletubbies and polite as grannies, but completely unsupported by a real service backbone, the framework that makes the modem arrive to your home and work, or the system that makes your call convert into the satisfaction of getting what you’re paying for.

Service design is about making things go from A to B, not to paint in rainbow colours touchpoint A so you buy it and then figure out where on earth is B and how to get to it while holding your tears or saving your bullets. Don’t get me wrong, it is also about making point A and point B as satisfactory as it’s needed for you to want to traverse them, but that need/initiative seems already embedded in the culture of currently successful service design enough not to make me worry that much. However, we might touch it in a coming post.

As an example of how services might be perceived and delivered, I’ll mention FedEx ((I am in no way advocating for FedEx as an example of good service, only using it as an example of a promise and a fulfill, relation that is the cornerstone of any service.)). The worldwide known courier post company FedEx don’t promise a nice box delivered to your home/office, it promises a nice box whenever you need it to be whenever you need it to be, “absolutely, positively overnight”. And that’s what you’re buying. That is the service. A nice anecdote on how that service was born is given by Business Journalist Roy Rowan in his book “The Intuitive Manager”:

He cites the birth of Federal Express, the company that created the market for overnight mail delivery. The idea for the business first came to Founder Frederick Smith while he was a student at Yale writing a term paper on the parcel-service system. Much later, while he was flying combat missions in Viet Nam, Smith developed his notion of an “absolutely, positively overnight” service.
Hailing the Eureka Factor

I don’t really know if that anecdote is true, but it does not need to be for the idea of FeDex service to live, as many of their ad campaigns have stated it over and over, and it has become the promise, the need to be fulfilled. If a FedEx nice-boxed package does not arrive when they told you it will to arrive, the service is broken, and you might not feel a satisfied customer, period.

In this era of so much discontent with pollution, consumism and sustainability, services are one way (the only, perhaps) to attain the most of those, so we might as well get our heads straight and our goals fair and aim for getting our users from point A to point B, “absolutely, positively overnight”. Not just giving them better experiences.

Continue the reading:

Thought / Productivity in big environments

While reading this post on Looks Good Works Well by Bill Scott, I started wandering about scale and methodologies. As Scott mentions, when he started using Extreme Programming in agile methodology, it worked for him when not taking it literally or dogmatically, but as guidelines that informed his process.

I wonder if that is not a result of scaling (up or down) the method to the process.

As I see Jason’s approach to work, it more and more seems like ideas that have arised from his own experience at 37signals, and thus are informed by many a characteristic of his own enterprise, such as scale, dynamics and communication methods. An excerpt of Jason’s key points from the article:

(note: this does not pretend at all to be a questioning or judging on Jason’s arguments, it is just a personal reasoning started by these points)

Keep your team small
– Forces you to focus on what’s important
– Clearer communication comes for free
– “Communication usually fails except by accident”

Collaboration is about communication, not control
– Keep your team apart. Interruption is not collaboration. Interruption is the enemy of productivity.
– Encourage alone time
– Stay away from each other as much as possible
– Communicate more passively, less actively.

Meetings are toxic
– Usually a symptom of a problem, not a solution. Mentioned a business leader in Brazil who advocates that all meetings are optional.
– Meetings convey an abysmally small amount of information per minute
– Require thorough preparation that people rarely do
– Tend to procreate

Instead make tiny decisions
– Decisions are progress
– Progress is great for morale

Most of these points are sound and seem to tackle rather well some inner problems of company productivity. Yes, meetings consume valuable time in a rather unefficient way, and yes, uninterrupted time might prove as a very productivity-savvy tool, and yes, keeping your team small helps having an eye on mostly everything.

But (and this usually tends to be a big but) what if you’re handling the intranet design for such a multinational behemot as Dresdner Kleinworth or Accenture? How small your teams can be? How many conferences and meetings you might avoid before the team is completely uninformed? How many uninterrupted time you can have before you fall out of the client’s loop?

My way of seeing it, and where de weakness is, is that all that smart and sound advice is directed and intended for a rather small audience: that of start-ups, small companies, design studios; but it is not explicit in its wording.

Small is not necessarily better: Apple is great and big. Small teams can take care of some projects like, but not British Gas’ many service websites.Tiny decisions help keep things being done instead of being talked about (as it happens in meeting-driven and design-by-comittee cultures), but in a big project scope can be missed.

I am in no way saying I am contrary to these guides; I am convinced they work, and I believe in most of them as great guidelines to improve your workflow, project and product/service. I just miss the appropiated context on where to apply them, or better, from where to rethink and adapt them to the existing context.

There’s a great book S, M, L, XL by architect Rem Koolhaas. It defines a common ground from where to think about scale inside architecture. His approach is that every scale has its own advantages and shortcomings, and we have to focus on them to exploit them at their maximum. After all, it seems rather unlikely to pretend that you can build the Pyramid of Giza over Agile Architecture. But that thought might be completely wrong.

That’s one thing I might start thinking and working towards, as little has been said on how big companies can benefit from these forward-thinking productiveness-driven guides.

Thought / The picture of New

Lately I have found myself thinking much about innovation. It is a very difficult word to define these days, and it has to do with the marketing value it has.

Today I was looking at a fantastic picture from Reuters about a dreadful fall of Dani Pedrosa, a spanish rider for Honda, in the Japanese Grand Prix.


It made me think it was beautiful, even when showing an action we might label painful and reprehensive to enjoy. Its beauty came from beyond the situation itself. It came form the uniqueness of it, of the moment captured in the film.

Its beauty lays in its innovative way of showing a situation we already know how to interpret. It is an innovative picture, showing a new way of seeing what might have quotidien to recognise, a fall from a motorcycle, an event that can take secons to happen, and to which eyes are usually unaccustomed to perceive in detail.

Innovation in itself, as a word, means a new way of doing something, more or less. Photography has always depend on innovation, as it rests within showing us new ways of seeing the world that surround us, always surprising our accustomed eyes with uncommon images of what’s colloquial, known to our perception.

As far as I recall, innovation has not been a particualr search for photographers. It might be me but photographers don’t define their work as innovative in general. Breathtaking, incredible and impressive are adjectives that adapt and describe better waht great photographers do. And I start thinking innovation is not a spoken issue just because it is the most common of issues for a picture professional. It is so much part of what they do, it is a common place. It is what good photographers do.

Perhaps we designers should let it become a fundamental part of what we do in order for it to become what it might really be: a fundamental part of our everyday work.

Thought / A little research on wikis

I’ve been running a little research on how wikis can affect/improve communication processes for companies, enhance collaboration and consolidate files and information versions.

Here are some of the most interesting articles I have found (i’ll be updating it as I continue my check)

Case Studies:


  • Nokia and Vodafone Share Ideas – is an online community and a wiki for sharing ideas on how to use mobile communications for social and environmental benefits.
  • Microformats – Microformats are a way of adding simple markup to human-readable data items such as events, contact details or locations, on web pages, so that the information in them can be extracted by software and indexed, searched for, saved, cross-referenced or combined.
  • Lussumo Documentation – This wiki contains documentation for Lussumo software like Vanilla and the Filebrowser.
  • Freebase – Freebase is an open shared database of the world’s knowledge



Thought / About

A couple of weeks ago I was pointed to I went and check it, expectations high and excitement built up…

I personally expected more from a subdomain as, being it at the same (virtual) place as Flickr and Delicious (in the Yahoo family). We’re talking about one of the major players in the online world of today. Their vision of R&D might show the world what they’re striving for. And right now it does not amount to more than a couple of projects with future, a bunch of rehashed ideas, and a lonesome blog.

I think Design Yahoo has to hurry up and fill the subdomain with work, and not let it die of lack of content and a forgotten blog, as I also reckon the launch has happened a little too soon: the blog is already 6 weeks old and it has only one entry saying “Hi, We’re excited to share our work with you. Watch this space for more, soon.”. Define soon.

Everybody wants to be design these days, but the way is not to collect some mildly interesting projects and throw them in a cool URL, together with a blog and some videos, and then forget about the whole thing.

Anyone can do such a move. Yahoo, you can do better than that.

Update (28/11/07): After some days of uncertainty, finally awoke to the full splendor of their projects. Wish you the best of lucks.