Everyone is doing strategy right now.

Leisa Reichelt18 Comments

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

Leisa Reichelt21 Comments

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.

 

How we do user research in agile teams

Leisa Reichelt

Originally published on the GDS Blog

Getting user research into agile teams in a way that is timely, relevant and actionable is a challenge that teams the world over are tackling. Working effectively in agile has recently been the driver of some fairly significant changes to the way our researchers work at GDS.

In the early days of GDS, the User Research team worked across the different projects here, as well as helping support the exemplar transactions. We did a mix of in house research, as well as managing usability testing and other research that was outsourced to specialist companies.

Using this model we found it difficult to provide insight to teams quickly enough, and researchers were spread across projects to the extent that they were never really a part of the team shaping the design or developing real depth of expertise in a particular product or its audience. This was less than ideal for both project teams and researchers.

We’ve been iterating how we do research in the same way we iterate our product design, and learned that the following techniques seem to integrate good research into agile teams more successfully.

Dedicated researchers for each team

Rather than a team of researchers taking research briefs from lots of project teams, each project team has a dedicated researcher working closely with the team of designers, developers, content designers and product owners.

This allows the team to be closer to the product design and adopt a more ‘experimental’ approach  hypothesising about what design or content approaches might work and designing ways to measure what is more or less successful.

Test designs at least every fortnight

The ‘two week rule’. We don’t design anything for more than two weeks without watching real end users interacting with it. This means that most teams are out in the field or in the research laboratory at least every fortnight, putting our design and content in front of potential end users.

Everyone in the team should take part

We believe that research is a team sport and encourage all team members to observe research sessions for at least 2 hours ever 6 weeks. There is good evidence that this helps teams create better products. And having dedicated researchers in our teams makes it easier for everyone on the team to get regular opportunities to watch people use the product they’ve designed.

A varied toolkit

It’s easy for teams to get comfortable with a small set of research methods and to use those for everything. An experimental mindset requires that we are always looking for better ways and a more varied research toolkit to help us get a richer and more accurate understanding of our users and their needs.

We use a mix of qualitative and quantitative methods and work closely with our web analytics colleagues to design studies that allow us to better understand how people respond to interface design and content using A/B testing and detailed path analysis in early prototypes.

See it through from analysis to action

Getting interesting insights from research isn’t hard. Getting those insights into the design of products can be surprisingly tricky. We analyse our research collaboratively and make sure we extract both findings and actions from each study. Findings build our understanding and go into our research library. Actions go into the project backlog, into sprint plans and therefore into the product design.

We don’t do powerpoint presentations or detailed reports and we use the time we’ve saved from that to work more closely with the team.

Sharing what we learn

As we do more research in more of our teams, there is a lot to gain by sharing our findings. We’re experimenting with ways to capture and share research across teams and even across departments, so that research becomes a real valuable and reusable asset for government.

We’re iterating how we work in the same way we’re iterating our projects. As we find better ways to work within teams and within the agile framework, we are better able to help teams build empathy with users and shape products that are focused on their needs.

Experimentation beats expertise

Leisa Reichelt2 Comments

I found the design process utterly transformed once I decided to stop trying to be the expert and start trying to encourage a culture of experimentation.

Battles that would rage, angrily, for months – dying down when the provocateur was busy with other work but rising up as soon as they had a little time on their hands – these battles began to go away. Long frustrating and unproductive sessions of trying to explain, defend, rationalise why the design that I suggested had more merit than the many and varied suggestions (or requirements) coming from stakeholders all but disappeared. People who would usually sneer derisively at the design team became participating members of the design process.

It’s not perfect, it’s no silver bullet, but for me, it’s been a transformation.

And it’s pretty simple. To embrace experimentation you just need to stop talking about design in a Socratic way (other related but less civilised methods are also very common) and start formalising hypotheses and tests.

Stop having meetings to argue about which design approach is better  – endless meetings with stakeholders full of defensiveness and crazy arguments where the people who tend to win are those who are loudest, most persistent or highest paid. Start making decisions based on lightweight research that provides evidence (sometimes stories, sometimes numbers) to support the design that most strongly supports the agreed goals.

Goals. That’s one pre-requisite you need for this experimental approach to work. You need to have agreed what your goals are for the design. What success looks like. Without this agreement, no change to methodology will save you.

The experimental mindset is an egalitarian approach to design. It allows that anyone can suggest a design solutions and, rather than argue endlessly about whether it is better or worse than other approaches, you design a test. Find out how to find out which design works best.

Hypothesis, prototype, test.

There are loads of tools you can use to test ideas quickly – from some quick in person user research, to some A/B testing (if you’re not set up to do A/B testing, meet your friend Google Content Experiments and get onto this immediately), to an online card sort, to one of the range of tests that places like VerifyApp offer. The methods for testing are limited only by your creativity and are mostly inexpensive.

Sure, you can’t design from the ground up this way – you will still need a good designer that you trust get you to a good starting point from which you can experiment up, but once you’ve got the framework in place, don’t waste time and goodwill bickering about the details but encourage experimentation throughout the entire organisation. You’ll raise the overall ‘design IQ’ and happiness quotient of your company, your design team and, most probably, even yourself.