where does crazy come from?

Leisa Reichelt1 Comment

You can imagine how this went down.

The lawyers decided that the privacy policy needed updating, so they updated it and put it on the website.

Then they decided that they had to make sure people knew about it. Who knows why… I can only imagine because they’re actually starting to do something that they know people probably won’t really be happy with (or they’re beginning to admit that’s what they’re doing), so they need to prove that a certain number of customers knew about it.

They say, ‘put a sign up in the stores, we have to do this because this is a risk to the business. It could damage our brand and cost a fortune in law suits’.

No one wants to be the person who is putting the company at risk and responsible for lawsuits, so they don’t ask any questions except for what is the cheapest and easiest way to meet the lawyers’ needs.

I imagine the email the lawyers sent (it would totally have been an email and not a meeting), the meeting to discuss what to do about the lawyers email, all the emails to argue about which type of signage they’d use, what would get bumped so this sign could exist, arguing over the wording. And finally, the meeting where someone approved this.

And so it is that, as I go to buy some paracetamol, I am informed that the privacy policy has changed and I can find out about this on the website.

I wonder – is this just the website privacy policy, or the Boots loyalty card privacy policy, are those the same things or different?

I wonder – how many people would pull out their phones or rush back to their desks to find out what changes have been made (I did… I couldn’t resist. There’s nothing to draw your attention to this information on their website and the section on privacy doesn’t make any reference to recent changes). Even if I do want to find out about the changes to this policy, I can’t see how on earth I might meet that need on their website.

I wonder – did they think about how it would make people feel or act to see this.

I wonder – did anyone fight for this not to happen? They probably did. Fear won.

I wonder – if a law suit did come up, could Boots actually prove that this has sufficiently informed people of the change to the privacy policy? Probably not.

I wonder – what opportunities were lost to actually understand the end user need and design a way of meeting that need in a way that benefitted the relationship between Boots and their customers.

You see these little things that companies do, you can see that all they’re doing is ‘ticking a box’, a token effort for the lawyers or whoever else, and you know that they’re pushing the burden onto the customer, and probably missing gigantic opportunities to be really great.

Fixing the crazy way things like this happen is at least as important as designing the shiny signs and the websites.

being more human at work

Leisa Reichelt1 Comment

I went to see Steve Hilton talk about his new book, More Human at the RSA last night. I was sufficiently inspired to buy his book and I’ve just finished the chapter on government – so only just started really.

As I read it I keep flip flopping between feeling hopeless and excited. Hopeless because the future he imagines requires such enormous changes in both government and society that – as good as they may be – how will they ever happen? And excited that there is someone who is as relentlessly optimistic as me, who seems to think that if you just say it often enough and clearly enough, perhaps enough of the right people will listen and do something sensible to radically change the world we live in so that it is fit for purpose for now and the future.

Then I thought about my little personal rule:

If the process insists that humans act more like machines/robots/spreadsheets than real human beings, challenge that process.

Don’t just accept that the process is right. That the way you’re doing your business planning and budgeting (something that’s on my mind at the moment) is actually sensible just because it has a form you fill out and makes numbers in the spreadsheet that create the impression that we have a process that ensures the most important things get funded.

Don’t just accept that the performance review process is right just because it appears to enact a policy that is theoretically designed to be fair and equitable and that gives the managers graphs that makes them feel as though they understand how people in their organisation are performing.

Just because it appears to be rational doesn’t mean that it is not entirely insane – and the best predictor of insanity in business process is a person who is still thinking and behaving like a human being. (Too many of us get trained out of keeping our humanness in the workplace – I’ve heard it’s a good way to get promoted.)

Consider every business process as a (usually) poorly solved design problem and approach it like a design team should – firstly understanding the what the actual problem is then thinking about different ways it could be solved, and then choosing the one that actually solves the problem – remembering that businesses are really nothing but groups of humans trying to work together to do something great. (There’s that relentless optimism again)

Insist on speaking and acting like a human being, especially in the workplace. Any time you’re not listening or not being heard, or being forced to communicate in a method or manner that doesn’t feel natural, throw up the red flags.

It will make you a right pain in the arse to work with, just ask any of my colleagues, especially my bosses. But it is the right thing to do.

If more of us challenged and fixed small things to make them more human then I’d have a lot more hope that the world that Steve Hilton envisages – a world where people come first – might ever come into being.

 

 

We need to talk about user needs

Leisa Reichelt

Originally published on the GDS User Research Blog

