Strategy fast and slow (or culture IS strategy for breakfast, lunch and tea)

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.

The culture you see reveals the strategies that people are actually employing in their day to day work – not the ones that are proclaimed on posters by the lift or in the annual business plan.

And, as Joshua Porter would say, the behaviour you’re seeing is the behaviour you’ve designed for. (Granted he was referring to the behaviour of people in social systems on web application, but I think the wisdom holds).

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.

Things get cool when your fast moving patterns integrate well with some slower moving strategies, like design patterns (faster) integrating with design principles (slower). For example, plenty of discussions about design patterns reference the design principle ‘do the hard work to make it easy‘.

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.

or something like that.

Strategy doesn’t live in a silo (or, there is no such thing as UX Strategy)

This is the second 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.

I started trying to write a book about UX Strategy not long after my youngest son was born. This all started because Bruno Figueiredo, who does a wonderful job organising the great UX-LX conference, had asked me whether I thought I could run a workshop on UX Strategy for him. I figured I did strategic type stuff whilst doing user experience work all the time, so how hard could it be?

Turns out, pretty hard.

I spent the following years trying to write about UX Strategy and find myself, with my youngest son about to start school, still not knowing what UX Strategy is. I’ve met plenty of people who are employed as UX Strategists, and I’m still not clear that what they do is specifically a part of the discipline of user experience.

Certainly, there is user experience work that is done more or  less strategically but there is isn’t a role for a person in the UX team to come up with the UX Strategy.

(Of course, along the way I have also been convinced that it’s not legitimate to use the label ‘UX’ when defining a job role or a team either, so perhaps I’m just going through my nihilistic phase?)

Of course, corporate strategies are incredibly influential when it comes to impacting the overall user experience, but they only really effective when initiation and ownership comes from the highest level of the organisation.

Let’s take the my current workplace as an example. If you asked people who work at the Government Digital Service what our strategies are you will almost certainly be referred to one or more of the following:

  • simpler, clearer, faster. You can find this headlining an actual government policy and you fill find it as the tagline on GOV.UK This is not something that a UX team came up with, but it is something that the entire organisation and all of the different disciplines within that organisation use as guiding principles for deciding what to do and how to do it.
  • our design principles. These are called ‘design principles’ and I’m pretty sure they mostly came from the design team (although, GDS people, feel free to correct me), but they are now used by people to make important strategic decisions, like whether or not a project should even be started (is there a user need?)
  • similarly, what the UK Government now considers to be essential practice for teams building digital services is now enshrined in the Digital by Default Service Standard. Again, parts of this might read like what could be a UX strategy, but even those parts are also important guiding principles for people who are doing very different things that making wireframes and journey maps.
  • Probably the most important strategy of all is delivery. Doing less hand waving, white paper writing, frameworking making, and just actually making things and letting people use them so that we can start learning and iterating and actually improving the experience that people are having every single day. This might be a strategy that radically improves the user experience, but it is certainly not a UX Strategy. It’s a statement of intent that informs every decision made across the organisation every day.

This is not just true for UX Strategy. It is the same for technology strategy, security strategy, social media strategy, content strategy. None of these can be effective in isolation, the only strategy that works is cross-disciplinary, multi-disciplinary, integrated across the organisation.

Users win when the whole organisation orients itself around the users so that the technical team, the security team, the content team, the social media team and the designers and researchers all make decisions in the users best interest. Otherwise, all you get is handwaving and frameworks.

Everyone is doing strategy right now.

this is the first 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.

Everyone wants the strategy job. It’s much sexier than the ‘implementing the strategy’ jobs. That’s why the people who have managed to get the strategy jobs have a vested interest in making sure that doing strategy stuff seems very important and serious and senior. And confusing. You don’t understand exactly what these strategy people do, do you? (Except make frameworks or models and wave their hands around a lot). That’s kind of the plan. You continue to be intimidated by strategy and keep doing the implementing while the strategy guys get to go to the fancy lunches.

Fact is, everyone is doing strategy stuff all the time. If you choose to do one thing and not the other (which we all do every day), we’ve got a strategy. We might not know what that strategy is, but it’s there. Common strategies include:

  • do something that will help me avoid having to do the hard thing for another ten minutes.
  • do the thing that will win me the most brownie points with my boss
  • do the thing that my boss will hate the least
  • do the thing that I’m best at

By applying this strategy you are able to choose tasks in a coherent way that will achieve an end goal – avoiding the hard stuff, not making your boss cross, feeling clever.

