It’s always interesting to me to see who finds these discussions useful and who doesn’t. I’ve found that people I’m working with who are less familiar with design, research, user experience find the definitions useful. Within our teams we have to correct ourselves often, change what we called things before, get rid of previous habits of language, but that’s a good thing – every time we remember, we remind ourselves of why we use the language we use (because we’re testing ourselves and not our users, for example).

Interesting, the people who get stroppy about the definitions and say that it doesn’t really matter tend to be people who have been involved in the ‘user experience’ community for at least five years. I guess they have a vested interest in not being seen to be wrong. Or, perhaps more generously, they are just so close to the subject that any word will always be an oversimplification of all the beliefs, attitudes and practices of their work.

If you want to know what an organisation really believes in, look at the language they use in their day to day work – in their meetings, in their documents, in what they call things.

There are people, like Gill Ereaut, who do this as their full time job – they do linguistic analysis to help companies try to join up what they ‘officially’ say they are trying to do (their official language) with what people actually say as they go about their day to day work (the surface language).

Language is the medium through which culture is enacted – Gill Ereaut

A mismatch between surface and official language is a signal of ineffectiveness in an organisation. There can also be lots of different surface languages in different parts of the organisation that makes it even more difficult for communication across the functions and increases the impact of silos (for example marketing speaks a totally different language to the tech team).

Organisations who are thoughtful about the words they use repeatedly are more able to have a more consistent culture that allows their strategies to come to life in the products and services they create and the way they interact with their audience (this works even if those words might appear artless, like ‘show the thing’, something people at GDS say all the time and even have a poster for)

Changing the words on the hymn sheet won’t create a whole new religion, but, as Gill says,

‘linguistic change at the surface level affects the assumptions held by the organisation’.

Especially when it comes to customers, making sure that the words we use in the organisation are empathetic to the people the organisation is serving and that it reflects the type of experience and interaction that the organisation wants to have with those people sends daily micro signals widely through the organisation that this is something with which it is genuinely concerned.

In her talk at Design of Understanding conference in 2012, Gill (yes, I am a bit of a fan) talked about an organisation where she’d done some linguistic analysis. This was an organisation that believed that they cared about good quality customer service, but analysis of the way the organisation communicated showed that actually, they were afraid of their customers – they were distant from and lacked empathy for their customers, making it almost impossible for them to really deliver great customer experience.

Every day, in the words that organisation used, in the names of their processes and documents, in the way they communicated with each other, they were entrenching this fear of the customer that made it impossible for any corporate level ‘Customer Experience’ strategy to be effective.

Words can remind us many times a day what we all care about and what we believe in.

Changing the words we use can help us to change our culture in tiny moments every day and help us to be more able to implement strategy effectively.

Calling it user research instead of user testing won’t change the way the moderator runs the session or the experience of the research participant. As the person who is running the sessions, it probably makes no difference to your competence what you call it. But deliberately deciding to call it user research even though your reflex is to call it user testing means that every time you choose to use the words we’ve agreed on, you are also agreeing, once again, to the reason we chose those words – because we’re testing ourselves, our work, our design, our services and not our users. Because we are in service to our users and if they don’t understand, that reflects poorly on us and not them.

Being thoughtful about words seems to be one of the simplest and least confrontational yet most powerful ways to transform organisations in tiny moments every day. Teeny, tiny moments of strategy everyone in the organisation can implement every day.

Thus, words being symbols of ideas, we can collect ideas by collecting words. The fellow who said he tried reading the dictionary but couldn’t get the hang of the story simply missed the point: namely, that it is a collection of short stories. – James Webb Young, A Technique for Producing Ideas

This is the sixth post in a series of rambles around the topic of strategy in the general vicinity of user experience which I’m posting as a kind of obituary to the book I almost finished writing then realised was pretty much completely wrong.

It’s not a great use of time to debate exactly what is a strategy and what is not, but what makes more sense to me is something more like this:

Goal: Take the hill. Strategy: Skinny guys behind trees, fat guys behind rocks. Tactic: Find the nearest rock/tree that will help me get closer to the hill.

Some people seem to think that strategy needs to be a comprehensive statement of what you’re doing and how. I think it’s better to have a number of smaller strategic approaches that can be joined together – a modular approach to strategy.

