{"id":250,"date":"2023-07-21T09:00:53","date_gmt":"2023-07-21T08:00:53","guid":{"rendered":"https:\/\/blogs.bath.ac.uk\/digital-content-and-development\/?p=250"},"modified":"2023-07-21T11:03:16","modified_gmt":"2023-07-21T10:03:16","slug":"how-were-approaching-user-research-in-2023","status":"publish","type":"post","link":"https:\/\/blogs.bath.ac.uk\/digital-content-and-development\/2023\/07\/21\/how-were-approaching-user-research-in-2023\/","title":{"rendered":"How we're approaching user research in 2023"},"content":{"rendered":"

Good user research is a foundation of good design, and thus a good product. It\u2019s important to do it and equally important to do it right, but for some reason it tends to be one of the biggest struggles for designers. It\u2019s time consuming, meticulous, involves lots of planning, and worst of all, doesn\u2019t involve colours and shapes! Everyone knows user research is important but really, is it any wonder that many designers would rather get on with things like\u2026designing stuff?<\/p>\n

Well good user research doesn\u2019t have to be all those negative sounding things. More accurately, it does, but it doesn\u2019t have to be as bad as they sound. What\u2019s more, even a little research really can help improve the user experience of your product. Read on to see how we do user research at the University of Bath.<\/p>\n

 <\/p>\n

What do we mean by user research?<\/h2>\n

OK, let\u2019s be clear about this from the start. What most people think of when they use the term \u2018user research\u2019 is user testing \u2013 getting a sample of your user base and interviewing, surveying, or otherwise observing them to learn things about how they use your products. The \u2018research\u2019 bit of that term can refer to other research-based activities that usually come under the umbrella of \u2018UX research\u2019. These activities are more about getting to know your users before you\u2019ve got a product for them to use. Things like creating user personas, empathy maps, competitor audits etc. Framed in terms of the design thinking process, UX research happens at the start, whereas user testing happens later on when you have something you can test.<\/p>\n

For the purpose of this post, we\u2019ll be talking about user testing rather than UX research.<\/p>\n

 <\/p>\n

User research at a university<\/h2>\n

In many ways, conducting user research at a university is no different than it would be at any other organisation or company. However, there are certain peculiarities about universities that means user research works a little differently. For one thing, working at an institution that itself conducts rigorous, world-changing scientific research does tend to put the comparatively simple research we do into perspective \u2013 it does sometimes make you feel like a toddler playing with a toy digger while around you the grown ups are operating real ones.<\/p>\n

Among the more positive aspects is the wealth of users that you have ready access to. This one is sure to make some seethe with jealousy \u2013 you see, in most companies that make digital products, their users are anonymous, far-removed, and difficult to access. On the Digital team, we work on a variety of products \u2013 some internal, some external - but arguably the main one is the University website itself. The main users of the website are prospective students looking to come and study at Bath. These former prospective students are now actual students here on campus in their thousands. If we need to carry out user testing, we can simply walk out on to campus and ask them!<\/p>\n

 <\/p>\n

So you must do user testing all the time right?<\/h2>\n

You would think that with this incredible well of users to draw from, we\u2019d be conducting testing all the time. In reality we've tended to have periods of time where we do lots of testing, making use of events like open days, and then periods with very little testing. There are lots of reasons for this including changes in the Digital team, prioritising other kind of work, etc...<\/p>\n

The pandemic didn't help either, cutting off our ability to carry out in-person testing and generally up-ending everybody's workflows.<\/p>\n

It's only in the last year or so that we\u2019ve been able to shift focus back to research and feature development that benefits from it. Thankfully, we\u2019re now making a concerted effort to get back to doing more user research on a more regular basis.<\/p>\n

 <\/p>\n

Our approach to testing<\/h2>\n

Preparation is key<\/h3>\n

We start out by thinking carefully about our research questions and really try to understand what it is we\u2019re trying to learn from doing user testing. This is easier said than done, but if you can devote some time to doing this at the start it well help you to ask the right questions of your participants, as well as inform the type of testing you carry out, and generally save time that you might otherwise waste by conducting research that doesn\u2019t tell you anything useful.<\/p>\n

Regardless of the type of questions, we always try to write them in a way that\u2019s open-ended and designed to give participants room to tell us what they really think. If you ask questions which are too direct, you\u2019re more likely to either lead the participant to a particular answer or get a short answer which doesn\u2019t tell you much beyond a simple \u2018yes\u2019 or \u2018no\u2019 \u2013 basically a data point. There are of course times when this is appropriate, but in general we\u2019re looking for a deeper understanding of how our products are used. In simple terms, short direct questions are useful if you want quantitative data, whereas open-ended questions are more useful if you want to understand what your participants really think or feel about your products.<\/p>\n

 <\/p>\n

A hybrid method<\/h3>\n

When it comes to the type of testing we select, it depends on what we\u2019re trying to find out. If we know a particular page or user flow isn\u2019t working well but we don\u2019t know why, we\u2019ll do a usability study. We\u2019ll do an A-B test if we want to know user preferences between a couple of variations. Recently, when introducing new features that could have radically different solutions, we\u2019ve found ourselves doing a hybrid of A-B testing and guerrilla testing. We take the basic methodology of A-B testing \u2013 presenting users with a smaller number of design variants and asking questions to find out their preferences \u2013 and streamline it so that each session only takes around 10 minutes. We do this in a venue with a lot of foot traffic, somewhere you\u2019re likely to have access to a lot of participants. This is where we borrow the guerrilla testing approach, where we try to get as many people to participate in a session as we can in a given time period. This may diverge a little from the usual way of doing either of these research methods, but we\u2019ve found that by using it, we tend to get the benefits of both methods -\u00a0 the focus of A-B testing, with the insights and larger sample size of guerrilla testing \u2013 with few downsides.<\/p>\n

 <\/p>\n

Remote testing<\/h3>\n

Of course, testing features related to the main website lends itself to guerrilla testing \u2013 if we use locations on our campus, full of students, chances are they\u2019ve all interacted with our website before. This isn\u2019t always the case with all our products. For example, when working on Typecase \u2013 our bespoke CMS platform \u2013 we need to use a more organised approach as its users are staff at the University who have busy schedules and can\u2019t just drop what they\u2019re doing at a moment\u2019s notice. To complicate matters further, many of them work remotely for at least some of their time. We\u2019ve had success carrying out tests over video call using platforms like Microsoft Teams or Zoom but they do come with drawbacks that are worth considering.<\/p>\n

You need to make sure you\u2019re organised before doing any kind of user testing, but it\u2019s even more important when doing it remotely because fixing anything that goes wrong is that much more difficult when you're not in the room. Don\u2019t underestimate that extra technological barrier between the tester and the participant. Some of the things you should consider:<\/p>\n