Collaboration – that’s the name of the game

Oh, no wait – that’s multiplication. But in a funny way, it still works. Cue quote:

“The range of our collective vision is far greater
when individual insights become one” Andrew Carnegie.

Amen Andy.

As designers we espouse the value of collaboration. But what I’ve noticed in my years in the game is sometimes a designer speaking about collaboration is a little like the overweight dietician; oh sure, they say the right things, but they like their doughnuts on their own. This post is about collegial collaboration, that is collaboration with fellow designers. Working with clients and customers/users is largely the same, but you can be a little rougher, so to speak, with colleagues. And I guess I’d qualify that ‘co-design-collaboration’ has a few more etiquette rules around it which I’m not drawing out here.

A potted history of my relationship with “collaboration”

A few years ago a small group of us (three) organised a corporate leadership forum with the underlying theme of ‘Collaboration’. My role was to come up with the content and exercises for all the senior executives to present. Two key things came out of the experience:

• A deeper understanding of what collaboration actually means because I had to break it down for the executives
• A truly excellent and joyful collaborative collegial experience

Prior to forum I hadn’t thought much about collaboration. Yeah, yeah, people together, goals, outcomes, blahdey-blah. But this is where being a designer gives you the opportunity to dig into and behind the assumed. Some important definitions:

• Collaboration: multiple people working together in a mutually beneficial and well-defined relationship to achieve a common goal
• Co-ordination: the bringing together of different and multiple working elements for consolidation towards a shared outcome

When we couldn’t get copyright to a collaboration model in time I had to produce one overnight as a Plan B. Broadly speaking there were five elements to the CLEAR model:

• Communication between partners (trust, respect, constructive conversation)
• Leadership of people and process (someone’s gotta be clear about the why, how and what)
• Engagement of a shared outcome (everyone has to be on board – willingly)
• Accessibility to participate and contribute (the process itself and how to contribute is explicit)
• Responsive to future collaborative activity (learnings are shared – bearing in mind this is a corporate model, so that really means shared across the organisation)

It was from this work that my consciousness of true collaboration emerged. Simply bringing people together doesn’t guarantee ‘collaboration,’ it’s more likely to be frustrating for all concerned. Collaboration is about people working together, and in our designerly world of multi-, inter- and trans-disciplinary groups (nod to @vickytnz for highlighting the categories, see PS at bottom) People + Techniques ÷ Intent = Magic Happens doesn’t always work out.

Three examples of collaboration : the good, the bad*, and the ugly

Example 1: The Good

- Creative design making a tangible product

• The situation: With virtually no time together – except for a 30 min session, midnight emails, and passing in the hallway – the two of us involved had to agree a concept, content and activity ahead.
• The scene: During the 30 min session we shared a flood of ideas and expectations based on thinking we had been mulling on from initial conversations. Whiteboards, sketching and prototyping was involved.
• The collaboration part: As the ‘maker’ I knew the basic concept and constraints we’d have to work within but it was still messy and fuzzy. Through the conversation and sketching a clear and shared vision emerged, we had clear roles and clear responsibilities and no one voice was stronger than the other.
• Why it was beautiful: For my part, I had made things like this before but with Obi Wan CLEARnobe in my head saying “Use the collaboration force, Mel” I shut up and listened. I used my experience as a framework for the discussion not as the content. What we came up with together was far cooler than any one of us could have come up with on our own. And it was still make-able.

Example 2: The Bad (as in Michael Jackson ‘Bad’, so Great!)

- Conceptual visualisations of complex and complicated strategic outcomes

• The situation: Making sense of voluminous and complex information and nutting out next steps
• The scene: In a room, piles of paper, client urgency, clarity unclear, a whiteboard, four designers
• The collaboration part: A time was blocked out with no agenda set. We just started talking. We all brought something to the discussion – some different aspect of understanding. Someone was referencing the data, a couple riffed on experience with the organisation, someone directed someone to capture key points on post-its so we could move them around as our thinking moved around, people would get up and re-frame the capture. Someone reminded the group of pragmatic boundaries. There was conversation, there was dialogue, debate. What was said would be built on by another. Questions provided deeper insight and spread deeper understanding across the team.
• Why it was beautiful It was dynamic, hugely productive, relatively short time-wise, fun, funny, bonding – in a team, and knowledge understanding sense. It produced a better outcome than the four of us going away by ourselves and bringing our thinking together.

Example 3: The Ugly

- Working out an approach for upcoming prototyping activity

