UX Research & User Testing

Upfront User Research & Prioritization

Paul Boag

Paul Boag

UX Research & User Testing

Check out a free preview of the full UX Research & User Testing course

The "Upfront User Research & Prioritization" Lesson is part of the full, UX Research & User Testing course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the importance of upfront research in a project and how to approach it. He explains that upfront research helps to avoid assumptions and misunderstandings, prevent disagreements among stakeholders, and ensure a solution that is aligned with user needs and the overall context. He also provides tips on conducting lightweight upfront research, such as consolidating existing research and information, running workshops, and conducting research as questions emerge. Additionally, Paul discusses the process of identifying and prioritizing target audiences based on business alignment, user impact, needs, growth potential, and feasibility.


Transcript from the "Upfront User Research & Prioritization" Lesson

>> Then let's talk about doing some upfront research, shall we? So yeah, like I've already said, upfront research is something that a lot of people do, they do some kind of discovery phase at the front of a project. And that's absolutely great and that's wonderful if you've got the resources and the time to do that, but it's not the only way of doing it.

So what I wanna share with you is some of the things you wanna know, how much you can strip it back to its bare bones, and how we can get again the most bang for our buck out of it. So how to approach upfront research, right? So considering the constraints that we're presuming we're working under around time and budget, it's important to have a clear plan of how to address any initial research you wanna do, right?

And it is a reasonable question to say, well, why can't I just skip upfront research entirely and just get going, right? That'd be super lean, and I said earlier that you don't even know what the questions you wanna ask when you start. So there is an argument to be made or maybe you could skip it and just get going and then do bits as you go along.

I actually, I can understand that and I've kind of tried that a few times, but I've missed doing at least something upfront. And I think there's kind of a few reasons for that, first of all is without user research, there can be a lot of assumptions and misunderstandings that cause chaos later.

Especially if you've got a group of people working on something, it's a bit different if it's just you, cuz you're all agreeing on the same thing, you are the decision maker etc. You know what you don't know and all of the rest of it, but once you start working in the team it can cause confusion.

If you don't have some kind of agreed understanding in terms of any assumptions or constraints that you're working within. The second is it can lead to disagreements, different stakeholders can envisage a very different thing, right? Even something which you think we'd all agree on, we're gonna have a carousel on the homepage, okay?

All of us will have a slightly different view of what that carousel will be, how it will work, what it will do, how it will behave on mobile, all of those kinds of things. So it's very easy for our understanding to diverse one another, but when you hear the phrase we're gonna have a carousel on the home page, you think everybody would agree on it, right?

And they won't cause issues, so it's quite important I think to do atleast some kind of upfront research and understanding. So that there is an agreed understanding where to go and maybe Carousel that's probably not a good example, but certainly around who you're trying to reach, right? Agreeing on audiences is agreeing on what those audiences what a need is a big one.

And then the final one is often going into it without any context can cause some real problems leading to poor solutions. So in particular, oftentimes an app or a website whatever is part of a broader journey, right? The user has done something before they've arrived on the website or use the app and they'll do something after to it.

And knowing that context and what's going on around the project is quite important in order to ensure that the solution you deliver is worthwhile. So all of that is to say it's worth doing a bit of user research upfront, it doesn't need to be massive, so what's the minimum we think we could get away with here, right?

If we really strip it back, what do we need to know before we start? Well, the first thing is who's your audience, right? Having a clear picture of who you're designing for what you're creating for is crucial to success. And not just for you to have a clear picture but all of the stakeholders in the project, absolutely crucial.

Second thing we really need to know is what do they need, what does this audience need? What are they trying to achieve and how are they gonna go about achieving it, right? Then the other thing we need to know is what's the overall experience at least to some extent, what brought somebody to this point.

And what will help them progress to the next step in their journey, and that one's often an overlooked one to be honest with you. We focus so blinkered in on the project that we're working on that we tend to forget what comes before and after. And then the other thing that I'm always looking for is where are they encountering friction?

So they're gonna be achieving this thing, whatever they want to achieve in some way, either with the existing version of the website or through another mechanism. So where are the pain points, where are things going wrong? We kinda need to understand that if we're gonna try and fix it for them, right?

But we can do all of that by keeping it really lightweight, that doesn't need to involve weeks of work, right? And I always try and make my discovery phases proportional to the project as a whole, right? So if you're creating a single landing page and you've got a no a day to do it.

My discovery [LAUGH] phase might be an hour at the beginning of the day or probably even less than that. If I'm doing a multimillion pound project, then I'll probably put a bit of effort into the discovery phase upfront and make sure I'm well prepared going in. So I normally look at about 10% of the overall of all project value, normally if I can get away with it, but if I can only get away with less then I'll do less, it's as simple as that.

You can achieve a huge amount just by consolidating what other existing research and information is available, right? Like I was saying earlier, there's often documentation knocking around, there's often existing user research knocking around, grabbing all of that and hoovering it up. I do a lot of these days cuz I'm lazy, of uploading PowerPoint presentations and PDFs and stuff to something like Claude, which is really good at analyzing documents.

And ask it to summarize them for me and I ask it questions about based on that, so I don't have to pour through a 300 slide deck [LAUGH] etc. So I cheat quite majorly, but it means that I can consolidate a lot of information very quickly, sometimes just a single workshop is enough, right?

So, if you work on smaller projects that's absolutely fine, then just do a kick-off workshop and ask some of these questions and dive into some of these issues in that workshop. Try and make sure there's people that have got answers to those fundamental questions we were talking about in the last section.

