Member preview

A couple of weeks have passed since Service Design Global Conference 2018. I had the pleasure to be among the 800-odd service design practitionners/academics/supporters in Dublin this year. Below is a selection of the conversations I caught during my three days in Ireland (Irish people’s sense of hospitality was fantastic by the way and Cork was a great sponsor as they were able to demonstrate quite a mature take on Service Design themselves).

“All that is solid melts into air”

Borrowing (and rearranging) the words of Marx’ and Engel’s Communist manifesto, someone kicked off the conference reminding us that “all that is product turns into service”. The tone was set: we were among people that believe in the value of a well crafted user experience. The other dominent theme of most of the talks was implementation.

“Strategy with no shipping is #strategery” via Jess Leitch

We should have people who can ship in our teams — and not just when it’s time to implement. Implementation is not an add-on that we tackle towards the end of a project. Or in the words of another speaker:

“Start implementation on day 1”.

Design to Deliver

Blueprints — a service designers’ all time favorite — have been widely discussed. They often come in durong the second part of projects, in the so-called delivery phase (I personally dread that term as everyone involved in a project may have a different understanding of what is actually going to be delivered).

There are multiple layouts and ways to go about blueprints, everyone is encouraged to tweak them to each projects needs. One consensus surfaced among all the participants though: “Blueprints are not deliverables” !

“Careful of post-its lead transformation”.

It’s unfortunately not uncommon to see blueprints quietly gathering dust once hung up on a wall, as no one is taking ownership and updating it. Other times, a beautifully crafted blueprint pdf has been released as a pdf or a powerpoint file but as soon as the developers have started their part, it got replaced by Jira and other dev tools… and the blueprint never resurface.

I see two reasons for that: 1. they often come in too late in the project (the successful implementation of a service partly relies on the pluridisciplinarity of the team that designed them from day 1 — that includes dev)

“Have people who can ship in your team.” via Jess Leitch

2. most of all, blueprints are often created using designers tools like illustrator and that means they will never be updated by the dev team.

Paul Harrison, who serves as Service Design Lead and UX Architect at Wipro Digital (who recently acquired DesignIt), showcased his use of Realtime Board — a competitor to — to create blueprints that devs can actually use all throughout the project implementation.

SDGC18 — WiPro Digital — Members’ only day

It consists of an online whiteboard accessible with edit rights to both client and ‘consultants’. They called their canvas ‘The Project Wall’, as it contains all the elements generated during a given project: in addition to the Service blueprint you’ll find personas, data mapping, Data sources, metrics, content copy (e.g. emails), etc.

Most importantly, each step of the blueprint links to the corresponding user story in Jira, meaning that developers and designers can use the same document. Developers can then start their workflow on the blueprint which ensures they’ll grasp the fundamental WHY behind any single step they’ll develop. At any single time they can jump to Jira seamlessly to continue using the tools they are the most familiar with.

When something changes on the blueprint, the modification can be more easily carried to Jira too. To me this is the recipe for a blueprint that’s always relevant and up-to-date, and most of all it maintains the big picture view all throughout the project completion.

Other tip from Paul Harrison: focus on Vertical slices instead of horizontal swimlanes. Of course, as service designers, we love the horizontal nature of blueprints as they illustrate an experience that is much more than just a succession of screens. But our role as projects unfold is to bring many disciplines and people to work together intricately and collaboration is exactly what a blueprint vertical slice is all about.

Climbing up the ladder from design to Strategy

A few discussions around the nature of design have emerged in several talks, as you’d expect from a crowd of practitioners and academics.

There is a consensus around the idea that design has evolved from its hisorical industrial focus, to a process focus and towards what is now considered as a mindset. One that is relevant beyond the mere shaping of artefacts and that can be adopted by non-designers too.

It was suggested that the Design Ladder, which I often refer to when selling design projects, is in need of a 5th step to show this evolution. Designers at OP Financial Group described their work as aiming as the new frontier of design: culture.

I’m yet to see the validity of that lens on my own project but I admit it offers an exciting horizon to tend towards. They offered an interesting metric to quantify the penetration of design within an organisation:

“how many projects are utilising a design method from ideation to launch ?”

Is it 1 out of 10 ? 8 out of 10 ? 
I would personally say from framing to implementation.

Good to keep in mind: organisations don’t move on the proverbial ladder as a monolith, their evolution is more sketchy and it involves different functions moving at different paces.

More Service Design degrees coming

MA Service Design @ NCAD Dublin September next year

I wonder if students will be offered the pluridisciplinary collaboration they need to complete service design projects or whether it will remain a theoretical approach.

Shaping collaborations

Another aspect of service design projects I deeply care about is the very start of the relationship with both the internal client and the project team. We never start on a blank canvas. The words, the frameworks, the examples and the paradigms we use to sell service design (and more broadly any sort of innovation projects) have — I believe — a great impact on our relationship with the client and his team. The first meeting (or meetings) will no doubt shape this relationship and the lee way people will uncouncisouly grant us or not. This will impact the project and above all the implementation of any given solution that’ll come out of it.

Of course, it’s never too late to steer the ship into a different course, but a lot of friction can be avoided if we consciously set the expectations and the ground rules of collaborations at the very start of the journey — and what better than leading by example?
With this in mind, the following question made a lasting impression on me:

“Define your version of done” via Tim Macarthur

Does an developper truly understand what a service designer means when, after compiling verbatim into a service blueprint, he says the futur-state solution mapping is DONE? Debatable at best.

Tim Macarthur’s version of ‘DONE’ on a given project

The tensions between the frames

On the account of understanding the frictions that lie in the user’s journey, I find the following analogy is gold. Alok Nandy calls them the “the tensions between the frames”.