• The situation: Group of designers with mixed expertise in design method and varying levels of practical experience trying to scope and plan a series of prototyping activities
• The scene: A time was set but no agenda set. One person reading track-change notes off a computer that one other person was marking up on the only copy of the document. Same track-change person doing all the writing on the whiteboard and saying things like “Let me just write this up before we go any further” “What I want is…”, “When I did something similar I…”
• The collaboration part: n/a
• Why it was ugly: One person turned the collaborative session into a meeting where they were Chair. They also used their personal reference points as the predominant ones – so little experience in prototyping meant the person’s experience in facilitating a usability report deliverable framed the conversation. The experience at the table was also weak so the dominant personality could not be constructively challenged. The real trouble in this example was a collaborative intent was crushed by a more senior person’s insecurity with the design process itself.

So, to sum up, good collaboration to me is:

• A conversation: Just like design is the conversation, and the conversation is the work. It’s the glue that connects the making to how you get to the solution. Like any good conversation there needs to be a clear topic, some kind of outcome sought and equality of the participants. Good rapport and spirits help a hell of a lot too. And as with any conversation, the ability to shut-up and listen is very useful.
• Fast and deep: For generating ideas and insights there is no faster or deeper way than through collaborative conversation. To the point that, aside from all the obvious collaborative stuff like workshops, I am absolutely convinced two people sitting together writing up a workshop or research outcome is faster and creates better synthesis than one person doing it for the other to QA. ABSOLUTELY CONVINCED!
• Not personal: It’s about getting to a good place, not about feeling good: if you don’t have enough collegial rapport to say something is bullshit or wipe a whole whiteboard of thinking, then call out some ground rules first. If you do it right, with the right people you all end up feeling good at the end. Strike that, you end up feeling great and energised and spent!
• Not about quick consensus: Not being in total agreement is vital (except about the outcome). Like-mindedness is ideal but don’t trust too much agreement and consensus if it’s not tested. Expect and seek creative abrasion – this is where collaboration and emergence converge.
• Not for everyone: Some people just don’t know how to collaborate. If you can, avoid them. If you can’t, try and set some ground rules if you’re leading. If you’re not leading, let them get their inputs and directives out and work bloody hard to win them over progressively by balancing greater good compromise to their personal agenda. Poor collaborators (and here’s my amateur psychology input) fear a lack of control, so they exercise what they think is missing.

I love collaborating with good people. If you’re lucky enough to work regularly with good collaborators recognise it and cherish it because it can be rare. It’s the sweet spot of design to me. But its not the end spot, and I’m going to do the most egotistical thing (other than having a blog dedicated to my own thinking) and quote myself to end this post.

After the Bad* collaborative session, we were pretty fired up/exhausted from where we got to. We probably could have gone for a few more hours. But it wasn’t just about where we got to because we’ve got clients we’re collaborating with too. I said:

“We’ve got lightening in a bottle here, but we don’t need to start a fire yet”

There’s a point in collaborating where you have to pause. Where you leave it, sometimes in a unfinished-nearly-finished form. But you have to, so it can percolate, so emergence can emerge, so collaboration can continue.

Be a good collaborator. It’ll make the world a better place.

Postscript
-disciplinary Definitions (my take)

• Multi– varied but complementary expertise, skills and knowledge. Shared interaction for outcome
• Inter– specialist expertise from related fields experience. Collaborative interaction for outcome
• Trans– individual knowledge and expertise is valued and shared as boundaries are blurred for the outcome

Emergence: revelations, percolations, bunnies & unicorns

There are three notions my design mind oft returns to:

1. ‘Time’ in the service design context – time taken, time spent, time saved (both from the design process and within the delivery of a service)
2. Design evaluation – what is it, how do you do it
3. What’s different about design in business that makes it of value (as design, not as a business method) – I guess this one is really “why is my vocation design-in-business, and not just ‘design’ or just ‘business’”

I appreciate these three things/notions/concepts/imps are inarticulate but I choose not to question or delve dedicatedly, until such time as the gods conspire to prod me by laying a morsel connected to one of the notions. One such morsel was laid before me on Friday, 22 July 2011. And the prod-ee was number three.

Sabine Junginger visited where I work. She’s a lecturer in Product Design and Design Management at Lancaster University. She’d worked with our principal, John Body at Carnegie Mellon a few years back on the re-design of the US Postal Service Domestic Mail Manual, along with Angela Meyers, who was also at this sharing session. But, enough of the introductions, what pricked my interest happened when Sabine mentioned ‘emergence.’

The context in which this came up was when she was talking about the principles she applies to her design research work. Nothing different from what most designers either explicitly or implicitly follow so I wont repeat them, but if you want to look further they’re informed by John Dewey and Richard McKern writings (can’t find any apparently appropriate reference for Mr McKern).

The principles, broadly speaking, cover (my descriptors):

• method (we do this)
• assumption (because we assume this)
• so what (in order to achieve this)

One of her principles in the ‘so what’ category was:

“allow focus on emergence to new possibilities”

Emergence(?!) What’s this – just a way of saying ‘emerging’? I’m intrigued. From the minor discussion that followed, and may I stress at this point that this was not a key topic of conversation, 60 seconds max but it did earn an asterisk in a circle on my notes, this is my interpretation and extrapolation, filtered through nerdy excitement and minor research.

‘Emergence’ is the process of coming into being or prominence. For design, emergence is the ‘connection of possibilities’ from ‘what didn’t exist previously’. Reads as poor English, reads better as a formula. It means emergence is the point where patterns and meaning come out of the multiple interactions of information, and from this new possibilities can suddenly appear. It’s like when you have a mass of information and you’re making sense of it, different voices in the room (or your head), different life experiences applying their thinking, and something new starts to emerge – a better way of understanding the information, a new angle, a better idea. That’s emergence. It’s not an ‘aha’ moment. It’s cooler, it’s the ‘hmm, hey…” moment. It’s the point of possibility.

Sounds like a bunch of esoteric arse? Well, no. I don’t think it is. To me it’s calling out that intangible value of design and the thing I love about it. This notion of emergence captures how the design process (super-broadly: research – analyse – synthesise – define) isn’t the steps alone. Design activity/thinking/whatever tangible-ises the bits in between. If, as we collaborate, iterate, discover, explore, we converse (and I use ‘converse’ in it’s broadest sense as a device for engaging at a human level), design makes value of the conversations, which lead to some form of capture. It encourages and facilitates those conversations. It brings the right people together to have those conversations – creating the circumstance for emergence. And then it has the means to visualize, capture and represent concepts. In this way it differs from analytical processes because the conversation is a crucial part of the work (as opposed to simply the means to an end). Design needs the divergence and synthesis, where analysis may seek to converge and refine as soon as possible because their parameters can be clearer (remembering design is concerned with experience and fuzzy human elements like that).

I’ve always been interested in ‘the process’ of design – I can even track it back to previous posts: Memory lane ramblings (ep #1) and the postscript musings (ep #4) and how designers think and what I call percolation. In a funny way, this post is the result of emergence for me – when my brain went “hmmm, hey…!” during Sabine’s talk. It’s not the end point, or the answer, it’s the revelation of deeper understanding.

So what does all this rambling mean? Well, in terms of the value of design in business, and as a change approach:

• Design captures the bits in between the traditional notion of work and does something with those bits (makes visible, facilitates conversation, explores, etc)
• As for the notion of emergence, it calls out that there is a point connection to what didn’t exist before occurs. The process of design seeks this out and makes value of it. As designers, maybe consciousness of this could mean greater possibilities emerge.

Well, that’s my take anyway. If I’m wrong (and do set me right if I have it all wrong) then I’m sure the Germans or Japanese have a word for what I’m on about. I still need to percolate on it, but I feel like a designer who’s approaching a breakthrough! And now, because there are an awful lot of words up there, here’s some pretty.

Emergence is not the unicorn framed by the rainbow.
It’s the thought running through the bunny’s mind before she
acknowledges that it is indeed a unicorn she sees before her.

Love movies, Like info-graphic-tainment

Presented without comment. Except ‘cool’

 

Source: Flowing Data

Maps, shmaps, pathways, shmathways, etc, shmetc

I write this post with a conflicted heart. The post is ostensibly about language. And making sense – which simultaneously is precisely what this blog is for me; a record of my thinking, and thoughts in progress. But, I’ve just read Nick Marsh’s post on service design is dead, and while I don’t agree necessarily I do see his point. And do kinda sorta agree with the sentiment.

Sometimes I think being a designer is like being an artist in the early part of the 20^th century when they became conscious of their isms – dada-, cub-, futur-, favue, orph- express-, et al. And I find myself *heavy sigh* a little bored of considering my point of view of “[insert term] design”. This may well be my last technique-based post for some time as I think I’d just like to do some doing and post about it, or post about some info-pretty.

But before then – this little bugbear has bugged me unbearably for sometime and started with the question “Is it a pathway or a journey map?” So in order to get some semblance of ‘just right’ in my mind I present the following musing to concluding.

Let the musing begin….

To wit: maps / pathways / user pathways / journeys / journey maps / experience map / service blueprints* / service models / service maps

So, all the pretty names, but what are these things essentially?

Tangible and visual means of showing:

1)    How the service is experienced (outside-in)

2)    How the service works (inside-out)

Why do you do these things as a designer?

To help business understand how the service – intangible in nature – works in a tangible way and how ultimately change can happen that supports customer/consumer/citizen experience and doesn’t make the customer/consumer/citizen hate the business for making their lives more difficult leading to distrust, ultimately making future change difficult. Simplistic but I refer you to para two and this post.

