UX Design: Conducting research in the discovery phase | Jon Porton | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

UX Design: Conducting research in the discovery phase

teacher avatar Jon Porton, UX Researcher & Designer

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

11 Lessons (52m)
    • 1. Introduction

      1:27
    • 2. What is a UX discovery?

      5:00
    • 3. What are the benefits?

      5:52
    • 4. Who is involved in discovery?

      3:35
    • 5. Typical research outputs

      2:29
    • 6. Getting started

      8:35
    • 7. Recruiting users

      7:13
    • 8. Research methods

      7:13
    • 9. Bringing the research together

      4:20
    • 10. Sharing the findings

      5:18
    • 11. Conclusion

      0:40
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

10

Students

--

Projects

About This Class

The discovery phase is the starting point for any agile UX project. More and more organisations are adopting agile project management and UX research is vital in supporting this.

But what does this mean for the UX Researcher? In this class we'll explore what the discovery phase looks like, including:

  • What discovery really means
  • The reasons to conduct a discovery
  • What the discovery team looks like
  • Where to recruit users
  • The common research methods
  • ...and how to bring it all together and present back to the team

At the end of the class, you'll be able to confidently guide your organisation or client through their first discovery.

Skill level and audience

This is for anyone with a basic understanding of user research, or looking to understand what the discovery phase of an agile delivery project looks like.

Learning objectives:

  • Understand what the agile delivery discovery phase is
  • Learn how your role as the UX researcher fits into discovery
  • Sell the benefits of conducting a discovery to your organisation
  • Explore a variety of channels to recruit research participants
  • Discover the different research methods open to you
  • Use the supplied templates to create compelling research findings
  • Confidently communicate your research findings back to stakeholders

In UK government projects, all digital services are built this way and for good reason!

Some of the templates included

bf68eb49.png

Meet Your Teacher

Teacher Profile Image

Jon Porton

UX Researcher & Designer

Teacher

Hi! My name is Jon Porton. Glad to meet you. I’m a UX researcher/designer with over 30 years technical experience, the last 15 of which focused on UX. I transform products and services for private sector and government organisations.


I love the idea that all products and services are designed around real users needs. I’m a mentor for several junior researchers. I often share my experiences through talks within organisations and public events such as World IA day. I’ve written the occasional blog post and research paper as well. My reason for teaching? If my knowledge and experience can help others build better products, then it’s all worth it.


