Connect with Ethnography Matters

Leisa Reichelt (@leisa) is the Head of User Research at the Government Digital Service in the Cabinet Office. She leads a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.

Tricia: Leisa, thanks so much for taking time out to chat with me! So let’s get straight to it – you think most UX is shite. When you wrote a blog about this in 2012, the reaction was just amazing! People were beyond happy that you laid it all out. While many designers have made similar arguments, your polemic essay stood out because you tackled one of the major issues that are often ignored – how organizational culture leads to bad UX.

Leisa: It was definitely one advantage of being a freelancer – I was able to say exactly what I thought without worrying about how it reflected on my employer. I get really tired of organisations not walking the talk when it comes to user experience. It’s very easy to say that customers are your number one priority, but for most it will require some pretty fundamental change to actually follow through on this, and most aren’t up for it. Hiring a bunch of designers and researchers and sending out lots of surveys doesn’t cut it. You need to empower those teams to do good work and push the user focus throughout the entire organisation, not just attempt to delegate it to a UX team.

Tricia: So a year or so after your post, you entered into a behemoth of an organization – the UK government! Why did you take this job on and what it is like to be inside an organizational structure that is not known to be easy for designers and cultural change?

Leisa: I’m not sure I would have been so brave if not for the work that the Government Digital Service had done well before I joined. Through the process of designing and launching GOV.UK they laid out a great example of how a clear focus on user needs proliferating throughout an entire team can lead to great outcomes for citizens.

I initially joined to work on a really interesting identity project but saw a great opportunity to help GDS become even better at understanding and focusing on user needs by better integrating user research into agile teams. Government is a challenging environment to work in, but it is full of people who are really committed to doing the best they can for their country and its citizens. Traditionally a lot of research in government has still placed a lot of distance between the people who make the decisions (whether it’s interface decisions or policy decisions) and the people who are affected by those decisions. We are trying to close that gap and help enable teams to be able to see what the impact of their decisions will be for citizens. It’s exciting to see how enthusiastic people throughout government are to do much more of this kind of work and how well it works within the agile process.

The working environment is also very important. Our teams are small, project based, co-located, and multidisciplinary. We are encouraged to externalise the work (lots of sticky notes and index cards on the walls) which helps encourage an atmosphere of openness and sharing. Also, we have lots of bunting and cake – it can be difficult work at times, it’s important to keep spirits up and to have fun and enjoy the work we do.

Tricia: How much of the GDS team is made up of people who like you, worked in business?

Leisa: Ack, I saw the answer to this at our all staff meeting the other day (we have these monthly) and I can’t quite remember… there’s certainly been a big influx of people who don’t have any previous experience in government, which has been significant, I think, in helping to reset the expectations around what is possible to achieve in digital within government. It would have been impossible to achieve what’s been done so far and what we have ahead of us without a large contingent of incredibly smart, dedicated civil servants.

Tricia: During our conversation in London, you told me that you’re trying to shift the mentality of “research as nice to have” to “research as a key part of the process.” Why is this shift hard? And what are some ways you are encountering resistance? How are you framing this push?

Leisa: I think a lot of people have a history of research being time consuming and expensive and not necessarily providing a lot of actionable insight for the project team. When thinking about agile projects, a lot of people think of this kind of research and make what they believe to be the ‘pragmatic’ decisions to eliminate research entirely (maybe keeping just a bit of usability testing here and there) and rely solely on web analytics and whatever internal understanding there might be about customer needs. It’s unusual to find a researcher as an integral part in a multi-disciplinary project team, so people don’t tend to expect it or even necessarily know how to use a research properly. I think that if you are serious about putting user needs at the centre of your product or service design, then it’s essential that the entire team has regular opportunities to observe end users. This means you need a researcher in the team as an integral team member (a pig, not a chicken, as it’s sometimes described in agile). This is a learning experience and we encounter more or less resistance in different places. Mostly though people are enthusiastic about working this way and we’re hiring more and more researchers into teams all the time.

Tricia: So you’ve been at your job for a few months. What are some things you are focusing on?

Leisa: Hiring researchers! Trying to make sure that research is used well in all stages of the project lifecycle and in all kinds of projects (not just digital). Trying to work out how to take advantage of having a reasonably large team of clever researchers who are sometimes encountering similar themes across a range of projects, so thinking about things like how to make a collaborative cross-government research library. Lots of fun things.

Tricia: What kind of people are you hiring?

Leisa: Smart, passionate people who care about working on things that matter. I’ve got a mix of researchers who are more ‘User Experience’ shaped, so have experience either doing design work themselves or at least working very closely with designers. I’ve also got a bunch have more anthropologist or sociologist backgrounds who are mostly working on projects that have less digital interface. Oh, and I just hired a content strategist to help us with the research library project. We’ve got people with a range of experience – some have literally decades of experience, others are fresh out of university. They’re all amazing though, it’s a wonderful team.

Tricia: You write a lot about using Agile in your work. As a longtime borrower of Agile processes, I view Agile as an awesome toolbox that allows me to select different processes depending on the project or client. But I do find that Agile is limited for longer term and more in-depth research. How do you incorporate research with agile at your current job as the head of user research at GDS?

Leisa: I think this is a common perspective, but I think it depends on how embedded the researchers are in the agile project and how long the projects are allowed to run. At GDS we have an attitude of continuous improvement so research continues even once the project has ‘launched’, and in some ways, that’s actually the real beginning of the project. You might only do a little bit of research in each sprint, but on the project I’ve been working on this year we’ve now done more research with more people than I’ve done in any previous project I can recall, and we’ve also designed and developed an entire live service at the same time. If you have researchers who are in it for the long term and you think about the research you are doing as building an asset incrementally rather than just answering the specific questions of each sprint, then I think you can do a lot of long term and in depth research. And if there is something that you particularly want to investigate that doesn’t fit in with the product development that’s happening each sprint, then you can always do a research spike.