Service Design diagrams are the same as a LOVEM for an architect, and a BPMN for a business analyst. Relevant, useful and tools of our trade. Disclaimer: I know Architects and BAs do many more types of representational information.

Are Maps/Models/Pathways all different?

Except for the separation of outside-in to inside-out, I think no.

I was going to capture some definitions – but there are plenty out there and I do like Service Design Tools, or the definitions in this site (I did work pretty hard over four years to determine and ratify them).

To be literal, this is a map:                                    This is a journey or pathway through:

The map has all the details of the experience – it’s signposted, it features the surrounds. The pathway or journey is the route through the map. The map shows the system in action in which all customers/users act, the pathway shows the customer with a particular goal’s route through the system.

I am therefore saying that a journey map shows the system in action for a particular experience of a customer/user. A map on its own shows only the system in action.

Furthermore, I think I’m saying this:

• Want to show the service system and how users interact with it? It’s a map (experience, journey, whatever) and a pathway is an inherent component (otherwise it’s just a system diagrammatic) – in fact, the journey/pathway gives context to the map
• Want to show how the service works from an inside-out perspective? Service blueprint, baby. And don’t mess it up with experiential information.

And now for some definitive-ish concluding:

1. Maps are a suitably broad description for the visual means of illustrating a service system. As a map they should be appropriately signposted and show the relationships between time, space and objects. Ref: I Heart Frameworks for where maps come from.
2. Pathways/Journeys are routes through the service system. As a navigational course intended by a human to achieve a goal the ‘journey’ needs to show the think | do | use elements of experience: motivators, expectations, perceptions, beliefs, and particular tools, interactions, etc of the particular journey-maker (i.e. different users have different journeys)
3. Maps and pathways/journeys should always go together because they provide the ‘so what’ context to the ‘this is what actually happens’ revelation.
4. A separate tool – a blueprint is my preference – needs to illustrate how the non-experiential elements of a service work from the business perspective.

So, “Is it a pathway or a journey map?” I’ll go with ‘Journey Map’, and I’m comfortable in saying it can look like this. Does that mean I’ll rename the example post ‘Customer Journey Maps’? No, but I’ll add a link to this post.

Thanks for reading. Comments welcome.

Related Posts:

• Customer Experience Mapping &
• & Service Blueprinting
• I Heart Frameworks

*I have discovered in Australia (or maybe just Canberra (or maybe just the public sector in Canberra)) Service Blueprint means a full spec of user experience and user requirements. However, to me a service blueprint is the single schematic a la the Shostack originated version and this post.

Service Design & UX Design; Po-tay-to/Po-tar-to or as umami is to salty*

I have recently found myself working in the same physical space with some user experience practitioners.  Good people, nice people. As a service designer I have been listening to them talk, hearing familiar descriptions of activities and outcomes sought. Familiar but not the same. ‘Contextual enquiry’ and ‘affinity diagramming’ are expounded in such a way that I wonder “what is this magic that I’m missing?”. I sidle off and look up the terms and concepts I hear and instead of magic I read about things I would call ethnographically-based research and plain ‘ole grouping of things. But when I hear impassioned conversations about the virtues of certain approaches and structures for getting to explicit outcomes, with  concrete ways of seeing users, I think – “Is this what I do and I just haven’t learned the right terms? It doesn’t feel like it, and yet, does it…??!”

And then I saw this tweet via @huddledesign

great presentation by @hereatengine difference between #ux & #servicedesign http://t.co/OrAyosP

And all was right with my world again.

Oliver King, from Engine Design presents his view on the differences and similarities of the two disciplines. I highly recommend viewing the presentation: Service Design and User Experience: Same or Different (it’s about 34 mins – Oliver speaking and slides flashing). Or have a glance below where I have drawn out what were for me the highlights. I think it is the best comparison I’ve seen that I totally agree with wholeheartedly. Phew.