‘Start with user needs’ is the first of our design principles and it’s the first thing we ask teams to demonstrate to meet the Digital by Default Service Assessment. Even Members of Parliament (video) talk about user needs these days. This is all good.

But what does it actually mean to understand user needs? How do we do it right?

Observe and talk to end users

Do user research to observe and talk to users. Understand what people are really trying to do, and the real problems they have trying to get something done. That will show you what their needs are.

Needs can be functional and emotional

Needs can be functional things people need to do, for example, to check eligibility. Needs can also be emotional, perhaps people are stressed and anxious and they need reassurance.

Both of these types of needs are important to understand if you want to design services that are so good people choose to use them, and are able to use them without assistance.

There’s no substitute for talking to real users

You need to go to the source – to the user, and discover (not just validate) the user needs.

You may get some user needs from stakeholders, but you won’t get them all. You can’t even guarantee to get the most important user needs from stakeholders.

Some of our colleagues might be service users, but at the very least we tend to know far too much about government and technology to accurately represent ‘typical’ end users.

Treat ‘user needs’ from stakeholders as assumptions

You are not your user and you cannot think like a user unless you’re meeting users regularly.

Our delivery teams and various stakeholders never accurately represent our end users. Not even when our end users are civil servants. Treat any user needs you get from stakeholders as assumptions.

Get out into the field

In the discovery phase of your project, your team should be out in the field doing user research. You should be discovering what your end users are doing when they encounter your service.

This let’s you make sure that your service is a verb – a thing that supports a task that people are trying to do, not a noun – the thing you’ve always called the form before.

Understanding user needs saves money

Understanding user needs enables better service design which results in greater digital take up, higher compliance, more effective policy outcomes, fewer user errors and inaccuracies, reduced failure demand and, overall, makes your service better value and cheaper to run.

And it also just makes the world a better place. That’s good too.

Doing user research in the discovery phase

Leisa Reichelt

Originally published on the GDS User Research Blog

Here are some things you should know about doing user research in the discovery phase.

  1. You should definitely do user research in the discovery phase.Understanding who your users are and what’s going on when they come across your service is one of the most important parts of discovery. Have an experienced user researcher in your discovery team. Plan for the rest of the team to spend plenty of time going out into the field to meet real users with the user researcher.
  2. Discover people not projects. If you want to deliver a service that really meets user needs, you need to understand what people are trying to do, and how they’re trying to do it, when they encounter your service. This means that research during discovery might seem ‘bigger’ than it needs to be for your specific project. This is because you’ve got a bunch of preconceived ideas about what your project should be. This is exactly why we do user research: to find out what people are doing now to solve their problem, understand what needs they have, and to understand how we can best help meet those needs. Then it’s time to work out what the project should be.
  3. Discovery is for discovering, not for prototyping. Making is an excellent way to learn about a problem, but that doesn’t mean you need to make from the very beginning. Put the code away for a few weeks, get out into the field, and understand your users. Understand how different they are from you and your team. Spend some time doing this at the outset of the project, and it’s much more likely that the thing you make will meet everyone’s needs and not just yours.
  4. If you haven’t discovered you were wrong about some things, you probably haven’t done it right. Discovery is not for validation. The point of research during discovery is to work out what people need, and what you need to do to meet those needs. It’s not to prove that a project should proceed. If you set out to validate, you won’t learn what you don’t know. What you don’t know is the thing that will ultimately make your project fail. It’s fine to have some hypotheses about what the project will be, but go into discovery to test those hypotheses, not to validate assumptions. The way you frame the user research in discovery will make all the difference.
  5. Do qualitative, contextual user research in discovery. Try to meet at least 6-8 people of each ‘type’ of user of your service. (Your user researcher will help you understand what ‘types’ there might be and which ones matter). Go to the place your users are currently doing the thing you’re going to make better, and get them to show you how it works, what it looks like, how it makes them feel (user needs are both functional and emotional). Don’t ‘outsource’ this and get a report and a presentation at the end – bring the team along to observe the user research – everyone should see at least 2 interviews.
  6. Maps and stories are good things to make with user research in discovery. Lots of teams have found that making maps of the journey that people go through (in doing the thing they need to do when they encounter your service) can be useful. It’s also important to try to capture the stories of the people you meet, what they’re doing and what their needs of the service are. There is no one right way to do this – talk to other people who have tried different things to get inspiration (being part of the cross government user research community is a great way to do this).

Doing user research to understand your users will help make sure you design the right thing, before you start worrying about designing it the right way.