Tricia: What are some of the biggest obstacles for researchers and designers to successfully working together?

Leisa: I think it’s often just lack of experience working together and not knowing what the other can contribute to each other’s work. Often this is due to each being involved at different phases of the project. You really need to be sitting right next to each other almost all the time in order to be properly helpful. We like to think of designers and researchers working as a pair just like programmers work in pairs. The most important thing is for each person to not feel like they have to know it all and be perfect – creating a project environment where everyone is encouraged to experiment, to be allowed to make mistakes and be wrong sometimes and where learning is valued.

Tricia: In one of your blog posts, you argue that experimentation beats expertise. I totally agree with you, but why would you even need to make this argument? Do you still encounter designers who would argue with you on this?

Leisa: Absolutely. If you’re doing consultancy work it is very common to be hired into a team that has the attitude that you are the expert and you are going to walk in with the answers (not that you have processes that will uncover the answers). Lots of designers work in these kinds of environments all the time and feel pressure to get it right, the first time and then defend that first go at the design. In my experience, environments where designers and researchers can work together in an experimental way are rare and special. There should be many more of them.

Tricia: How has bringing a front-end developer to your work changed your output ?

Leisa: It’s meant that I’ve not used prototyping software (Axure and the like) for a long time, which is good. And it’s also meant that my HTML and CSS have not improved much in the last few years, which is not so good! It’s massively reduced the time it takes to get an idea into working code that can then be given to stakeholders to interact with and used as material for research. It allows our teams to be more experimental from earlier in the project and to have more opportunity for iteration (which I think is the secret to widely usable design). I hope never to work in a team without a front-end developer ever again!

Leisa: A prototype beats a powerpoint deck every time when it comes to giving an organisation the courage to make a risky decision that will ultimately benefit end users. And I say that having tried many times to get exciting things to happen with a powerpoint deck. Sometimes the real challenge is to help a team gain a vision for what they might be able to accomplish in response to understanding user needs rather than ticking things off a requirements list. Prototypes can create that vision and the energy in a team to do something great. Build a prototype and you make otherwise inconceivable concepts achievable and desirable – once you’ve done that, exciting things can happen.

Tricia: You’ve given so many great talks. Two of my favorites you’ve given are the ones you gave at dConstruct (Waterfall Bad, Washing Machine Good) and Frontend United (Prototyping your way to UX success). You are always very generous with sharing specific processes that you implement. Why do you give talks? What value do you get out of sharing your work so publicly?

Leisa: Good question – I often ask myself exactly that whilst waiting nervously to go on and talk! The reason I say yes to doing the talks in the first place is because it forces me to reflect on what I think is interesting and important and what I actually think about it. I find it hard to carve out time to be reflective so this creates that opportunity. So, in a way, it helps me and my own practice to go through the process of writing a talk, and I hope that if I share some of my own experience it can help someone else who hasn’t made all the mistakes I have, or who just needs someone else to point to so they can say ‘see, she said so, it’s true!’. Cheesily, I believe that talks that I do might help contribute to more teams doing better work and ultimately making better experiences for the world. I am relentlessly optimistic.

Tricia: I learned about ambient intimacy from you in 2007. You described it as “being able to keep in touch with people with a level of regularity and intimacy that you wouldn’t usually have access to, because time and space conspire to make it impossible.” I found 134 results for the term in Google Scholar and 15,200 results in Google search. That’s amazing. How have you seen the term being adopted by different groups of people?

Leisa: To be honest, I don’t really follow it much any more. I’m actually not sure it’s still relevant now!

Tricia: Well I still think it is relevant. Just look at how people use Instagram!

Leisa: Social media has changed a lot since those days – it’s a lot noisier for a start, which (for me at least) affects both the ambience and the intimacy. It was good to find a term for something that I felt very strongly back then, and I’m happy that it seems to have resonated with others.

Tricia: So what is a non-design book that every designer should read?

Leisa: I think Peter Drucker was a User Experience guy way before his time.

Tricia: OMG I had no idea Drucker was a User Experience guy? For reals?

Leisa: Well, he wouldn’t have identified as a UX guy but if you read his books you and didn’t know better you might think he was a User Experience guru. If you’ve not read some of his writing on business management, you should get onto that. (Managing Oneself is also a cracking read about understanding your own personal style – it taught me I often learn by talking about things, for example). In a completely different vein, I am thinking of handing out a copy of Good Days, Bad Days to people as they join the team – I tend to recite it at least once a week, and it helps.

Tricia: What would a Leisa music playlist for the UX designer look like?

Leisa: There wouldn’t be one! It’s not that I don’t love music, but these days working in highly collaborative agile teams, headphones on means you’re not communicating or collaborating, so for me the old days of spending hours moving boxes around a screen listening to great tunes is pretty much over. The only time I have my headphones on these days is to review research videos.

Tricia: If you had a magic wand, and there was one thing you could change about organizations, what would it be?

Leisa: I’d give all the C-Level management a REAL passion for their customers/citizens and the courage to make the changes needed to really look after them well.

Tricia: What do you do to clear your head?

Leisa: I am rubbish at clearing my head, I feel like I am constantly thinking about work, things we are doing or could be doing, trying to keep up with Twitter, and I get a bit obsessed with podcasts. Recently I’ve taken up cycling to work and back each day, that’s time when I have to just focus on the task I’m doing – staying safe on the streets of London, not falling into a pot hole and making up the hill without stopping – with no headphones in and no screen to distract me. At this time of year, some bracing wind – that blows the cobwebs out at each end of the day.