If you’re waging a war, playing a football game or trying to do whatever it is your organisation does, the kind of strategy you don’t want is a ‘play by play’, an inflexible, linear strategy that requires the entire world to stay exactly as it is (or exactly as you plan it to be) in order for your strategy to succeed.

Most of us now operate in environments that are crazily complex and uncertain, subject to unpredictable change. Competitors do surprisingly good things, financial sectors have unpredicted crises, a whole new programming language is required (or deprecated) by an company that is critical to accessing your end users, a butterfly flaps its wings….

The kind of strategies you need are ones that the troops can apply even when they get separated from their commander and each other. That allows them to know what they should be doing without relying on being told. It allows them to reliably predict what all the other brave soldiers would do in any given situation. This allows the company to behave in a reasonably unified way.

Having a collection of easily remembered, easily applied strategies work best. Strategies that everyone in the organisation can apply. Strategies that are complementary and integrated. Strategies expressed with carefully chosen words.

Someone commented in on a previous post saying that although GDS says ‘the strategy is delivery’ this is not a strategy because it doesn’t say what is being delivered. This is true in as much as ‘the strategy is delivery’ is not the only strategy in play, but I’d argue that it is still very much a strategy and is used in a strategic way.

Modular strategy works something like this.

Combine ‘start with user needs‘ with ‘making digital services so good that people prefer to use them’, ‘the strategy is delivery‘ and ‘show the thing‘ (four strategies that are widely in use at GDS). This tells the team an awful lot about what they should be focussing on and how they should be working.

You can apply this at a project level – what should we be working on and prioritising as a team right now? Answer: quickly making a thing (probably a prototype to being with) that addresses the things that are most important to the end users (or finding out what that is if you don’t know), making it as easy for people to understand and use as possible, getting stuff live, iterating based on research, analytics and feedback.

Apply this at an individual level and you also get a lot of guidance. As a user researcher, for example, we are constantly focussed on understanding our users and their needs, and working with the team to iterate design improvements and test new features. We take a delivery focussed approach – optimising for providing actionable insights for our team over taking the most robust research method.

When you’re doing something for the first time, when you’re choosing between different approaches, deciding what to do and how to do it, when there is no one around to tell you what you should be doing – you can go a long way to doing the best thing by applying these strategies.

Have a clear goal – know which hill your organisation wants to take, but then have a whole load of strategies that can be combined to help project teams and individuals be empowered to make decisions that are aligned and will all work together to help achieve the goal.

There are hundreds and hundreds of people who work where I work, and we have quite a few strategies that we apply in our work on a daily basis but I’m pretty sure that there is no one in the organisation who has the work ‘strategy’ in their job title.

(OK, there may be one, but if you meet him, he’s more than likely to introduce himself as the Director of Powerpoint, which kind of supports the point I’m about to make).

Strategy is not a thing at the top of the hierarchy in our organisation and I think, compared to other places I’ve known and worked, we’re reasonably good at strategy. I think this is probably a big reason why we are reasonably good at strategy. Because we all own it.

Strategy only works if everyone in the team believes in it. If they feel ownership over it, over the ability to act on it, to make it so, every day.

Strategy doesn’t work so well if there are a few people who get to go to all the fancy lunches who ‘own’ the strategy. Strategy doesn’t work if it is a land grab, a desirable job title, a person with all of the power who gets to tell people what the idea is and then get exasperated when the execution doesn’t live up to his what his slide deck said it would be.

Strategy needs servant leadership. The unit of delivery is the team.

If you want to be the most awesome strategy person here is what you need to do:

Help your team find the right, succinct set of words to describe what they believe they need to do to succeed.

Help them to find the opportunities to say those words over and over again – especially as they use them to help make decisions about what not to do, what to do and how to do it.

Get out of the way and let them believe it this was all their doing.

This is the fourth post in a series of rambles around the topic of strategy in the general vicinity of user experience which I’m posting as a kind of obituary to the book I almost finished writing then realised was pretty much completely wrong. This is some of the stuff I probably should have written instead. You can see the first post here, the second one here, and the third one here.