Please consider what follows ‘FROM HERE’ ‘TO HERE’ as Oliver’s words and not my own – [unless it's in square brackets]. After ‘TO HERE’ I have captured some of my thinking.

‘FROM HERE’

Service Design and User Experience: Same or Different

Opening Summary:

“One designs the interface and the other the service and organization behind it”

Service design is:

• Not new
• Not ours
• Just a useful term
• Misunderstood by designers
• Really appropriate

The world is changing:

• From products to services
• From industrial to digital
• Being looked after to looking after ourselves
• Abundance to austerity
• Sharp to fuzzy edges

The differences expressed and his opinion:

• It’s subjective
• Definitions help to a point
• Broad terms are necessary
• The focus of the viewpoint is about project work, not practices
• This is about designer’s Design

What’s common for us both:

The differences:

	Service Design	UX
Research	Qualitative – research is constant	Qualitative and quantitative – more data sets, analytics
Medium	More physical – more focused from a service perspective on the people part, how people behave, what they do and what they say, interested in physical environments and how they work[Also, the outputs we generate are more tangible and become tools – such as experience maps, service blueprints]	More virtual – more digital in nature
Practitioner mode	Facilitator – recognising that services are made by [complex] organisations	Technician – understands how to make something happen, and are interested in the building and doing
Domain	New business models and social innovation; how does the service come together? How does it create value? Where does it go?	New technology
Scope	Broad – multi touchpoints, multichannel, threading things together – they know a little bit about everything, understand how to orchestrate and bring those things together to deliver an experience, and out of that come up with specifications to respond to HR, developers, interaction designers, etc	Deep – understands how to get through and delver a thing someone can interact with and use

Case studies to illustrate the points:

Oliver takes us through a couple of case studies.

First case study: Mercedes Benz who wanted to look at redesigning there after sales services. The approach and outcome from a service design perspective means:

• At a level SD it is like design management
• SD addresses much more of a strategic question – a broad question
• It starts without direction
• It helps to form how the service can add value at a business model-level
• Looks at the entire service, not just touchpoints
• Service Design has to have no favour as to what can be done. It must be discipline neutral and exercise a level of impartiality.

Second case study – BBC2: Helping to understand what happens on air with what happens interactively.

Getting to a solution from an SD point of view there’s a top-down-bottom-up approach. It’s about user needs, understanding and principles to redesign experience, but the top-down enabled a reformatting of the proposition and how the needs, understanding and capacity should meet. So, where these met was not a new interactive service it was the development of a set of tools that were largely internal. The deliverable was a toolkit to help internal people understand the vision, principles for the experience, personas, etc which included a collaborative workshop to quickly bring together the players in the service – for it to work (that is, getting live radio content online for interactive purposes)

From a service designers perspective it was about developing tool, not a final solution – create the toolkit, build capacity and expertise into a capability internally. The outcome was to address a new way of working and shift focus on building a new capability.

So, what’s the difference?

The difference between SD and UX is not so much about what it is now, but what it [service design] is going to be. And the move to the strategic approach. “Where one will focus much more on the interface of the experience, and making that work beautifully… and the other will engage with “now how do we get the organization to think differently, work differently, commit to and want to build great services and [be] great service organizations”

To have a great service that’s got to come out of a great service organization. Service design has to engage with the challenge of making the organization better at developing services

The challenge is that organisations are silos, but the customer journey is horizontal. So how do you connect it up? You might do a customer journey, you might design the user experience but you need to be able to engage with the IT guy who’s got a finite budget to spend and explicit solution deliverable.  The big challenge is how to go from a silo organisation to one that can deal with horizontal journeys and all that that entails.

Great service organisations – context

We understand, for service design, all that you need to engage with to make the above work:

Service experience – the importance of delivering great experience, various things it takes to do that, and that need to be considered

• Touchpoints
• Service journey service aesthetic
• Service variability
• Service envy
• Service recovery
• Service advocacy

Service architecture – the service needs to be well-built, joined up and seamless in how it fits together and works

• Kit of parts
• Connectivity
• Modularity
• Service integration
• Design rules

Service proposition – the service needs to be mutually meaningful and valuable to the organisation providing it and to the customers themselves

• The business model
• Revenue
• Partnerships
• Incentives and disincentives
• Offers
• Customer segmentation

Service organization – the service itself needs to be delivered

• Service vision
• Service strategy
• Service culture
• Service operations
• Service training tools and materials
• Service design and innovation process

How Service Design deals with Service Organisations

The ‘hoops’ model:

The model recognises that the journey of building a service organization starts at the level of experience. You go through one cycle of turning experiences into insights, next cycle goes from insights into service design, next cycle is service design into new capacity and capability that need to be built into the organization to support service, next cycle is the system level and new policies, new ways of working.

This means service design [as a change methodology] is a project when:

• You’re asked a bigger question – a more strategic question
• The solution is going to require some organisational change
• You end up having to train people, build skills
• You need to be utterly unbiased towards the solution
• You pitch against management consultancies

Summary

• UX and SD not mutually exclusive – but there are differences (right or left)
• It’s about projects not practices
• Different but symbiotic outcomes – both need experience, you also need organization to make it happen
• Organizations need both
• We are not alone…

‘TO HERE’

I feel, for me, I’ve captured the meaningful points. I guess what resonated most was how SD is interested in change at the organisational level – not just for touchpoints, interactions and experience (or the ‘how’-level) – but at the ‘why’ level. So while the customer and frontline person may well provide rich experiential information, you can’t discount the opinion and experience of the executive-level person because of their ‘heightened position’ – they may not interact with the same touchpoints, but they influence and inform decisions that effect those touchpoints. And all of these in-turn are informed and influenced by the environment and community we live in – even more so for the public sector.

It also reminds me of Richard Buchanan’s Fourth Order of Design:

1. Symbolic and visual communication (graphic design)
2. Material objects (industrial design)
3. Activities and organised services (strategic design)
4. Complex systems or environments for living, working, playing, and learning (systems/design thinking – what I think is also ‘service design’ in the future sense that Oliver describes).

I know what’s bubbling up for me is “are the above notions and positioning of service design turning it into just another business change methodology? Is it losing something of the creativity? Is the notion of design thinking dead?” But that’s for later mulling. Hell, I’ll probably even mull all of the above, percolate a little and add to this section. I just know that the touch of inferiority I was feeling in the face of such UX resolution has gone.

• For more on the Hoops Model you might also check out form Engine this article: Make Yourself Useful
• (Wee disclaimer: I have a soft spot for Engine because 1) I love their stuff/thinking/ethos 2) When I holidayed in the UK a few years ago Joe Heaphy agreed to meet a nobody from lil old NZ on the strength of no more than a grovelling email, and maybe the fact that I worked in a big govt department who said they did service design. And he’s kept in touch.)

