What is Service Design?

In our field, we often tend to hear the phrase Service Design. Service Design is basically applying holistic user-centred design methods and processes to on- and off-line services. The Design Council has put together a good introduction to the field.

“A service is something that I use but do not own […] Service design is therefore the shaping of service experiences so that they really work for people. Removing the lumps and bumps that make them frustrating, and then adding some magic to make them compelling.”

In my personal experience, Service Design is often triggered by the opportunity of providing a better customer experience at a better cost by using mobile, digital technology. In the last 7 years, most of the opportunities of innovation in service design are coming from the mass adoption of internet-enabled, touch-friendly smartphones.

However, my interest does not stop with Smartphones. Often, working on a Service Design project is an opportunity of tackling the design problem from a holistic perspective, looking at the experience through different touchpoints, such as email, post, retail points, customer service and so on.

Customer Journey Maps, for example, are a great tool for documenting existing customer experience, and show how customers shift through different touchpoints to reach their goals. Customer Journey Maps strongly resemble user flows/journeys, with the exception that the design needs to represent multiple channels, in a swim lane fashion.
customer journey map

Ethnographic research methods can be required to fully understand the context of use. In my experience, ethnographic research projects are really good at getting under the skin of a product or service. It’s a great way of stepping outside our comfort zone and put ourselves in the shoes of the customers.

If you are a designer and you are interested in getting to grips with the methods and techniques of Service Design, I would recommend this book:

This is Service Design Thinking
(BUY on Amazon.co.uk)

This little video introduction hints about what the book covers

Other useful Service Design resources

Service Design Tools

Service Design Network


Aviation, Human Factors, Automation and Modes

As a design community, we tend to forget how User Centred Design is not only employed in building customer-facing experiences. UCD and Human Factors are also used to design plane cockpits, submarine and nuclear power plant C&C rooms. The latest episode of 99pi does a great job of explaining why designing for automation can mean the difference between life and death.
Human Factors have a long history in Aviation. The first Human Factor studies were carried out during WWII, and focused on incidents related to human error and such. With the advent of automation, one of the key roles of Human Factors has always been to design automation in such a way that human lives would not be in danger, or at least reducing the risk of that happening.

I was lucky enough to work tangentially to Human Factor design professionals for a few years at Thales, and look at decision support system, naturalistic decision making, Abstraction hierarchies and all that sort of things.

With automation playing an increasing role in a number of areas, think of self driving cars, what can history teach us in designing such interactive systems? Automation can be a double-edged scimitar; when it works it’s great, but when it fails it leaves the pilot with a serious lack of hands-on experience in flying the plane.

Automation can prevent mistakes caused by inattention, fatigue, and other human shortcomings, and free people to think about big-picture issues and, therefore, make better strategic decisions. Yet, as automation has increased, human error has not gone away: it remains the leading cause of aviation accidents.

From a New Yorker article: The Hazards of Going on Autopilot

The more a procedure is automated, and the more comfortable we become with it, the less conscious attention we feel we need to pay it. In Schooler’s work on insight and attention, he uses rote, automated tasks to induce the best mind-wandering state in his subjects. If anyone needs to remain vigilant, it’s an airline pilot. Instead, the cockpit is becoming the experimental ideal of the environment most likely to cause you to drift off.

In the cockpit, as automated systems have become more reliable, and as pilots have grown accustomed to their reliability—this is particularly the case for younger pilots, who have not only trained with those systems from the outset of their careers but grown up in a world filled with computers and automation—they have almost inevitably begun to abdicate responsibility on some deeper level.”

Enjoy the 99pi podcast, ‘Children of the Magenta

we don't need designers who can code

We Don’t Need More Designers Who Can Code

A great excerpt from the Article “We Don’t Need More Designers Who Can Code“, by Jesse Weaver

“Saying designers should code creates a sense that we should all be pushing commits to production environments. Or that design teams and development teams are somehow destined to merge into one team of superhuman, full-stack internet monsters.

Let’s get real here. Design and development (both front end and back end) are highly specialized professions. Each takes years and countless hours to master. To expect that someone is going to become an expert in more than one is foolhardy.

Here’s what we really need: designers who can design the hell out of things and developers who can develop the hell out of things. And we need them all to work together seamlessly.

This requires one key element: EMPATHY.

What we should be saying is that we need more designers who know about code.

The reason designers should know about code, is the same reason developers should know about design. Not to become designers, but to empathize with them. To be able to speak their language, and to understand design considerations and thought processes. To know just enough to be dangerous, as they say.

This is the sort of thing that breaks down silos, opens up conversations and leads to great work. But the key is that it also does not impede the ability of people to become true experts in their area of focus.

When someone says they want “designers who can code”, what I hear them saying is that they want a Swiss Army knife. The screwdriver, scissors, knife, toothpick and saw. The problem is that a Swiss Army knife doesn’t do anything particularly well. You aren’t going to see a carpenter driving screws with that little nub of a screwdriver, or a seamstress using those tiny scissors to cut fabric. The Swiss Army knife has tools that work on the most basic level, but they would never be considered replacements for the real thing. Worse still, because it tries to do so much, it’s not even that great at being a knife”.

The first secret of design is … noticing!

I just finished watching this great talk from Tony Fadell, at TED this year. Tony is the Lead Product designer of the iPod and of the NEST Thermostat. This talk is thoroughly enjoyable and it does a great job of getting a simple  message across: why is Product Design and UX so important today?

Tony takes us through his design principles in the typical 18-minutes TED format. He does it with great passion and emotional intelligence. What is Habituation? Why do we get annoyed at problems and then stop caring? Why is it so important to notice the tiniest details? Why sometimes the solution involves taking a step back and looking at the problem together, as a whole? Why do we need to think like young people to get a fresh perspective?
It is great to see how Tony can deliver this message with superb simplicity and clarity.