I love a good principle.
They’re fundamental in nature. Sometimes simple, often deep. They guide behaviour. They help make decisions in the complex world of multiple decisions required. They’re better when there are more than one – because nothing is ever black and white (if is it then they’re rules not principles).
Also, having read through many of them, I couldn’t help but have a go at my own set of Principles of Principles based seeing 73 collections and 587 principles.
The Desonance 6 Principles of Principles
- Same letter start, way to the heart.
- Single …word, then explain.
- S’Number them for better hits.
- Six minus one to 10 in number.
- Succinct verbosity, otherwise too much curiosity.
- So action occurs, use verbs.
1. Same letter start, way to the heart.
Connected, Courageous, Collaborative, Coherent, Co-sponsored.
Make it clear, Manage it all, Maintain what you can, Maximise the value.
I made up that last one but seems like to could be something! Anyhoo, I’ve been guilty of this in the past – using the same letter to start each Principle. I think sometimes, trying to get that matchy-matchyness (there is no linguistic term for lists starting with the same letter) may dilute the actual heart of the principles intent.
2. Single …..word, then explain.
I’m a fan of conciseness (even if I don’t often practice it), but I think a list of snappy descriptions is better then a single enigmatic, open-to-interpretation word. And it goes with Principle 6.
3. S’Number them for better hits.
Apparently, you get better clicks if you number your lists and posts. Just think of all the ‘4 Ways Elevators Will Get Totally Insane in 2016’, ‘38 Foods That Shouldn’t Exist’ and ‘10 Signs You’re a Sucker for Clickbait’ you click on. I know I do! I know they’ll be skimable, I know they should be fast to get through, and I know it will be a list.
4. Six minus one to 10. (See what I mean about Principle 1)
Between five and ten seems to be the most popular number for a list. I subscribe to the ‘The Magical Number Seven, Plus or Minus Two’ (Miller’s Law) so it works for me.
5. Succinct verbosity, otherwise too much curiosity.
‘No gorilla arm‘ is rare as a type of principle, but generally a principle is immediately understandable so you don’t get confused. And if it is wordy or verbose, it’s probably aimed at a specialist audience.
6. So action occurs, use verbs.
Design, Assume, Tailor, Strive, Reduce, Offer – doing words! Because principles are about doing something – making a decision, changing a mind, setting a course.
Disclaimer: If, in reading this list you say “ahhhh, they aren’t actually principles!” – Sorry, I don’t really care. Sometimes it’s nice to just put fingers to keyboard, compose something and hit publish. Without making sure you’ve captured a system of broadly applicable truths. Ironic, don’t you think?
Again it’s a topic in government and I can’t share details. But this time, from a design process perspective I’ve played the Second Chair role – take care of everything (finding the place, confirming anything with the participant beforehand, logistics of getting there, interview packs, back up interview packs, recording, keeping time, follow-up) so that First Chair can wholly engage in conversation with the person.
A wee note about research roles and responsibilities here: I’m a strong advocate of process. Probably no more so than when in the field. These have been deep dive one-on-one interviews for an hour or more in the homes/workplaces of the participants and on a particularly sensitive topic. You have so much going on that process frees the part of the brain that needs to be organised, rigorous, ethical and practical. That leaves the rest of your brain to be empathetic, engaging, probing, curious and on-topic (or off- as is beneficial to the project outcome).
But what my role has meant is that I’ve had the opportunity to reflect on the interview process itself. Enough that I wanted to capture these observations in this off the cuff and probably over-verbose post.
So, to the observatoring!
- It is so satisfying professionally to see someone physically change as they relax in front of you from crossed arms and suspicious expression to laughter and open gestures and genuine curiosity to explore their own thoughts. And when they start swearing? Gold.
- Witnessing an interview that is transformed into a true conversation through rapport and authentic empathy between interviewer and participant. That is, the interviewer can articulate their understanding of a range of experiences but also able to build on the rapport with a sharing of their own feelings.
- From a personal perspective, being presented with different ways of thinking is a total perk in some cases – sometimes people share extremely inspiring or thought provoking perspectives and experiences. It can change the way you look at your own life or attitudes. These interviews are a delight.
- Also from a personal perspective, it is, fortunately, a rare experience, that you can come across someone who not only has completely opposing thoughts, attitudes and demeanour but who can be boorish, egotistical and really not someone you want to talk to at all. But you do. And you always find out something of value. These interviews can be a test, requiring circumnavigation of topics and questions, and strategising of responses to reach, if not rapport and openess, then at least genuine perspectives and input.
From talky-talk to writey-write (some rubby-rub out) and then re-writey-write
As we’ve gotten into the analysis and synthesis phases, I, as an introvert who needs to layer up my analysis and understanding over time (however short), have forced myself to type up my notes the evening of the interview. Yes, I know, I, who extolled the virtue of process only six paragraphs ago doesn’t follow all good process all the time. Whatever. Been doing it more than 10 years – know the rules to break them baby. Anyhoo, the love/not-love of the research phase is followed by the love/not-love of notes and analysis. We’re in that space now.
My notes are structured around themes, quotes (which I get verbatim wording from by checking the recordings – really liking as 2nd chair being able to note the times in the recording when someone shares gold), insights from the users, insights from the car debriefs.
It’s all a set-up and preparation for what I think of as the 20% of actual fun and free design time you get out of any design project. The whiteboard, the conversations in the office, the referencing of the notes, and exploring the interpretation, the different perspectives the design team brings. This is the great stuff of design.
As we move to synthesising and refining the 20% gives way to the necessary 80%. Oh, sure, we’ll get back some 20% glimpses during prototyping and viusalising, but the fact is, after analysis/ synthesis /exploring we’re through the looking glass here, people. And on to the actual design part!
Lately at work we’ve been busy. Three jobs finishing around the same time, development work for projects starting up at the same time. That’s meant two things:
- I love designing, but you gotta capture the design in a concrete way which means a lotta synthsising of key elements, features, contextual linkages, pattern ah-ha’s which all needs to be succintified, captured, edited, refined, described, clarified.
- I love explaining the complex in a visual, but getting to the final graphically designed visual takes time, and mousing, lining up, and saving often, and resizing, and sourcing imagery and inspiration and making icons. And then taking a look and realising it’s unreadable, and adding a few lines and boxes. And then transferring it to an already MB-full document. So some more resizing, and wondering what the hell to do. And then googling and working it out.
So, I love and hate this time. You’ve done all the fun talky whiteboardy stuff. Now it’s time to get your define on.
We work mostly with Public Sector clients. They get a lot emphasis on *A LOT* of words to read; tables and matrices, paragraphs, bullet points – pages and pages of it. Prose and composition and narrative take time to craft, to take in, to agree on. So for a change I’ve been leaning quite heavily on sketching to draw out process changes.
Instead of getting the client to read:
The activity begins when the user makes either a formal or informal approach to the group. This may come from a variety of sources including:
- Existing Plans
- Previous Plans
- Executive Forums
- Opportunities that may result from discussion or forums
- Informal discussions where “bright ideas’ may evolve naturally.
I’ve been sketching this and talking through the refined detail:
We use this sketchy approach all the time during the exploring and designing phase. But using it for final clarifying to the defining stage is new for me. Bourne out of necessity – too much on, too much to take in (client-side, my side), wanting to allow the client to be able to contextualise the multiple series of decisions we’ve been making together all along but now we’re in the final act.
The result has been great. Couple of times even greeted with a “great!” and a generous lean in and casting aside of reports. (It’s very nice as a designer when the new way of looking at things to a client is actually enjoyable and a relief to them from what they’re used to).
FROM VISUAL (SKETCH) TO VISUAL (DIAGRAM)
This sketching has also meant turning these conceptual views into the experience maps, and blueprints, and diagrammatic representations and frameworks has been much easier for me.
Just like the conversation is often designing. It’s true also that when you sketch you’re designing. That means when I’m using Illustrator I’m designing too. As painful as it can be to start on a blank Illustrator page.
Because as you’re drawing the person, and thinking how to colour-code them, and relate them on a screen to an icon that represents a touchpoint or a process or a feeling, you’re thinking as if doing – outside-in and inside-out.
I’ll admit I’m a bit of a perfectionist on certain things, and digitising a diagram takes time. Plain and simple. That’s not to say I haven’t always, and still don’t feel guilty for taking time to do diagrams or info design. Even if it is my job. I’d say a typical one-page diagram like a customer experience map takes probably 6 – 10 hours. All the refinements are in addition to that.
I am surprised how often I finish a diagram and just hate it. I look at it and I think: “that doesn’t work at all!” “It’s going to be illegible to anyone but me…But I’m so sick of it. And the iterations” (yes, people, iterating can be a pain in the arse!). And then a client sees it and says “I like how you’ve represented me there” (as happened recently) or a colleague explains it back to you seeing even more then you realised. That’s cool.
SO WHERE TO ACTUALLY BEGIN THE END
My final realisation from this burst of multiple visualising activity has been I am now comfortable with where I need to make a start on a blank page.
Start at detail. Start by writing a bullet point list of what the thing should fulfil. Start by writing a story of someone looking at the diagram. Start by crafting the icons on the diagram that represent emotion, or touchpoints, or a spreadsheet. Start by picking a colour scheme in Kuler. Just start, and slowly but surely, it always comes together. And sometimes, if you’re a lucky designer like I am, you get some absolute and genuine pleasure from it. It reminds you why you love being a designer.
I present to you the regular verbal punctuation of a typical design conversation – after each passage analysis, synthesis, tension, delight, creativity, and often, solutions ensue.
Please, to enjoy:
Last afternoon, before self-imposed deadline
Finally, next day, when it’s committed to paper
*Based on a true events in the DMA office.
Not a year in review, because it’s nearly February…so it’s more an annual post! (Still with the long titles though)
Jiminy wowsers! It’s been a long time since I last published a post here, huh?!. That’s not to say I haven’t been doing, thinking and writing design. In fact, I’d say just about every week I come to desonance to reference something I’ve written or thought through here. So it’s serving exactly the purpose I’d hoped. : )
This isn’t quite a “year in review” post – I’m just in the mood for some writin’ and mullin’.
I have written a number of pieces on design at my company blog, DMA with my biz partner Justin Barrie. The ones I reckon have relevance on desonance are:
- Innovation: Two Perspectives – With Video, With Slides only (July 2013)
- Breaking down users of services: User Typologies (November 2012)
- Visualisation progression: Loving the sketch (August 2012)
- Creative Boost 2: Playing in a different design discipline to learn more about my own. (April 2013)
- Creative Boost 1: Visualising and pattern making (August 2012)
Also, pretty freakin’ cooly and thanks to this blog I’ve been published in a number of publications
- Airport Operations (Third Edition) – Norman Ashford, HP Martin Stanton, Clifton Moore, Pierre Coutu, John Beasley. My Customer Experience Map was used to illustrate the value of mapping customer experience.
- Designing for Behaviour Change: Applying Psychology and Behavioral Economics – Stephen Wendel
- Interactieve marketing, 2e editie (incl. XTRA) – Marenna van Reijsen, Theo Zweers en Huub Janssen
Let that be a lesson to the kids out there to just put it out there.
Two things that have preoccupied me most about design for a wee while now:
- Professionally, the notion of service design to focus internal service deliverers (such as IT, management) and arm them for change, from the inside-out. At DMA, we explore this in many a-conversation, and have been doing it with a couple of clients – to great effect! It’s exciting, and I believe it’s a really cool, decidedly un-sexy way to use design to effect real change. Engine are the only others in the service design space I see consciously talking about this. To me, it’s the notion of building a platform for design to be sustainable (which was part of the discussion I had with Joe Heaphy so many many yeas ago). And there’s something that resonates with business. And it’s super fun if you like dealing with complexity.
- Personally, maybe this one hasn’t excited me, but it has given me pause to accept. My creative thinking process is one of introversion. Introversion and reference (ie. I look up stuff – everytime). I often feel slow – in both the conceptualising and in the creative opportunity when teamed with an extroverted, quick and smart partner. This is not an enjoyable state. But it just means I need to find that solitary space early or later in the day to work through things. I get there. Or sometimes I have to say “I just need some time to think this through”… or words that effect. One night I was so frustrated with my self-defined “slowness” I drew it out. That was when I realised, it’s ok. It’s just different. I really like the place me and my brain can get to. And return to.
- Sometimes you talk too much and you just have to shut-up.
- Sometimes you don’t really know what you’re talking about so you just have to shut up.
- Sometimes you just have nothing to add; you just have to shut up.
- Sometimes, if you’re having a one-sided dialogue – that’s actually a monologue, because people can’t engage with you – just shut up.
And so I find myself, in my blogging, and maybe even in my engagement with some of the vocal vociferous voices of the design industry, at number 3.
I have now been in the design game long enough that I see repeats of the same arguments, same hyperbole, same “design thinking” evangelisation, same let’s fix design!/let’s redefine “design” excitement! that I saw, and that excited me, some 10 years ago.
But I’m a bit over it really.
Not over design.
Not over service design.
Not over the difference design can make.
Not over being a practitioner.
And not over slaving over a blog post for hours to craft the thoughts and get the point just right in my head and on “the page” – which is the point of this post really and what direction for these efforts in the future.
Because I am over “THE PROCESS!” I know it enough to forget about it, adapt it as necessary, seek to reinvent it appropriately – I’ve earned that. And I know it enough to shudder a little each time I hear about a training course over X-days in “innovation practice” “design thinking” “experience mapping” “prototyping made easy” “become a designer”. And this is from someone who developed and ran a two-day course called Service Design 101 for a large government department! But with practicing designers, and seven years practice – not theory – experience, and a deep knowledge of the organisation itself.
And I’ve spent enough time on getting clarity on meaning that means I am over the definitions and redefinitions for the sake of supposedly encouraging dialogue, debate or for plain ole “I’m right!” purposes. Meaning matters and labels help, but definitions that fix a precise description and have to fit within 140 characters? Over it.
See, here’s what I love about design (as in service design, design in a business context):
- It is complex.
- It is hard – it really is. I’ve said it here before and I still agree with myself.
- It is human.
- The act of design can change the way people think about themselves, their roles, the people they deal with, the difference they can make, the outcomes they can achieve.
Here’s what I love about the world of design I am lucky enough (and also choose to) operate in:
- It is not sexy.
- It seeks to effect change in the places that don’t always start with the customer – often in deeply mundane and political places.
- It’s about helping the right people make the right decisions at the right time (for them) to achieve their individual goal – whether it’s a policy outcome, a service outcome, a process outcome, a payment or entitlement outcome, an information outcome, a technology outcome, a certainty outcome. But what matters is the outcome, not the process.
After three-and-a-half years blogging about design resonance, my desire to move on from the love of a perfecting and describing design process (and I have loved it) has manifested as a slight obsession, after a number of projects at work, and a number of experiences, with the role of those who deliver service and their role in the service experience – at a systemic and sustainable way (think Zappos, but in a non-sexy socially-driven environment like the public, community or voluntary sector). Customer stuff – easy (as in complex, hard, always interesting etc), other people in the service system – gimme som-a that to digest, consider, hypothesise, analyse, synthesise, share.
Besides a history of working deep in organisations, there are three recent triggers responsible for this evolved focus shift:
- Recognising when the client has so much faith in the touchpoint itself, they just don’t fully understand internal users may be highly unlikely to maintain it (given a choice) – if you build it, the customer might come, but the people behind the scenes might not maintain the outfield, if you know what I mean.
- Dealing with a major telco, receiving unexpectedly responsive service from the generation that’s not supposed to give a shit. On complementing them for the great service and hearing back “well, service is what the job is about, isn’t it.” Wondering how you recognise it, attract it, retain it, harness it, grow it, sustain it?
- An email interaction as a customer where I thought I was interacting with a human – only it was a human cutting-and-pasting scripts in order to deal with me efficiently. And effectively lose me as a customer. How does an organisation balance efficiency and effectiveness with being responsive and authentic?
It is that unsexy outcome-focused, change the system deeply from within – that’s what really resonates with me lately. Still with a repeatable scalable approach, still customer-centric – but maybe even more human-centric – knowing that many of those humans are bound by policy, process, tools and drivers that are outside of their control. That’s what has me seeking new insights, readings, and ways of understanding systems.
That’s probably a little harder to blog about.
That’s probably what I will blog about more now.
But I’ll shut up unless I have something to say.
The title of this post is dedicated to my business partner, Justin Barrie, who frequently challenges clients to “just shut up” in the most engaging, charming and unarguable way. After all, they invite us in. He also let’s me rant about stuff like this, and doesn’t tell me to shut up. Usually joins in. Heartily.
I’d also like to add the people guilty of 1, 2, and 4 will never read this post because they are the living embodiment of people who should indeed, just shut up.
Recently at work we did some service prototyping with a public sector client. We wrote about it on our blog. It’s a topic I’ve often wanted to capture here because, in my experience, prototyping and service prototyping in particular can be a challenge for people to get their head around. It took me a while and then it clicked (I suppose being schooled by IDEO, and having the opportunity to mull as my full-time job did help ; )
What Prototyping is for
Prototyping is about visually and tangibly putting together a working model of a concept in order to quickly test out various aspects of a design, illustrate ideas or features, and gather early feedback. Prototyping is the language of design and its basic tenet is ‘make to learn’. It helps you move beyond talking and thinking towards action. The prototypes are not the solution itself; they represent ideas, before artefacts are created, code is written, components are developed, and solutions are implemented.
Creating a representation of a concept through a prototype, or a service prototype of the whole system, means you build something in a fast, cheap way and can test it with users – inviting real input – from your own reflection, to colleagues, to collaborative partners, to users themselves. Better yet, prototyping gives the means of creation to the users themselves.
It’s a little bit semantic, but from my perspective there are two types of prototyping:
Service Prototyping in particular
The potential of service prototyping runs the gamut from conceptually illustrating service experience through sketching or storyboards to isolating part of a system and trying changes in real time. Most people would be familiar with the concept of a pilot, where 90% of the end product is there and the intent is work out the kinks. Service prototyping can and should happen way before then.
Like prototyping, service prototyping is about learning, failing fast (roughly and cheaply) in order to design success. But service prototyping is method of methods – that is, it encompasses a number of tools and techniques. The key difference is that service prototyping is explicitly concerned with service design context itself – how it works, where it connects, who’s involved, what has to happen.
Service Prototyping in practice
So to our recent project. Unfortunately, we can’t share what the topic was about (public sector budget sensitive), but we can share that it was a rare case (when we talk to other designers in the service space) of service design not concerned with improving an existing service, but designing a new service. Blank page territory and a fantastic opportunity with a keen public sector client.
We can also share that the timeframe was tight – only five weeks. We’ve done tight service design projects before but this was extreme. It meant there was some documentation compromise in terms of depth, but in terms of breadth it was still collaborative intent > research > analyse/synthesise <> prototype/iterate > define. It also meant working closely with the team and their trust in us was critical to get to the right outcome all round – a service design that represented the users, and a service design they could use. It also meant service prototyping was invaluable to fast-track synthesis and engagement.
The opportunity for the nitty-gritty of service prototyping occurred about Day 12 – Day 15. We had done the background research, and field research with actual and potential users in one-on-one interviews and exercises. Up to Day 11 we formulated with the client representatives (our team) emerging insights – both from the internal and external view, emerging design principles and a value proposition for our component of the service within a broader service program context. And we had design features we knew would and wouldn’t work for users based on considering existing ‘like’ services.
Working up the service prototypes
On Day 13 we worked up the service prototypes for the workshop to be held on Day 15. They had to be paper-based and mobile because the workshop was going to be interstate, and in a room we where we knew we couldn’t stick stuff on walls. Sidenote: why do so many event facilities not allow you to use the walls!?
We started with all the information in our heads, a wall full of the refined insights, what we knew were key design features, the design principles and value proposition. We talked a bit about what we knew, and what knew we wanted to explore. And what we knew was likely to be the shape of the service.
And then we gave ourselves 10 minutes to sketch out how the service might work.
A bit of this, a bit of that, a bit of interpretation, a bit of personal perspective, some sacrificial red herrings, but mostly a lot of evidence. We named our concepts, and then we told them as a story – drawing out how the concept illustrated the pertinent points we wanted to learn more from. They worked! We then spent the next three hours working them into presentable component versions that we could put in front of people in a workshop. These components would also give the participants the means to work up their own versions during the workshop (some examples shown below – no artistic skill necessary!)
Workshopping the service prototypes
The workshop itself was half a day. Deliberately short for the participants who were a 2:1 mix of real users and business team representatives. The tight time also meant we could focus the thinking and activity; this was to be divergent and blue sky, but blue sky with feet firmly on the ground. After some scene-setting and informal validation of our findings so far using brainstorming and discussion we introduced the service prototypes. Telling them as a story the same way we’d done in the office. The energy of the participants was palpable as you could see they were naturally were inclined to particular prototypes they wanted to explore.
To do this we asked them to capture on the prototypes themselves:
- What worked
- What didn’t work
- What would they change or add
This quickly helped us test the basic precepts of the design principles and validate or discard key design elements.
After this first round we gave the participants the pens, paper and scissors and tape and asked them to design the service themselves. As designers it was a delight to see. Having had their appetite whetted with the ‘review’ and the means made accessible with the basic service component representations the participants weren’t intimidated. They were inspired!
Using the components from the original prototypes they built on them, coming up with their own user whose journey they plotted – exploring who might be involved, what tools they’d use, even giving themselves boundaries of service because it was a government service. To bring their prototypes together we asked them to:
- Name their service – which helps drill down into what it is at essence
- Describe it’s key features or benefits in their own language
- Describe what they thought might be some of the challenges – especially fruitful for their take on government service boundaries.
At the end, the participants had not only given us feedback, but had also seen and felt like they had been an active part of designing a service they would one day use themselves (hopefully soon).
The value of service prototyping
In this instance the timeframe meant it was critical to not compromise on what can sometimes look to the client like ‘play’. The value of the service prototyping enabled us as the designers, with the business team, to rapidly, roughly, and cheaply; propose, make, explore, discard, enhance, learn, and extract solution options in a few hours better than any individual crafting could have achieved.
Because the team representing the business and technology sides of the service were in the room and working with the users they were part of the conversation and saw how users interacted and talked and felt about the potential service experience. This gave them a better perspective of what was to be built. Not just what policy initiative or CabSub (that’s a cabinet submission for those of you outside of the public sector) needed to be met.
- At a practical level, the service prototyping gave us and the client clues and direction to the ultimate service design in a very short amount of time.
- At a client and service capability level, the service prototyping activities gave the client an exposure to the type of design thinking and practice that will help them approach their work differently because now they are thinking about humans using their service, not as use cases interacting with a system.
Early on in my service design career I would have said the value of service prototyping is something like “a technique that represents the most effective tool to rapidly process ideas in a collaborative way, engaging with business partners and customers.” Mostly because organisations still don’t like the idea of the user/customer being in control. But now I say, rough a service concept out, and then give the means to the users to prototype. They’ll amaze you, and the clients. And you’ll appreciate that you really can’t come up with the answers in the same way an actual user will. That said, you still have to do the service design – I ain’t saying users are designers, you’ve still got to design the service – but they and the prototypes will help you move more quickly from talk to design and towards an implementable solution. Which is the point.