* Umami = Richness and Salty = taste – together, mmmmmm, yummy….

What is Visual.ly?

I’m intrigued. My assumption from the name is some kind of bit.ly for the visual realm.

Interesting(?) A little. Maybe….*heavy sigh* – y’know I used to really love information design and feel like part of a visual community trying to make a difference but now if everyone’s doing it and recognising it as ‘information design”…well, it’s feeling like it could be losing it’s “hey, cool!” factor and turning into graphically designed marketing info more akin to “yeah, sure.”

I’m especially unsettled by the fact that the end of the YouTube viewing it tells me Rebecca Black’s Friday [official video!] is up next – what kind of sick filter does that viewer profile generate?

 

How you doin’

It’s been around a while but one Newspaper Magazines I read when I arrived in Canberra had an article called ‘The Rise and Rise of the Infographic” (The Weekend Australian Magazine April 9-10 2011). I chose to see it as a good sign of my decision to move. In the article – which was a filler story to be fair – they mentioned this site.

We Feel Fine is an exploration of human feelings on a global scale. It’s also a delicious piece of interactive information design!

In it’s own words the site “has been harvesting human feelings from a large number of weblogs. Every few minutes, the system searches the world’s newly posted blog entries for occurrences of the phrases “I feel” and “I am feeling”. When it finds such a phrase, it records the full sentence, up to the period, and identifies the “feeling” expressed in that sentence (e.g. sad, happy, depressed, etc.)” The makers call it “an artwork authored by everyone”

Click on the different displays and delight at the representations.

• Madness
• Murmurs
• Montage
• Mobs
• Metrics
• Mounds

You can see the random feelings captured. Or you can focus on one and drill into it.

Then, as with any good piece of information design – reflect on the content from your own context. And feel….

I heart frameworks

My most popular post is about customer experience maps – it gets about 50 hits a day (I’m blogging plankton in the scheme of things so 50 is a lot for me). I’m chuffed about that because maps and frameworks are just about my most favourite thing in design. They’re even a form of info design (which is my other favourite thing). And ever since I put up that post I’ve wanted to do this post about frameworks.

I love dealing with lots of information because I love coming up with frameworks to manage the volume. That magical moment when all the information fits like finally cracking the sky in a jigsaw. And then that wonderful feeling (provided you trust it) when you know you don’t have to return to the data because it’s been organised. For me this is the magic and wonder of synthesis.

NB: Don’t be frustrated if I use framework and model interchangeably in what follows – I’ve never determined a clear enough distinction and if someone calls their framework a model (like Doblin) I’ll call it a model.

What’s a framework

Frameworks are a means of structuring thinking and research findings into a format that is meaningful to the desired change; they offer deeper understanding and turn abstract information into meaningful categories and relationships. It’s best captured in a quote from Conifer Research where they called “[frameworks and models] scaffolding when we build Experience Maps”.

A well-known experience framework is the Doblin Group Compelling Experience Model. It helps envision the different facets of generic experience a customer goes through when engaging with a service. I’ve teamed it here with John Maeda’s definitions:

A framework for frameworks

Experience Maps and Service Blueprints are forms of frameworks so when I was working on developing the techniques I needed a way of describing how you organised existing and created information before you could map it. I developed this framework (the purpose of which is to contextualise):

When frameworks become a map

Frameworks tend to be set in concrete in terms of content (i.e. once they’re developed they shouldn’t change. NB: this isn’t the case for maps). There may/should be many different frameworks to capture facets of information. At the user experience level:

• Frameworks model abstract experience to categorise and relate the information. The frameworks created during service design activity describe all the elements involved – separate and connected. For example, when I was involved in a piece of work understanding how small business used information we developed frameworks on how customers used information versus how the business created it (business produced ‘guides’ ‘letters’ ‘forms’, customers used them as ‘reference’ ‘memory joggers’ ‘proof of status’) user typologies, sources of information, interaction frameworks, delivery mechanisms. This synthesised knowledge gave us the parameters for developing experience maps
• When we’re mapping, ‘user experience’ is what happens. The map itself takes a specific case and works it through, helping explain how all the elements – separate and connected – contribute to the customer experience.

Frameworks become a map when you want to plot a journey and the map helps you ‘see’ service as a whole; the map humanises meaning from the abstracted frameworks.
 
Framework Hall of Fame

I’d like to thank these frameworks for helping me sleep through the night when panic set in about how the hell I was going to articulate experience, helping me work more quickly, and most of all, for helping making meaning of mass.
 

Service Design Frameworks

• Experience Framework (DSR Group (via Leslie Tergas)

A way of breaking down user experience. I have never been able to come up with a better definition of experience in relation to service design than this framework.

• What users THINK (Cognitive Domain)
• motivations, folklore, perceptions, beliefs, expectations, mental processes
• What users DO (Behavioural Domain)
• activities, processes, routines, patterns, interactions, relationships
• What users USE (Material Domain)
• products, services, brands, environments, messages, systems

 
• Typologies
  Typologies describe different types of users at a high-level – they are a springboard for understanding and designing for the variables of real user experience. Typologies and personas are closely aligned; the typology provides user experience information at an overview level; Persona’s take that information and bring the typologies to life. Typology example

• Who the user is in relation to the business need and intent
• What they do
• Their expectations
• Points of Delight (Opportunities, things the service/experience should maintain)
• Points of Pain (Barriers, Challenges)

 
 

The following frameworks I relied on heavily in capability development

• Activity descriptions
• Overview (high level description of what happening during the activity)
• How it happens in practice (instructional level description)
• Who are the people involved
• What outputs are generated
• Where are you at the end of the activity

 
• Technique descriptions
• What it is
• When it’s useful
• What you do
• Who’s involved
• What you need

 
• Operating Model
• What we do (our purpose)
• How we’re organised (our functional structure)
• Who’s involved (staff, process partners, business areas)
• How we do what we do (management practice, information flow, capability infrastructure)
• What’s important (values and behaviours)

 

• Innovation (as change creation framework)

• Known knowns – optimizing the system/service
• Known unknowns – improving to evolving the system/service
• Unknown unknowns – inventing to transforming the system/service

 

And just to show designers aren’t anti Business Analysis, this helped me engage with my BA colleague on many an occasion.

• Business Analysis Problem Definition
  • The Problem of….
  • Affects….
  • The impact of which is…
  • A successful solution would be….

Where I’ve been

Not here. As you can see by the months old last post. Since January I’ve changed jobs and countries. All the activity and change  started in January – hence the tardy timing. Here’s a wee map of my experience.

I’m still working with the public sector just in Australia now and as a consultant, not a public servant. I was also without an internet connection for 6 weeks *shudder*. And to be honest – given this blog is about what inspires and resonates with me about design – I feel I can share that I’ve found that the move has left me design-mojo-less. It’s coming back. Hence the torrent of posts (well, 2).

Thanks to all of you who continued to visit and comment and link.

What is a service? – an exercise

When talking about a service surprisingly few people can easily rattle off a definition. In my experience, people generally have some concept in mind but don’t think about it very consciously. No surprise because it is intangible, open yet time-bound, and a mix of things, feelings and goals.

The definition I like (an amalgamation of many sources so none in particular is referenced) is the following:

A service is the seeking and receipt of a specific outcome of a customer across a range of interactions and touchpoints over time.

or

As I train designers in the field of service design I have come up* with an exercise to dig into what a service is at a personal level – so people who need to design services really get what it means from a thinking, doing, user-human perspective. (NB: the definition of ‘experience’ I subscribe to is what people think – do – use. This is a key reference in the following exercise)

The following exercise takes about 15 minutes. I run it before any training on service design 101, customer experience mapping, service blueprinting or when talking non-designers (generally managers – more on this in a future post). I’ve run it about 12 times now so I’m pretty confident that it works.

What you need:

• Whiteboard
• Group of people – no more than 8 if you can help it – especially if you want everyone to contribute

To begin:

• Ask: “What’s a service”

Write the question on a whiteboard and ask what do people think. There isn’t an expected answer – this question usually reveals that people don’t have a clear view of what a service is. You often get ‘product’ answers: ‘it’s a thing’, or an academic response” ‘it’s the exchange of money for desired goods’ or a business answer: ‘it’s a transaction’.

From the random verbatim comments you capture on the board, follow-up with: “What’s different about a service from the perspective of 1) a business? 2) a customer? ”