To me, it talks about why we spend so much time ‘on the field’ discussing with users and observing what they’re doing. We’re looking for these deep seeded needs that lie within them and that will never surface through your average survey. I will definitely make good use of this visual analogy in future trainings.

What are we reaching for?

SDGC18 was also the opportunity to have a closer look at what IxDA is doing in a slightly different — although clearly overlapping — field.

Interaction19 will happen in Seattle between 3–8 February and SDN members should have access to discounted tickets over the coming weeks.

Alok Nandy, president of IxDA, suggested these concomitant fields are reaching for connected goals:

Invisibility -> design
Memorability -> service design
Fluency -> interaction

Will you have a bit more Jam?

SDGC18 was also the opportunity to discover TTC Lab who gave an inspiring talk about their take on empowering organisations to design more privacy-friendly services. They describe their mission as:

The Trust, Transparency and Control Labs is a cross-industry effort to create innovative design solutions that put people in control of their privacy.

Their website is full of insights and their toolkit is available for download. It covers everything you need to run a design jam around privacy, plus plenty of templates (from persona templates to pre-jam to-lists, etc).

This blog is a great example of what can come out of a Jam on privacy: Giving granular controls for sharing.

Value stream map

I’ve heard some people talk (or was it on twitter?) about Value Stream map and I have to admit they are a great thing to play around with a model. I will attempt to use them more often in workshops and probably in trainings too. I believe they are relevant when discussing business model, especially prior to filling a whole Business Model canvas.

Mobile Ethnography

I can’t wait to include some mobile ethno in one of my project again. I think I’ll use the experience fellow this time as the tool seems to reduce collection time to a minimum so one can focus on analysing the data.

Not sure about Smapply though (created by the same team) as I don’t find the tool enough visually engaging and not as versatile as RealTime Board.

All tribes want their view of the world to be relevant

Great talk by Patrick Quattlebaum (@ptquattlebaum) who reminded us that as practitioners of different approaches such as Lean UX, Design Thinking, Lean Startup, Agile, Service Design, etc. our behaviours can often resemble those of tribes fighting for a territory.

His slide deck is worth the read as Patrick nails his storytelling and is quite funny.

One dimension that is quite telling is how these informal ‘clans’ tend to interact with each others. He reckons we can draw a parallel between our attempts to win other tribes members to our cause and Chiefdom strategies in the pre-industrial world.

Violence: speaks of itself (who’s never thought out loud such tool is far greater the other team’s tool and therefore WE should run the show…).

Alliance by mariage: e.g. forcing agile teams to do design stuff and design teams to seek Jira.

Rainmaker: advocating for the sort of value your approach fosters (e.g. velocity, cost effective, long-term…).

Generosity: (as far as I remember but I might be wrong) plastering the office with production of your own such personas here and there, maps and so on … hoping enemy tribes will ploe under the weight of our genereous visual diarrhoea.

Rituals and idols: where the avalanche of buzz words comes in and the Popes of your discipline are summoned to justify your method.

Adopt language: when people start using other tribes’ made up words to seek acceptance by others.

Service design a holistic practice

Although there is still no absolute definition of SD, it is clear the practice of SD can encompass much wider considerations than the mere experience design that marketing teams have gotten their hands on for a while now. The notion of business model is — to me — an integral part of service design.

Alberta Soranzo‏ @albertatrebla retold the classic Kodak tale in which the only missing brick for Kodak to nail its entry on the digital camera market was not technological, nor understanding the users’ needs, it was instead their inability (or fear) to challenge their business model — which was based on selling film. They therefore launched the first digital camera — the Advantix — where the digital screen could only show the picture once it had been taken, allowing the users to retake the shot if they realised it wasn’t good enough — in an attempt to push photographers to consume more film. You know what happened next…

So service design a holistic practice made at least of: user experience + business model. The business thinking can’t be removed from the equation.


We saw some great examples of SD projects.

My heart picks:

Musgrave: for laying out their methodology quite elegantly on their poster board. This one reasonated with me anyway as I kind of am in the target.

Fjord: some interesting use of data visualisation, partly to better understand the user problems they had to focus on, and partly to narrate that choice to their client. They used the term ‘data infused journeys’.

Cotinuum: for the large scale prototype they built in a 1,200sqm warehouse for their airport signalisation (including background airport noise for an immersive experience!)

Upon reading the First edition of the Annual Award book I saw that we jury is not so much interested in ‘the ingredients’ used to develop a given service but instead in how the use of these tools and techniques informed the end results. In other words, it’s about making a case for service design in your project. This implies a high level of transparency in the submission that applicants have to put forward (insights have to be revealed for instance) and I can imagine not all clients would be confortable with this. A lot come down to how you submit the idea to your client I guess.

Last but not least…

Some simple truths I’ll probably remind my clients from time to time

A great illustration of a (digital) experience:

Some snippets of common sense I’ll try to apply to my practice

Inhouse startup studio: there is so much you can do to showcase your workflow without disclosing your clients’ IP (confidentiality kills me sometimes!!)

1-to-1 takeaways among participants for the final 3min of a day’s workshop or training as Markus & Jacob did during their closing keynote.

Damn I feel so good having written all that, no doubt I’ll find it handy personally when in need to refer back to some learnings with colleagues and clients. Too bad I couldn’t include everything — kudos for the talks I actually liked the most totled ‘Creating Efficiency with Service Design’ from Eva Liparova.

Looking forward to SDGC19! (I won’t miss the workshop rego next year!)
Hope to see you there!

PS:One thing that I regret though is that the dates are not locked in already. It would make projects planning much easier (and allow for early birds tickets to be sold 12 months in advance).