And that's often you can supplement any information you've got when you were looking at existing research and you can get the additional answers you need there. So for example, sometimes I'll run a workshop where we'll create a customer journey map or your personas or things like that and again, I'll cover those things in more detail later.

And then sometimes if there's nothing that stands out that I need to know at the beginning, there's nothing stopping me doing more research later as questions emerge. Again, don't feel you have to do this stuff just because that's what some article you read somewhere tells you to. And that applies to what I'm telling you as well by the way, just pick and choose what is relevant for you out of all this, cuz every situation, every project's different.

So, I mean, one of the big things is identifying your audience, and so this is one that I do really spend a little bit of time on, getting very clear in my head upfront. And the reason is you can't really serve everybody equally and this is the big mistake, if you try to appeal to everybody you end up appealing to nobody, okay?

And here's a great example of this that I was working on recently, I was working with the University of Florida in this case with the HR team there. And they have a website, and they were trying to present information about health plans and all this kind of stuff.

We don't have things like that in the UK but apparently it's important over here to have a health plan. So they were trying to present all of this information and they were trying to present it to everybody at the same time. So you had all these different audiences with different needs all accessing the same page.

So there were existing employees that were probably primarily interested in updating their health plan. There were new employees that just wanted to know what they were gonna get and in particular how to register for it. There were HR managers that were trying to help other people with their employee health plans.

And then there were people joining the company that wanted to know what their health plan was gonna be if they joined. All on one page and there was so many different audiences all fighting for attention. So really having a clear picture of who your audiences are, and most importantly how to prioritize those audiences is something that I try and flush out at the beginning of a project.

Because prioritization in particular can be really tricky, everybody will disagree over this, right? And so people just avoid coming to these conclusions, right? And then you don't know who you're working with, well, we have to appeal to everybody. Yeah all right, fine, but of all those people who do we appeal to most, right?

I believe in designing for somebody alienating nobody, that's the phrase that I use, okay? So how do we go about prioritizing our audiences and I do spend a little bit of time projects doing this because I know it will come back to bite me horribly if I don't.

Well, I kind of use different characteristics, first of all, I use business alignment. So prioritize groups directly contributing to key metrics within the organization, so the first question I will ask is what's your primary metric that you're trying to move here? Is it revenue market share, whatever, and I say, okay, which of your audience's most help with that?

So don't ask people to prioritize, right? No outright, I instead ask very specific questions that are yes no answers, because if you ask people to put things in priority order, then politics get involved, right? But if you just ask direct questions with factual answers, you kind of avoid that, so that's the first one I do, second one is user impact, right?

And I look at groups whose needs if met, would significantly enhance the overall user satisfaction and engagement, right? So I say okay, which groups have got needs they're not being met currently, and if we fix the problem would be really beneficial in terms of overall satisfaction? So these tend to be the most vocal groups, the largest groups, the groups are the biggest issues, right?

And so I get people to brainstorm those kinds of lists out of people. Then I talk about needs prioritising user groups for the most acute pain points some of them having the biggest difficulties. Especially if these difficulties are acting as a barrier for whatever the project's goal is so I get them to list a few of those as well.

Also look at things like growth potential, so I say which is there a market or a group of users that you're looking to grow? You want more business from those people, right? And then I ask about regulatory requirements, is there a particular group that you need to meet the needs of for example, people with with disabilities or veterans or whoever else.

And then finally, I consider feasibility, right? The practical aspects of reaching and engaging with each audience group. So I kind of discuss all of these things with the client, and with the stakeholders and then I go away and prioritize, right? And I tend not to tell anybody that I've prioritized in that way, because the minute I present back a prioritized list everybody starts arguing about it.

And that's the project stalled for two weeks [LAUGH] while they debate about this. But I then work on the presumption that this is the order we're looking on based on the the data we have. It's a bit of a kind of touchy-feely process, there's not hard and fast rules with it.

But having it clear at least in your mind who the priority audiences are will make your life lots easier, yeah, go for it.
>> Can you apply this to the previous example?
>> The previous example being.
>> The project you were working on at the University of Florida?

>> Yeah, so that was a good one, so can I apply it? Probably not very well, to be honest with you, what came out of that is that there really wasn't a strong priority in that situation. So employee retention was very important, so in other words, keeping existing employees happy and by extension them having good managerial support was a part of that.

So that's the important audience bringing on new staff members it was very important as well because they were under-resourced quite heavily as an institution. So all the audiences in that case, it was very hard to prioritize, so what we did is we ended up creating four separate sites.

So we actually segmented the audience and go, we can't serve all of these audiences on a single page, they've all got very different needs. So actually we need four health plan pages for example, one for each of the audiences, and that's how we had to resolve it in that situation.

So unfortunately that example doesn't prove everything I've just talked about here. But actually it's quite nice that you asked the question because it kind of shows sometimes you have to improvise [LAUGH] and sometimes you have to find a different way. Other times it does kind of shake itself out, so I do a lot of work with the universities and student recruitment is always a huge challenge things for a lot of universities.

But then certain types of students are a lot more valuable than others, so they tend to prefer postgraduate students to undergraduate students. They tend to prefer international students because they get paid more intuition, right? And so you can tease all of this out through conversations with them and ended up with a pretty good idea of what the priority order is, even if they can't come out and say it in black and white.

>> So there would be business alignment you're talking about.
>> Yeah, so that that would be heavily business alignment in that particular case. But also to be honest with international students, it's also user impact, user need, and growth potential as well. Because there's normally a big growth potential for getting more international students, they have a big impact on the institution.

And also they have profound needs because they've got to learn all this stuff about being in another country, etc. So really, they come out very highly from using these criteria.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now