By now the participants realise that most of their answers are from the business perspective – not a feeling, thinking, human-customer perspective. You may get some customer representation but a strong business perspective is more common. And this is good – if everyone in the room is articulate about what a service is you can wrap up early!

The reason to ask what’s different about the perspectives is to get them thinking at a high level about the engagement of a service by a customer, and all that’s involved regarding the access and delivery of a service.

At this point you can give a definition (this is useful if talking to managers) or you can say: ”That’s great if you’re not certain because the point of the following exercise is to drill into what a service is from a customer perspective.”

Starting the exercise:
Get to a blank screen on your whiteboard and start by saying “what we’re going to do now is explore a service – I want you to think of this from your personal perspective, you as a private citizen – not you as a civil servant (which is where I work) or as a business person (who the civil servants facilitate the design with).” You’re likely to have to remind people of this throughout because they may slip into ‘functional’ language or try to turn it into a ‘business problem’ for them to solve.

Below is the output you’ll ultimately produce. The numbers correspond to the sequenced components of the exercise as follows:

1. Write up the service topic you’re exploring

It has to be one that you can extract a specific and simple service (not a product) – this sounds like a no-brainer but quite difficult to come up with the right kind of service for the exercise, one that bears some relation to your own business but isn’t your business, and truly has multiple interactions that aren’t just one business.  I have used two services and service topics that work well:

• parking a car – which starts with “Who owns a car” – you can explore local councils, police, parking buildings, garages, maintenance, regulatory agencies – it’s a very rich example. Or
• redeeming points in a loyalty programme – which starts with ‘loyalty programmes’ – which is the example we’ll be using.

As you write-up your service topic, in this example “loyalty programmes” ask the room “who belongs to a loyalty programme, like FlyBuys, Frequent Flyer miles, etc?” to get the conversation started.

Write-up and ask the following:

2. “Why?” […do you belong?] – capture what people say
3. “What’s involved?” […in belonging to loyalty programme?] – capture what people say
4. “What organisations?” [are involved in a loyalty programme?] – capture what people say

5. Identify the think, do, use, (i.e. definition of experience) interaction, touchpoint elements

• Think – you all have different drivers motivators for belonging
• Do – you all do different things to maintain and utilise the loyalty programme service
• Use – there are different touchpoints, activities, organisations you use to access loyalty rewards and manage points
• Touchpoints and interactions – there are different people, organisations – some obvious, some not so obvious that you or the loyalty programme is connected to to make the loyalty programme work

This is the first part of the exercise and hopefully, some nods and revelations ensue – “ah, yes it isn’t just a transaction”, “people do do things differently”.

6. Now you’re going to take the above and pick out an actual service related to the topic. In the example it’s:

“Redeeming points for a toaster” (this is deliberately crossed out and replaced with “Getting a toaster from flybuys” because what customer would really say “redeeming points”?!)

7. From here, you’re basically facilitating the conversation about what it’s really like, based on the experience in the room of getting a product from flybuys
What are the steps and activities, thoughts and considerations that actually take place?

NB: You should do a private practice run before you do this with a group – just to avoid people starting at ‘I go online and redeem the points’ so you can prompt them to start at the point of ‘I want a new toaster’.

Often someone will dominate and believe their experience is the common experience and expect the discussion to be wrapped up quickly. It is real delight when someone else pipes up with “You do that? I don’t do it that way” followed by a “me either!” It’s like they become humans talking about their different and valid experiences and expectations – which is exactly the point.

8. Underneath the experience and activities capture separately the touchpoints and interactions
People often do well in this because they get channels – but they don’t always see all the users, and you can help them draw this out

9. Because this example is used as the intro to customer experience map training, circling this section represents the experience that can be mapped because it represents how the service is experienced

10. Because this example is used as the intro to service blueprint training, circling this section represents the service that can be blueprinted becuase it represents how the service works

I have not run this exercise without success. The exercise itself is enjoyable to run and I have had extremely positive feedback from people who’ve gone through it. I think it works because people are able to engage at a personal level – by sharing, they become like the abstract customer they are designing for, they walk in a customers shoes because they are customers. And by hearing other “customer” experiences they realise their experience isn’t the only, or even the right one. With many customer and many experiences this is where the value of service design can be demonstrated.

I’d love to hear any feedback or suggestions you may have.

* Getting the exercise to this point wouldn’t have happened without directional input and finessing from Rachael Smith. Every designer needs a collaborator!