This is the third post in a series of rambles around the topic of strategy in the general vicinity of user experience which I’m posting as a kind of obituary to the book I almost finished writing then realised was pretty much completely wrong. This is some of the stuff I probably should have written instead. You can see the first post here and the second one here.

I’m a big Peter Drucker fan. He was a User Experience guy way before there was such a thing as User Experience Guys. (I wrote up some of my favourite things about Peter Drucker in the earliest stages of trying to write my Strategic UX book. You can read them here.)

Drucker is the guy who apparently said ‘culture eats strategy for breakfast’. I think he’s right, but I also think it’s not as simple as that. I think that culture is strategy in action.

So, culture and current strategies are dependent. Culture and proclaimed strategies are often competitors. And there are probably things that we do that encourage the culture we currently have and discourage the culture (and day to day strategy) that we want.

This makes me think of Stewart Brand’s great book ‘How Buildings Learn: What Happens After They’re Built’ (based on a BBC series you can watch in full on YouTube).

In considering the life of buildings once they’ve been designed and come into use, Brand observes the way that we ‘iterate’ buildings so that they better suit user needs. (At least, the good buildings can be iterated rather than bulldozed). There is a great diagram in the book that shows the different ‘layers’ of buildings and the relative speed at which those layers are able to/likely to change.

This makes me think about layers of strategy – firstly that these different layers exist and also that the rate that those layers should change will be different. Some strategic layers should be able to change quickly and others ideally move more slowly. In the same way that you don’t want to change the structure of your house every couple of months (probably), it’s also less than idea for some of the strategic foundations of your organisation to change substantially on a regular basis.

Things like your value proposition, you don’t really want to move that unless you really have to, it should be a slow moving strategy. For somewhere like the Government Digital Service, the Digital by Default Service Standard should be a slow moving strategic document.

This is a document that asks the whole of the UK government to change the way that it creates and maintains digital services in a fairly substantial way. A lot of people are doing a lot of work to get into alignment with this strategy.

The Service Standard should be able to be iterated (to be improved and to respond to change in the world) but it shouldn’t change substantially at a rapid pace. If it changed all the time it would massively compromise it’s ability to be successful.

Neil Addison thought that my use of the word ‘enshrined’ when talking about strategy was indicative of a problematic mindset (and I think he was right to pick it up as a red flag), but I think that it’s indicative of a slow moving strategy. If you’ve got a big ship to turn around, you need some consistency in your approach.

Slow moving strategies can help you get lots of people to get lots of activities into alignment. If you want to do some big things, you need some slow moving strategies.

On the other hand, fast moving strategies can be very useful for helping to shift culture.

Strategies that are smaller, more malleable, and able to be influenced by people at all levels of the organisation. Strategies that form a part of the daily tasks of people in the organisation.

Agreeing and applying design patterns might be a good example of fast moving strategy. Conversations to form and iterate design patterns involve lots of different people in the organisation (or they should), including designers, front end developers, user researchers, security specialists – just for starters.

The goal of the design pattern is to try to get everyone working to a consistently high standard of interface design (and ideally with some consistency in the interface), but obviously as the organisation learns more and more, the quality of the design patterns and their implementation will continue to iterate and improve.

Even more important, the discussions that people have on a daily basis as they implement and challenge the design patterns encourages discussions around design, user research, and technical implementation that help to build a culture where design, user research and technology well implemented is valued.

This is what you’re aiming for: layers of strategy from fast moving ones that people ‘work’ on every day that integrate with the next layer out so that ultimately work that you are doing day to day has an evident link to the big, slow moving strategies.

Fast moving strategies that give people small ways to align their work to the bigger picture – letting people ask ‘what’s the user need?’ or to think ‘publish don’t send‘ as they decide whether to send an email, write a blog post or update the wiki. (yes, some people do update wikis).

Being about to routinely, every day, every hour, align the choices you make to the strategies of the organisation you work for, that helps build culture. Especially if you’re all using the same words when you do it.

Its just one ingredient of culture, but being empowered to make tiny small choices to align and sometimes even adjust the strategy of the organisation – the fast and the slow layers, eating strategy for breakfast, lunch and tea helps ensure that you build a culture that’s not just ‘healthy’ but is aligned and supportive of the strategic goals of your organisation.