Three enemies of UX and how to defeat them

Lee Duddell, UX Director at UserZoom and Chris Lockhart, Web Content Lead at the University of Southampton presented a talk at 2018’s OneWeb Festival, where Lee discussed his experiences with organizations battling the toughest UX villains, and Chris revealed how his team has solved these issues with help from UserZoom.

Enemies of UX

First, let’s just think about what we mean by UX. So, over my long 10 years working in this sector, UX has meant about 15 different things. What it means today is creating and providing a digital experience for your users that is desirable because it meets their needs and their expectations, is free of frictions, but also meets your needs, as an organization. It’s not about making things pretty, it’s about making things easy to use and valuable to users.

It used to be that it was all about colors and visual design. Now, visual design has its part in UX,  take Amazon as an example. It does very well without being particularly pretty. It’s never won a design award ever, but it’s highly functional, it gives users and customers what they want. So it clearly has a good UX. I think everyone agrees that having a good UX is a good thing, but if that’s a commonly held belief, why is it that so many sites are so difficult to use? They’re just not meeting expectations.

University websites, embassy and visa websites, high school websites, are among the worst and could be improved in terms of their UX. I’ve spoken to lots and lots of organizations over the years to understand what’s preventing them from delivering a great user experience and I’ve discovered there are three core enemies of UX, and here we’ll look at each of these in a little bit of detail.

1) HiPPOs

HiPPO stands for the ‘highest paid person’s opinion’, and this should resonate whether you work in digital or not. A lot of design decisions are made by people who get paid a lot, but really are not the end user. So they will say, “This is what our customers need” but how do they know that? Because they’ve been working for 20 years in the sector, and they think that gives them some innate knowledge to know what people need, and know how to deliver a great UX.

When you’ve got a senior person in a room, they’ll draw upon their own personal experiences and they will throw their weight around, but essentially they’re just guessing. It’s not really data or insight, they just get paid the most and therefore their opinion counts more than anybody else’s.

How to deal with ‘HiPPOs’

The HiPPO situation is all to do with authority bias, and this often comes into any situation where there’s a difference in people with seniority – you always want to try and do what you’re asked to do. HiPPOs across our University are doing all sorts of things that we need, setting strategy, leading teams, driving initiatives, and that’s all really vital. But we need to be led by data, not by opinion.

So what is the data that we can’t ignore? User experience means data, and there are two types of data that go into user experience. There’s the stuff that first helps you find what user needs are. For instance, insights from Google Analytics, or perhaps you’ve commissioned some research on your audience to try and understand who they are what they need.

The second set of data is testing if a user’s need is met. This is all about validating that what you’ve created is doing what it’s supposed to, and that your users are able to do what they need to do on your site. And there are many user research methods you can use to do this.

But having data is all well and good, but if you’re not using it correctly, it’s worthless. So what do we do to make sure that we’re actually using the data?

Firstly, we encourage conversations with the subject matter experts. It’s talking to them and saying, “Here’s some data that we’ve got, this is what we think our users need. What is your insight on it?” and then making sure this all ties together.

We’re also quite a passionate bunch in our team and we like talking about this stuff, so if there’s data we find that’s helpful or interesting, then we’ll share it. Without this kind of practice taking place, it’s easy for data to get ignored, and that’s not where we want to be, because data has to shape what we’re creating.

2) Asking people what they want

You may think that one way to get around HiPPOs and create better UX would be to ask people about their experience on the website using an online survey.

However a long, ill-thought out questionnaire about user experience is going to cause problems and introduce an insane amount of inaccuracy. Particularly when it comes to digital and UX, people find it really hard to recall, even if it was just a minute ago, what it was like to use a site. They might remember one or two things, but it’s often inaccurate, and often it’s the last thing that happened, rather than the journey up to that point.

Some of the questions that people ask in surveys are often just too difficult to answer. You’ll no doubt be familiar with a pop-up survey, which you obviously just dismiss immediately. But not everybody dismisses them. Some people do actually stop to give some feedback. And then they answer questions like this…

“How well is the website organized?” Well it’s quite well organized!?? What does that even mean?

“Please rate the options available for navigating the site.” Navigation is a term you understand if you work in digital, but it’s not a phrase that an everyday visitor would use. It’s great to get feedback from real, normal people, outside the organization, but it’s quite hard.

How to deal with ‘asking people what they want’

The public was asked what do you want to call this lovely really expensive, really important boat?

Boaty McBoatface! Although we ended up with tons of publicity, we also ended up with a massive, brilliant boat being cheapened by its name, and any research coming off that boat would probably be tarnished.

So how do you actually avoid asking users what they want? Design something based on user needs. You’ve already got the data that’s performed your process for creating and designing a product. You have a web page, a tool, or a feature. You can then test that prototype or concept with actual users and watch what they do, and make changes based on any kind of task completion errors they’ve encountered. Then you can retest it if the problem’s catastrophic, or launch it into the real world and see what people do in the real environment.

At no point did you ask your users what they actually want, you just watched what they did.

3) Agile

Agile is a methodology typically used in IT projects, design and development, and within this method, people work in short bursts (sprints) which are typically one, two, or three weeks long. They focus on delivering a specific thing rather than working to a massive specification on what needs to be delivered, which can be 30 or 40 pages long. It means that multi-disciplinary teams break out of their silos and at the end of a two-week period, something will be delivered. It might be a bit of a prototype, it might be some work in code, it might be a new page design. Something gets delivered. And everybody’s doing it.

The problem is that within those two weeks, nobody tests with end users because they don’t think they can get users into that two-week sprint fast enough to do the tests. They think that it’s going to slow them down and they won’t have their assets ready in time, or that the assets might be low fidelity and are just one or two pages of a longer journey. As a result of that, people who are adopting agile often don’t test and release content, products and experiences that are sub-optimal to end users.

How to deal with ‘Agile’

This is a very simplified workflow that illustrates what would happen to a task as it goes through our various stages of development.

We make sure the user experience is involved at nearly every single stage of this. From the reviewing of data, to building the tests, to designing content. And then you’ve got final checks on the content we publish. So there’s lots of checks for people to see and consider. This really helps with stopping us finding problems too late.

So hopefully at this stage we’ll start to understand if we’re doing the right thing, or are we actually just ignoring a massive problem? And if there is a massive problem, then we can catch that as well. This is a very simplified example, and more complex tasks might take more sprints.

The other cool thing about being able to test like this, is it will constantly redefine what we know about our users. If we start off with a bunch of ideas about what their needs are and as we take the products through these workflows, we’ll learn what works and what doesn’t work. We’ll constantly add to our knowledge bank.

The key thing about agile is delivering a working thing for the user. If we’re not delivering something that works for the user, it can’t be done. I like this quote from Jon Innes, “The definition of done can only be determined by users.”

The second problem of agile is that it’s hard to find users fast enough.

Working with UserTesting, we’re able to recruit through their own participant panels. There are a lot of users we can call on to take our tests, and make sure that our products are working as they should. We’ve worked with UserTesting to make sure that when we send them out to people to take part, we know we’re getting the right people. So we could recruit really specifically for example, an undergraduate interested in CHIP science. Or an international student who wants to study a part-time master’s course in the UK. You can get even more and more detailed if you like, and although the more detailed you get, the longer participants will take to source, but with UserTesting it only took an extra day or two.