These are simple strategies, true, but everyone is using them every day. The Strategy Guys forget about this a lot of the time when they’re making their frameworks. That’s a bad thing.

There are some pretty simple ways that you can evaluate the effectiveness of a strategy.

  1. How conscious is the person/organisation of the strategy? Do they know that they are using this strategy to make decisions, is the strategy clearly articulated.
    Often people and even entire organisations have no awareness of the strategies they are employing.

    As a general rule, the more consciously people choose to apply a strategy, the better the outcome.

  2. How well is that strategy helping you achieve your/your organisations goals?I might say that I’m trying to get a promotion into a senior role, but the strategy I’m currently applying is to avoid the hard things. My company might say that it is committed to user experience but the strategy they are currently applying is to value quantity of features delivered over meeting user needs.

    Strategies that match your objectives tend to work best.

    (I have an outstanding question as to whether clearly stating your goals makes a significant difference to the strategies you choose and their effectiveness)

  3. How integrated are people’s personal strategies with the organisation strategies.Do coworkers tend to share similar personal strategies in the workplace? How well do those personal strategies integrate with the organisational strategy? Do all the strategies work together to help meet goals or do they counteract each other.

    Does your strategy for having a good family life work with you strategy for getting that promotion? Does your strategy for having a good family life fit with your organisations strategy for being first to market? Does your strategy for not making your boss cranky fit with the organisations strategy of failing fast and learning from mistakes?

    Well integrated strategies are more successful.

Strategy is not a fancy thing that only a few special people can do. The reason they can’t really explain to you what it is is because it’s not really much more than an idea. As with ideas, most strategies are cheap and there are plenty of them. As Mike Tyson apparently said ‘everyone has a plan until they get punched in the face’. Actually implementing strategy, in the real world where there are always a plethora of competing personal and organisational strategies already in place, that’s the hard thing.

You are already doing strategy today. Don’t waste time trying to come up with the perfect strategy. Take time to understand the strategies that are in play today, make those as visible and addressable as you can, and start iterating.

There is no UX, there is only UX

After years of trying to work out where the UX team should fit into the organisation, it feels almost inevitable that my current thinking is that it belongs everywhere and nowhere. That there is no UX team, but that everyone is the UX team.

I came to this way of thinking by trying to negotiate the organisational structure of the Government Digital Service and their philosophy about user experience. At GDS we don’t have a ‘UX team’  and no one person has a job title that includes the term ‘UX’. We have designers and researchers who work as part of multidisciplinary, agile teams and who practice user centred design (UCD).

On the surface that may all sound pretty trite. The truth is that, for many of our projects,  the truly challenging user experience issues come not from designing the interface*, but from the constraints of the product that must be designed. Those constraints and challenges tend to come from our friends in policy or standards, or procurement or other parts of the organisation. Try as you might, you can’t interface away inappropriate policy.

It is really important that no one in the team can point to someone over in the corner and put all the burden of user experience on that guy. No one person, no small group of people can be made responsible for the user experience of a service. It is down to the entire team  to achieve this, and we need to drag people into the team who make decisions way before we get on the scene. (Should we be there earlier?  Perhaps. That’s one for another day).

I don’t see this as a governance issue. It’s not about who is ‘in charge’ of user experience. It’s a philosophical framework for sharing the responsibility for the users’ experience and allowing problems to be directly attributed to the true source, often far more deeply embedded in the organisation than the interface.

It assumes the prerequisite that the entire team agrees that it’s true goal is to create a great user experience. That is no small assumption.  The UK Government is relatively rare in having a stated aim to build services so good that people prefer to use them. Many organisations pay lip service to caring about user experience, but sharing the responsibility throughout the entire organisation tests whether they are really willing to back this claim through significant organisational change.

Not calling people ‘UX’ does lead to interesting challenges in day to day work –  like how to refer to the team who do the interface design and user research. This is when we’re most likely to get lazy and just call people ‘UX’.  Although it can feel cumbersome, every time you don’t give in, it’s a tiny little reminder of what we believe. Every time we call that team the ‘front end team’ on the project I’m working on it reminds me of our belief. That makes the somewhat awkward title totally worth it for me.

Related reading:

How we do user centred design in alpha and beta phases (Service Design Manual)

How we do user research in agile teams (GDS Blog)

* Having said that, trying to design user interfaces that everyone in the country should be able to use is no small challenge.