Clients describe me as a generalist. Someone who can come in and cover all bases and... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: Hi, Welcome to my class. My name's Jon Porton and I've been working in the field of UX for over 15 years. For the past few years, I've been conducting UX discoveries for both public and private sector organizations. I created this class because I'm really passionate about what a discovery provides to a project and an organization and how it's an integral part of any project where you look into either build a new product or redesign existing products and services. This course is primarily aimed at user researchers. But you could be anybody who's interested in the UX Discovery and you'll get something from this class. We're going to look at a number of topics. We'll look at what a UX discovery is. We'll look at the benefits a UX discovery can provide for your project and your organisation. And I'll give you loads of arguments that you can take to senior management to persuade them to conduct one. We'll look at how you plan for a UX discovery, who's involved. So what the team looks like, where you find users, what sorts of research that you'll conduct. So all the different types of research that's open to you, how you bring all of those findings together. And ultimately the best way to present it back to the team so that you create winning arguments for moving on to the next phase. I really hope that sounds exciting. I'm certainly excited to take this class. So let's get going. 2. What is a UX discovery?: So let's get started by looking at what a UX discovery is. The discovery phase is the starting point for any Agile project, It's a period of time where you need to find out as much as you can about the problem you are trying to solve by conducting research. Discoveries typically take four to eight weeks. Although I've worked on ones that are being shorter and longer. As a UX practitioner, you take this time to answer a number of questions. Who are our users? How do they use our products and services? What are their pain points? What do they need to achieve their goals? What improvements can we identify. What are the business requirements? And what business constraints do we need to factor. You'll answer these questions for a variety of research methods. And at the end of discovery, you have enough information to make an informed decision about what to do next. I should say at this point, if you are unfamiliar with the agile methodology, then don't worry, you don't need to be an expert on Agile to follow this class. If you are new to it, then I would encourage you to have a quick read up. But for now, you just need to know you should be starting your project with a discovery. Before moving on to the other phases, such as alpha and beta. As I said, the purposes of discovery is to find out more about the problem you are trying to solve. But what do we mean when we say problem to solve? The problem to solve is the reason you're all on the project. It's the thing you are looking to achieve. So let's have a look at some examples. You could be looking to replace an aging or unsupported website or Portal. Possibly change business processes because new laws or regulations might mean your business processes need to change. You might want to replace paper-based forms. You might have forms that already exist, but they need to be completed by hand and you want to replace them with digital versions. Or you could be looking to migrate to a new customer relationship management system because your current solution no longer meets the needs of the organization. And lastly, you could be looking to install new ticket kiosks in railway stations. Because your existing kiosks keep breaking down and you want to install new ones. These are just a few examples. But it really could be any project that would benefit from taking a bit of time and learning about the problem before trying to solve it. Just a quick word on these examples. The problem you start with might not be the problem you need to solve. So thinking about the last example on the list, installing new ticket machines. Well that that sounds more like a solution than a problem. It could be the after eight weeks of talking to rail passengers, you might discover that they no longer wanted to buy tickets from machines and prefer to buy online. And this is where discovery excels. It allows you to discover the facts and avoid costly mistakes later in the project, such as installing thousands of ticket machines that no one will use. Let's have a look at an example discovery. So imagine you want to change your existing website, at present it's hard to use and a headache for your internal teams to keep updated. In discovery, you will speak to users outside of the organization to find out how they use it and what they need from it. You'll also need to talk to internal users to better understand any needs they may have. For instance, to be able to update it quicker. You'll meet with internal stakeholders to gather, the business requirements and any limitations or constraints the organization might place when changing it, such as legal content that you must include or technology that you have to use. Once you have all of of that information, the task ahead of you will become clearer. And you'll be able to make an informed decision about what to do next. As I said previously, that might be to move to an Alpha phase and start building or changing things. Or decide that actually the problem you planned on solving is not a problem you really need to solve. That last point is really important, It's not unusual to get to the end and realize you don't need to change your existing website, just some parts of it. Or the key functionality is actually better served to users through an app. Finally, you might discover that the costs of proceeding far outweigh the benefits of making the changes. So finally, to reiterate, discovery is an opportunity to learn everything about the problem. You should not be attempting to solve it in discovery. For moving on, take a moment to think about any projects you've worked on previously. How user centered, where those projects did they deliver the intended value to the user and your organization? Could running a discovery have helped. Jot down some of the benefits using a discovery phase might have provided. If you are about to embark on your first project then ask yourself the same questions based on what you know about it now. If you're struggling to come up with the benefits for running a discovery, then you'll be pleased to know we're going to look at some of those in the next video. 3. What are the benefits?: I'm sure I don't need to tell you that one of the challenges with user a research is convincing stakeholders and clients of the benefits of doing it. If you're like me, then we can talk at length about the wonders of UX. But sadly, not everyone understands why we do what we do. Hopefully, you're taking this class because you've been asked to conduct a discovery. If not, then this section we'll cover the benefits of UX discoveries and give you some winning arguments if you're suggesting a discovery to your organization. Let's start by looking at some of the benefits to your organization or client. Gain a better understanding of the users. This is not just for your project, but for other parts of the organization as well. Why does this matter? Well, chances are you're not the only one talking to users on a daily basis. By understanding who they are and what they need, you'll be able to share this rounded view with other areas of the business. I've created personas that are used by marketing teams looking to create new materials. Policy teams look into create new content and customer support teams focusing on specific user groups to ensure they get the support they need. Reduce the cost of development rework. It's very easy to just decide what your user ones and build it only to end up discovering later down the line is not what they needed at all. A great example was a project I worked on where the organization had built an online data analysis tool. It took a year to build and cost hundreds of thousands of pounds. I was asked to perform a discovery to understand the impact of the tool on the user. The reality was that users simply used the most basic functions of the tool to download the data and used their own tools to perform the actual analysis. Had the organization performed research before building the tool, they could have saved a fortune and concentrated on building things that users actually needed. Understand support needs and reduce support costs. Without understanding the user. It's very easy to make decisions that result in more calls to the support lines, which result in longer wait times and possibly a need to take on more staff. Your users have a range of technical abilities and accessibility needs. Discoveries help you identify these needs and take steps to ensure all users can access and use your products and services. Identify improvement opportunities and risks. Discoveries are a great way to really dig into the detail with your external users and internal teams is not often an organization has the luxury or inclination to do that. You will naturally uncover insights across the wider user journey. This includes identifying improvements you can make, new opportunities to explore and risks you will otherwise missed. This isn't just limited to your project either. This is where internal stakeholders really start to take an interest in your work. You're uncovering insight that they can act upon as well. I've yet to conduct a discovery that hasn't either uncovered additional opportunities or highlighted big risks by making large changes to something. A few years ago, I was sat with a user talking about the impact of changing the technology behind an existing data supply service. As the session went on, it became clear that their product would no longer be able to access the data. And the whole thing would stop working. They told us they needed at least three months notice to adapt their system to work with our new system. Had it gone live without these changes, it would have affected over 300 thousand of their users and been catastrophic for their business. As you can imagine, they were extremely grateful that we taken the time to talk to them. Build or expand on existing relationships. Uses love being listened to. By fostering relationships with them. You not only help them understand what changes might be coming, but also make them feel valued and trusted by your organization. It is not uncommon for senior stakeholders in their organization to hear that their teams have been involved in research and provide positive feedback to their equivalents in your organization. Reputation. Any organization that listens to its users and can be seen to act on their feedback will be held in higher regard than organisations who don't, it's a simple byproduct of user-centered design. Those are just a few of the key benefits. Ultimately, the biggest benefit to your organization is that you understand your users. Have a clear view of their needs and can build something that really works for them. Before we move on, it's worth quickly talking about the arguments against running a discovery. Over the years, I've run into several barriers against doing them. We don't have time to do it. We already have great ideas of what to build. We know what our users want. We can't spare any resource. It's very easy to want to get straight into building something. Four to eight weeks seems a long time, especially when management wants something delivered. And you have a team of designers and developers chomping at the bit to get started. In my opinion, this is a sure-fire way to failure down the line. Sure, you will have something built in eight weeks, but will it be what users need? How can you be sure without speaking to them? Discoveries allow you the time to speak to a wide variety of users across all of your user groups. The opinion of one or two users over the years is not enough to make an informed decision that meets the needs of the many. I would argue that the cost of having to unpick a redesign and redevelop things later is a compelling argument for running a discovery. Now, you might have to strike a compromise with the CEO in this instance. Convince them that your time and that of a business analyst with a reduced discovery period is still better than no discovery. I've been in this situation myself. And whilst a two-week discovery is less than ideal, they always without fail, uncover issues that would have arisen later in the build process. 4. Who is involved in discovery?: I'm including this section as it is important to the success of the discovery that you understand where your role as the user experience expert fits into the team. What your team looks like in a discovery will vary. Discoveries are rarely one person event, but it largely depends on the budget and the size and type of problem you need to solve. The type of project will have a large bearing on the makeup of the team as well. Regardless, when you're sat in your first workshop, there will be some likely candidates you'll be working with will need to get involved. Let's have a look at what a discovery team for a digital project might look like. Any reasonably sized project will usually have a project manager tasked with keeping me on track and ensuring activities are completed when they need to be. This is the person that you will agree your research discovery task with. This often goes hand in hand with the product owner who usually has responsibility for the success or failure of the project, and will prioritise those tasks. One piece of advice here is the product owner will often have a relationship with users and therefore can have pre-existing opinions of what the user needs. You need to challenge their preconceptions. To get around this, have them attend research sessions to hear firsthand what the users are actually saying. That makes your job of playing back the findings easier as there will be no surprises for them. I find that their experience and intimate product knowledge make them an invaluable subject matter expert and can help you make sense of some of the findings. The business analyst is the role I work most closely with. I find it beneficial to agree who will do what in advance of any activities, as there is often quite a bit of overlap in yours and their role. I would suggest your expertise lies in teasing out the findings for research techniques and theirs in sweating the detail that comes from that. I quite often ask the BA to attend all of the interview sessions I conduct. When it works well, you'll become this super team of two who go through the discovery, absorbing all of the insight thrown at you from all parties, working together to compile and present it back in various formats at the end. The service designer role is relatively new on the scene and very common in UK government projects. They're tasked with worrying about the bigger picture of how the entire service hangs together. A good service designer champions the user and share similar goals and values with you. A UX designer might be brought in to start building a pattern library to support anything built later on, or to shadow the research team and create user journeys or similar. A content designer might be performing a content audit alongside your work and could be working with policy or other internal teams to prepare content in advance of building something. A performance analyst might be required to start looking at existing reporting, new reporting requirements. And most importantly, how success will be measured throughout the project. It's more common for technical architects and developers to start appearing towards the end of discovery. As I said previously, they should not be building anything in discovery. But you may have technical challenges that need to be explored at this point. Sponsors and senior stakeholders might offer opinion at this stage. but generally will be interested to see the outputs at the end of the discovery, which brings us onto our next video, where we'll look at some of the outputs that you should be looking to create during discovery. 5. Typical research outputs: Before we dive in, I want to talk about some of the outputs you might want to create during discovery. By outputs, I mean all of the materials and documents you will produce. By the end of the discovery period, you would have generated a wealth of research findings which will help to create these outputs. These will, of course, vary depending on your project. But I generally produce a base set of materials for all discoveries and any additional items that either the project calls for or the client requests. Let's quickly talk about the benefits some of these types of output provide. As we've talked about previously, the goal of discovery is to understand as much about the users and their needs as possible. Personas are a great place to start. They allow you to see, at a glance the different user groups you have and the characteristics that define those groups. The various mapping techniques such as journey and empathy maps really add the icing on the persona cake. In terms of showing the routes they take to achieve tasks and the challenges and issues they face along the way. Analytics reports and service blueprints help provide the backstage view, which adds an additional layer of detail to the research. Service blueprints are particularly useful for complementing the journey maps, providing a view of what's going on behind the scenes. For instance, when a user visits the website, they only see the things you want them to see, such as words and images. They don't see all of the tasks involved in display in that content, such as the teams creating the content and ensuring the website run smoothly, and all of the internal processes that make it happen. Service blueprint shows all of that detail, which is essential if you need to replace all of the elements required to make your new website work. Creating the blueprint is rarely the use of researcher's responsibility, but you will input into it when highlighting all of the external user touch points. As you proceed through discovery, you'll generate mountains of research notes which you need to write up and bring together in one place. You will draw out all of the user stories to show the user needs and bring all of the findings together into a digestible format you can present back to the team. Lastly, any research you didn't get time to do or were unable to do during discovery, should be captured in a research debt report. I find that this report is a great reference for identifying potential knowledge gaps and for later phases of the project when you can revisit the activities and cross some of them off your list. 6. Getting started: So where do you actually begin with the discovery? The first course of action is to get the team together and workshop the discovery. This is the time to agree what the goal of the discovery is and what it is not. Determine the problem you need to solve. This is the point to challenge any existing assumptions and the agree what the problem is and what it is not. The problem should not be based around a technology or a solution. For instance, remember the example of installing new ticket kiosks in railway stations. In this session, you should challenge that. That solution might need to be reframed to say, how can we make it easier for people to travel on our trains. Agree tasks amongst the team. This may seem obvious, but this might be the first discovery for some of the team. So it's key that you agree who is doing what and when. Determine the ways of working. For my experience, not defining the ways of working is a common mistake. And it's really important you all work together to ensure a cohesive discovery. Agree next steps. Before starting the discovery, you'll likely need to have several more meetings. For instance, you might have an affinity mapping session to determine what you already know about the problem. You will definitely need to have at least one research workshop to specifically discuss the user research tasks. For the user research workshop, I ensure that the team are in attendance along with any relevant internal stakeholders. Generally, the people in the room know more about the organization than I do, and their input is often invaluable. There are a number of things that I aim to achieve in this workshop. Brainstorm the types of research questions you'll be asking. These are the questions and topics you will base your research around. Your stakeholders might have never spoken to a user. So it's a good opportunity to see if they have any burning questions or things they've always wanted to know. Discover any existing research. It's often useful to review any previous research, analytics and reporting related to the problem. This is often referred to as armchair research and experts get a bit sniffy about relying on this. I personally find this quite useful in gaining an understanding of the project as it helps give hints as to where to begin. For instance, if you're looking to replace an existing website, then web analytics is great for understanding the volume of users that might make up your audience. Likewise, I look at previous research to get an idea of where they found users and what they learned. Establish the research budget. You may have a good view of this already, but I always cover this to ensure the person with the money understands everything we might do in the discovery. For instance, is there budget for travel, hotels or room hire for visits to users. Can we pay incentives to users to encourage them to participate? Is budgets available for UX tools if we need them. This helps to plan the research techniques and realistic activities at your disposal. Determine research tools available. If you want to run surveys, then does the organization already have this capability? Do they have video conferencing facilities that you can use? Is there any budget to buy these tools if they don't already have them. Get leads and ideas for reaching users. Do any other parts of the organization contact users and how do they do it? Can they recommend routes for reaching users such as social media or trade bodies? Do they have existing databases of users. Who do they recommend you speak to within the organization. What teams will be affected by what you do? Establish any existing privacy policies the organization might have. What does the GDPR compliance look like if you're in the UK? Do they have specific privacy policies for user research that might be covered in existing terms and conditions. Are there consent forms or existing legal content that you can use? If the organization has never researched with users, then you need to establish these roles before you begin your research. Decide who will attend research sessions. It's a well-worn phrase. That UX is a team sport, but it's very true. I tried to encourage everybody in the team to attend at least one research session. Confirm what are acceptable output formats for the findings. Will you be using in user stories such as, as a, I need, so that or something else like Jobs to be Done, for instance. How did the team want to see the findings? Simple slide decks or formal write-ups? What are they expecting from you at the end of all of this. If they need a 120 page report, then you need to know this now. Once the workshop is complete, you will need to start planning your research activities. The first thing I do is create a research plan. This will help you plan your workload and will provide your project manager or scrum master with a clear view of what you intend to do and when. This is particularly useful if it's their first time working with the user researcher. The plan should detail some or all of the following. The research goal. This is the one main goal to help meet the discovery goal. So in our previous example, this might be something like conduct research to understand how people want to buy train tickets from us. Additional research goals. These are slightly more detailed goals that count towards meeting the overall discovery research go. These could be things such as create personas, identify accessibility needs, or understand the needs of our most novice users. Methodologies. This is just a quick outline of the types of activities and the methodology you plan to follow when performing them. Rough interview session plan. Sometimes called an interview or discussion guide. This is the framework of questions and topics you will follow during your research interviews. I like to capture the high-level elements of this in the plan so that all parties know what we're likely to be talking to the users about. Recruitment plan. Try to list all of the routes you will use to recruit users. I like to set some targets on the number of users I want to reach. Until you start discovering new user groups, that is hard to do, but I do find it's good to have a goal. Include a timeline. It's helpful to produce a timeline for when you plan to perform your research activities. I like having a simple view of the next number of weeks or sprints so that I can easily see if I'm on track. Statement of delivery. Finally, I list all of the things I plan to deliver by the end of the project. Once the plans is agreed, you should move on to creating your interview guide. As a user researcher, you likely have created these before. So I'll just recap what this is and how I create mine. As I mentioned previously, this document acts as a guide for you to use during your interviews. My one covers my introduction script where I explain about the purpose of the research to the participant. Along with any important consent and privacy points I want to highlight, such as what happens to the findings and any video or audio recordings I make. It shows the topics I wanted to cover with them. And the time I will allocate to each of these topics, I will often create a few different versions of this document to suit the users I'm speaking to. For instance, having different questions for existing users to those you might ask to potential new users. I also create a guide for internal stakeholder interviews. My advice in this area would be to create a guide that works for you. You're the one conducting the interviews. You need to be really comfortable with the way that it flows. Don't get too specific with your questions. After you first start interviews in discovery, you will discover that users start talking about things you hadn't planned for. Keep your questions at the topic level and very open-ended, rather than very detailed and specific to begin with. You can then adapt the guide as common themes arise. Towards the end of discovery you might find that there are areas you want more insight into. It's fine to adapt your guide to pay more attention to these areas. With all of this done, our next task should be recruiting users to talk to you. And we'll cover that in the next lesson. 7. Recruiting users: In my experience, recruiting users is by far the hardest part of the job and one of the most time-consuming aspects of discovery, I strongly suggest starting your recruitment drive as soon as possible. It takes time to find users and arrange when and where you're going to speak to them. The sooner you start, the better. You don't want to be four weeks into discovery having not spoken to a single user. The other tricky part is getting users to agree to help. Your goal is to basically encourage people outside of your organization to give up their time to talk to you about something that may or may not be of importance to them. I find the ease in which you do this largely depends on the type of organization and the types of users you need to talk to. If you want to talk to members of the public, they we usually require something in return, such as an incentive in the form of money or vouchers. For business to business or government projects, It may be you can persuade them to give up their time willingly by explaining your trying to make their lives easier in the long run, by improving their experience as a result of their feedback. Here is the blueprint I follow to reach users outside of the organisation. Contact existing databases of users. If your organization has a database of users, then this is your starting point. Hopefully there's a decent amount of information about each user, which will allow you to target a broad section of different characteristics. To start with, you should determine whether you have permission to contact them. Speak to whoever looks after the privacy of your customers to begin with. Explore reaching users via an existing website or service. This means adding requests for help on relevant webpages. Add a link to a recruitment survey where they can sign up to help. I'll cover this in more detail later on. Ask teams in your organization. Ask them to introduce you to their contacts. This might include policy teams that speak to senior stakeholders in other organizations, or a customer engagement team who conduct market research. If you're marketing team send email newsletters, then try to get a message added to that. In the user research workshop I talked about in the last video you will hopefully have identified all of these teams. Ask your customer services or call centre team. Without fail I do this in every project I work on. The customer support team speak to all manner of users, mostly to give support or resolve issues. Give them a few lines to say to encourage users to sign up and have them incorporate it into their process. Social media. If your organization has a social media presence, then messaging through this can be very effective. Trade bodies and other institutions. If your organization is a member of, or works with, a trade body, then reach out to them to see if they will canvas their members for volunteers. They will often have their own newsletters and be happy to put a message in there for you. Use a recruitment company. There are plenty of companies out there who can find you users. This is always a hot topic in UX circles. Some are good, some less so. But ultimately, it depends on how well you brief them and how niche the user types you're looking for. If you want users of a very specific product, then you might be better off recruiting them yourself. On the street, on your doorstep. If you're looking to speak to the general public, then consider pop-up research out in the real-world. Thinking back to the kiosk example, you can set up at a train station and stop passers-by. You might have users in visiting you to use your products and services. For instance, if it's library or a bank. User panels. You can find users via online panels where you pay to access a specific number of users. I find the value in these varies depending on the type of user you want to reach. Personally, I try to create my own panel of users during discovery. This can make recruitment in later phases far easier when you have your own list of potential participants. How do I create my own panel of users? As I mentioned earlier, I will often produce a survey to help recruit users. This is a very short survey designed to capture some basic information about the user and establish their willingness to participate in research sessions. I will often use this survey to start forming some basic personas if they're required. By asking the right questions, you can form some basic groupings of users. You can also drive users to the survey from some of the other recruitment methods I mentioned previously, such as on your website, through social media pages, or asking a trade body to include the link in their newsletter. From these responses, I can then screen the users and determine who would be most beneficial to conduct user research with. If you're lucky, you will end up with hundreds of responses. And you can use the sample to conduct research all the way through discovery. It's quite easy to focus on the external users and forget that you may have users within your organization. For instance, if you're building a brand new website and there are staff who update the website via content management system, then you need to talk to them. They'll have needs that you absolutely should factor. Likewise, you'll want to recruit and speak to other stakeholders around the business who may have opinions or insight that you need to capture. As I covered in the previous lesson, the easiest way to reach these users is by identifying them in the user research workshop. Also, if you have an intranet or company newsletter, then try those routes as well. You may be wondering how many users you should see during discovery. This is possibly the most contentious issue in research. For discovery, this would depend on a number of factors, such as the size of the user base. Length of discovery phase. Variety of user groups that you have, and any budget constraints that you may face. I personally aim to talk to a minimum of 30 to 40 users as a starting point. All discoveries vary and it really depends on when you start to hear the same things over and over again. When I reach that point, I try to wide my net of types of users to talk to talk to and ask myself a number of questions. Have I spoken to users in specific demographics? Have I observed a good mix of technical competencies? For instance, power users or complete novices. Was there one user I spoke to who I think I should try to find more of. Have I spoken to users with accessibility needs? You need to be really confident you've seen a wide range of user types and a good representation of their differing needs. Don't beat yourself up if you haven't spoken to hundreds of users. For me, speaking to any is a great start. Products and services are being built every day without any consideration for the user. The facts you're attempting to incorporate user-centered design should be applauded. One final point on recruitment, your aim is to speak to a representation of all of the user types. Be careful that you don't introduce bias into your research by only recruiting through one particular avenue. For moving on, take a moment to think about the recruitment channels open to you. If you're likely to be recruiting users over many projects for the same organization, then consider starting a log of research avenues of your own. 8. Research methods: You want to be as thorough as possible with your research, which means being flexible in the different methods you employ. Some of these will depend on your user base and where they are in relation to your location. Others down to budget and time constraints. Again, I would imagine as a UX practitioner, a lot of these will be familiar to you. But let's take a quick look at some of them. Contextual interviews. Visiting the user in the environment where they would be using your product or service is one of the most useful activities in discovery research. Being able to observe the way they go about achieving tasks allows you to see firsthand their real behaviors rather than relying on them describing how they think they do something. In my experience, they rarely match up. If I've arranged to visit a user, I will often encourage them to ask relevant colleagues to talk to me in separate sessions. I worked on a discovery once where I visited an airline. I explained in advance our aims of the research. And they arranged a full day of interviews with different types of users across the organization. That doesn't always happen. But it's worth seeing if it's an option, Stakeholder interviews. it's crucial you speak to internal stakeholders. The business analyst and I will usually conduct these sessions together, often with the product owner in tow. You'll hear about their needs, concerns, and internal projects that might affect yours. These sessions will help uncover all of the touchpoints we talked about in the service blueprint, such as the flow of data, interaction with external users and much more. It will also uncover any constraints you might face. Remote interviews. These play an integral part in my plans. What you lose in having the context provided with site visits you make up for by being able to do large volumes of them, relatively easy and at low cost. I usually have a mix of 30 minutes to one hour sessions depending on the type of users and what I want out of the sessions. I tried to use screen-sharing to achieve the observed elements of the interviews where possible. Surveys. As I said previously, I don't like to run large or complex surveys early in the project until I know more about what I need to ask. As you progress through discovery, you might uncover specific topics you want to explore in more detail, or validate with larger sample sizes. Surveys provide a great way to get lots of quantitative data. Diary studies. These are great if you can get the participant to commit to complete in them and you have the time in discovery to use them. To get going, I have a brief meeting with the user to ensure they understand the commitment required. I explain what I need and establish their preferred method for capturing the data either online or via paper-based templates. It needs to be as easy as possible for them. I will also regularly check in with them to see how it's going. Design testing. Sometimes you will start out talking to users and they will start to describe him what they need, but struggle to articulate it. If there are competitor products or previously design prototypes, then I might use these to encourage conversation. Don't perform usability testing at this stage. I do competitive testing in later phases. I just have them use it and talk through what they are seeing. As an example, I worked on a discovery for a statistical website. Previously, they had developed a working prototype which used green arrows to show when figures have gone up and red arrows when figures have gone down. We took this to users and they immediately flagged that red arrows could be hugely misleading. For instance, when the unemployment rate goes down, that's actually a good thing but the red arrow implied otherwise. Competitor analysis. It's useful to understand how competitors do things. Not just your direct competitors, but indirect competitors in organizations as well. In government circles, we will often go and talk to other parts of government where their products and services might overlap the thing that we're looking at, or the problem looks similar. You might discover improvements such as sharing functionality or reducing the need for the user to perform the same task on two different services. Analytics and reporting. If you have existing web analytics or statistical reports, then count these into your research. If you're replacing an existing website, take a look at data such as visitor numbers, popular and unpopular content, and key paths for your website. As an example, I will often look at customer support logs to see what the common issues being raised by users are. In addition to this, I will always without fail listen in on support calls. I tried to spend a day sitting with various different support team members and find it really helps give me a flavor of the user types. The support team staff speak to users every day and hear the same things over and over again. So they're one of the first places I start. A key activity I include in my discovery plan is a pause and review session. I usually schedule this for around halfway through to discovery, sometimes earlier if research is not going well. This session has three main objectives. Review the findings. As a team, we meet to review the findings thus far. It gives everyone an opportunity to discuss any concerns around the topics coming out of the research sessions. This will allow you to adapt your research plan or focus down on specific topics you hadn't previously considered. It's not uncommon to hear about issues not related to your problem that you feel the organization should hear about now, rather than in eight weeks time when discovery is complete. Review recruitment. If recruitment is not going well, this is a good chance to create a new plan and review whether you're doing everything you can to reach users. You might need to enlist the help of the team to explore new recruitment avenues. If you're several weeks along and you've only spoken to a handful of users, then you might need to ask for an extension to the discovery now, rather than when it's too late. Raise risks or concerns. it's better to flag any issues now rather than a week before the end of discovery. And it gives you an opportunity to keep the discovery on track. Trust me, your project manager will thank you for it. One last piece of advice on this subject. As the weeks pass by your possibly encounter demands from stakeholders to speed things up. For instance, this could be because an existing website is failing and causing embarrassment, or even worse, a loss of revenue. Sometimes you can't help but get ahead of yourself. I've worked on discoveries where we've run design sprints towards the end of the discovery period, resulting in showing paper prototypes and wireframes to users. I've also run card sorts and tree tests to better understand potential information architectures, in advance of building something. My advice is to embrace this and try to ensure that decisions being made are based on real user needs rather than wants. Research from these activities all helps towards making the right decisions going forward. 9. Bringing the research together: Once all of your research is complete, you'll need to write it all up and get ready to present back to the stakeholders. How and when you start bringing your research findings together will depend on the length of the discovery and the activities you performed. Some of the outputs I produce come earlier in discovery, but most of them towards the end, once I've concluded the research. I tried to give myself the last week or two of discovery and bring all of the research together and workshop the findings with the team in preparation for presenting back. As a rough guide, I tend to create my outputs in what I think is a fairly natural order. As we've covered previously, I start with a recruitment survey to get volunteers. This provides me with my panel of users to research with. Once the survey is complete, I will perform some analysis on the data to get some very rough persona groupings. I will either perform manual analysis to do this or use a statistical methods such as Multiple Correspondence Analysis or MCA for short. If you're interested in how MCA works, I've included a link to an excellent explanation written by Dr. Stu Church who introduced me to this method. With the analysis complete, I will then recruit a sample of users for each of the groupings. Around this time, I will also start reviewing any existing analytics reports or other data that helps add some background to the problem. And I use this to produce my own analysis. I will also start arranging interviews at this point. As I conduct each interview, I will write up the session into a tab in a central spreadsheet that I created for the project. I will transfer notes taken by any of the observers into the same spreadsheet along with any diary studies I have received back from the users. I prefer this to having lots of separate session write-ups. And this becomes my go-to place to extract all of the issues, pain points, needs, observations and other details that will make up my additional outputs. I've added a link to a sample findings log in the projects and resources section of this class. As we meet users and internal stakeholders, the user journeys, service blueprint and empathy maps will begin to take shape. Once all of the research interviews are complete, I will get all of the interview observers together and we'll perform affinity mapping to agree the key findings. This also includes finalising in the service blueprints, journey and empathy maps. I try to ensure we do this as a team. However, it's not uncommon to go away and work on some of these outputs separately and then meet again regularly to review and agree them. During this stage, I will work on improving the original personas I created earlier in discovery. Adding all of the qualitative research captured during the research activities. This allows me to challenge those initial groupings and expand upon them, adding more detail and making them more robust and reflective of the users we met. At this point, you have a really good picture in your head of the people you've spoken to and whether they fit into your original groups. With better to find persona grapes, I can then pull out the user stories for these groups, which will help inform the approach to take for the target audience. I personally use a tool called Trello to capture these. It's a great way of grouping them by persona type and adding detail behind each of the stories. Once done, the stories remain here as a record of all of the user stories that came out of discovery. In an agile world, these stories will end up in a tool such as DevOps or Jira, or possibly on index cards on a wall somewhere if you're going old school. And this is where your designers and developers will start in the alpha phase. The last output I create is the findings presentation, which I use to present back to the stakeholders. By this point, you should be feeling really confident that you can show you understand the users, can talk about their needs and how all of this marries with the organization's needs. You'll know that discovery is complete when you have a clear view of your next steps. For instance, you have identified something viable and tangible to solve the problem and that it's cost effective to proceed to the next phase. Assuming you've reached that point, it's onto the playback session, and we'll cover that in the next lesson. 10. Sharing the findings: Finally, you will reach the point where you can share your research. It's your opportunity to lay out all of the findings in front of the team and stakeholders and agree the way forward. This is usually done in the form of research playback at the end of discovery, or in the weeks after. There is a lot of information that comes out of discovery and not everyone in the room will be interested in the detail. I recommend basing your research findings around an easy to follow slide deck that contain some or all of the following. Always include a reminder of the problem that you're trying to solve. Have an executive summary key findings section. This details the top-level findings in terms of what came out of the discovery. Who you saw and what you did. Stakeholders can be quite skeptical of the findings. So it's really important to talk about the types and volume of users you spoke to. Perhaps include the organisations they work for and the activities you did with them. Anything that adds any credibility to the findings? Personas. If your goal was to produce personas or to challenge existing ones, then show them here and clearly demonstrate how the groupings differ. Pain points. Talk around the pain points you've uncovered and the barriers the users face. I find it helps to talk about some of the needs you've uncovered and how these tie into the personas. For instance, that the current solution meets the needs of persona group A, but completely fails groups B and C. What needs to happen. These are high-level actions that need to happen along with ideas on how to address them. For instance, if I discovered the novice users require more support, I will say just that. I won't try to come up with detailed solutions as to how to achieve that. That's really for the team as a whole to decide later. Improvements and opportunities. This is where you highlight any improvements and opportunities you've identified. Not just related to the problem, but also call out additional areas that you have uncovered during research. From experience, I find senior stakeholders get quite excited at the idea of telling other areas of the business about some juicy insight you've uncovered. Selected comments. I usually include some of the actual comments users have made. A don't name names, but often detail things like job titles if relevant. You can also share audio and video highlights if that helps. But I try to keep this to a minimum at this stage of voice, it makes the session way too long. Next steps. Here, you should highlight what further research needs to happen along with suggested next steps. I don't try to offer solutions or a list of things I think should happen though. You really need to agree that as a team as well. It's very easy to spend the entire playback session reviewing the presentation and showing off all the great work you've done. I'll be honest, I'm as guilty as anyone of doing this, and from experience of discovered that this isn't the best way to get the information across the stakeholders. I use slide deck as a guide for the playback session and order of the slides from high-level findings I need to cover, through to more detail in later slides. That way people can takeaway and read the extra detail if they want to. Try to focus on the session being more of a two-way dialogue. Include polls and ask questions to the audience at various stages of the session. As an example, when you talk for your persona types, you could ask them what groups you should be prioritizing. When you talk through the pain points have a poll that asks which ones they think would be hardest to address. At the end of the session I will usually conclude with a last poll on what the room thinks are the priorities, now that they know the findings. This makes the session far more engaging compared to just talking at them for an hour. Before we conclude, I just wanted to talk quickly about working in the open. If you're not familiar with the term, then working in the open is a great way to expose the work that you're doing with everyone in your organization. You can openly share your discovery findings with other parts of the organisation and help them feel included in the project. I bet when you spoke to your customer support team at the start of discovery, they probably didn't expect you to come back to them weeks later and tell them what you found out and what you're doing next. Working in the open provides an opportunity for ongoing discussion and feedback. It also means everyone is aware of what's going on and it can highlight any barriers before they reached and ensure change is not a surprise when it happens. In the UK, government projects work in the open with their public users, as well as their colleagues in other government circles. If your organisation allows this, then I'd recommend it as a great way to make your users feel more included and give them prior knowledge of changes to products and services. Of course, you don't want to expose your next big idea to a competitor, so you will need to be careful about what you share. I have seen this done well in the private sector, where they share research with user groups through user forums, and encouraged further feedback and involvement in future research. I've included a link to the Government Digital Service team blog. If you've never seen this before, then have a read. It's a great resource for seeing how UK government services are built and getting ideas for different research techniques. It's really good example of how to work in the open. 11. Conclusion: Congratulations on completing this class. I really hope that you enjoyed it and that you feel excited and confident to go out there and start discovering for yourself. Before you go, I have a quick favor to ask. I'd loved to hear your own discovery stories, so please share them on this workspace. It could be anything about the challenges that you faced or possibly different approaches that you took to the ones that I've outlined here. Good or bad, your stories will really help bring this topic alive for other students. Lastly, if you have any questions or feedback on this class, then please let me know and I'll endeavor to answer as many as I can. That's it! Thank you so much for taking this class and I really hope to see you again soon.