Need user insights? Get the Playbook 📕
The job is yours. User Experience Researcher is the title (or similar — Customer Experience Specialist, Design Strategist, Consumer Insight Manager, Service Designer, etc.). It's time to roll up your sleeves and get to work determining how to run UX research projects of your own. Whether those project are well-defined... or not... is another story. Thankfully, we've developed a UXR Project Brief framework that makes quick work of straightening the ins/outs/odds/ends of a new engagement. So, before you jump directly into research, let's discuss the importance of a UX research Project Brief.
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference 👇 guide — free to download!
Get the Playbook
Learn More
When you're done with this article, you'll surely be ready for next steps such as figuring out how to write UX Research Tasks for user studies. Following that, you'll be empowered to decide how to analyze UXR data for insights from the newly generated user data. As it turns out, all of these follow-on phases benefit from a sound Project Brief. That's because the brief will provide the business context, measurement plans, and much-needed direction for your UXR activities. Better yet, it's not hard or time-intensive to create one.
Follow us on our journey of sense-making. We'll start with making sense of our own project and purpose, so that we can succeed in later stages. In this article, we'll touch on what's a UXR Project Brief, and why it's important to create one for your work. Importantly, we'll break down the 10 components that constitute a useful Project Brief, and share a brief template you can use to kickstart your own UXR projects.
Time's a-ticking 🕒, so let's begin.
project framework consumer insights research brief project management user experience process research archive background context project goals research measurement user screening criteria research deliverables brief templates
A UX research Project Brief is a 1–2 page word document that outlines the relevant details to the UXR work-to-be-done — enhancing clarity and accountability.
Clarity matters, in that you'll have a written artifact that anyone can reference. Whether it's the UXRr, manager, product partners, external consultants, or other stakeholder, the reader will be able to clearly see what the project premise is all about. At a high level, the value comes from putting stakes in the ground, to be easily referenced by all. Without this, your brain 🧠 is the only vessel for the project parameters. And unfortunately, we all have good days and bad days, which can make things fuzzy when basic information is required at some particular moment.
Accountability matters, in that the goal posts are no longer in flux. Within the UXR Project Brief, one will outline the metrics, goal, objectives, activities, etc. These all establish guardrails for the project. Guardrails are good, because you know what you're signing up to deliver. And the researcher can gain buy-in and alignment from stakeholders on key research questions, deliverables, timing, etc. Without this, projects tend to change or morph over time, and there can be difficulty closing them out on time and on budget.
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference 👇 guide — free to download!
Get the Playbook
Learn More
We've covered clarity and accountability as a valuable by-product of writing UXR Project Briefs. Additionally, Project Briefs are important for 3 reasons — they're are great place to start, they're an excellent source of reference during the project, and they're a useful archive / transitionary tool at the end.
First, UXR Project Briefs are the best place to start when details and direction is ambiguous. As often is the case during the early stages of a new engagement, complete information is lacking. Everything is new... stakeholders, product lines, context, users, touchpoints, and more. The intrinsic value of UXR is that we make sense of difficult opportunity spaces. We help drive clarity and insight into the user experience for the business. That isn't always easy or straightforward. So, it's best to begin by leveraging a Project Brief to nail 🔨 down the specifics with stakeholders. Use it as a conversation tool. Share it with others. Fill in the gaps as you learn more. The Project Brief is your first deliverable because it's valuable in itself for someone to write down all the foundational stuff.
Second, Project Briefs are a simple way to keep you on track during the throws of a project. UX research can be quite complex during the middle of a project 🚧. You're trying to schedule interviews, meet with users directly, design outputs that make sense of intangible concepts, establish new meaning through insight themes for the organization, and more. All of this requires a considerable amount of mental faculties. Therefore, not having to remember where you're headed, why, and how is helpful to free up additional brain cells. The Project Brief contains all the basics, easily referenceable, while enabling the researcher to focus on forward progress.
Third, Project Briefs are useful tools for cataloguing past projects, with associated details and deliverables. Since project come and go at a fast clip, it can be hard to recall all the inputs/outputs over time 🕦. Who was involved, what was the goal, how did we approach the problem, what were the outputs, and more are all embedded in the brief. As you close out projects, you can put direct links to the key deliverables in the Project Brief. Or you can outline further question area necessary to explore in further research studies. Whether you're the one looking to remember what a project was all about (and associated outcomes), or there's interest by an internal teammate, external consultant, new manager, etc. the Project Brief will show the way.
In summary, UXR Project Briefs are important because they're the best place to start, a solid point of reference, and reliable spot for archiving.
Just like the SATs, you get points just for signing a name. Turns out that's a myth, but for Project Briefs, names still count. You'll be calling this line of work by it's project name forever after. You'll reference it verbally in meetings, report to managers within emails, visualize it on your team's project list, and more. It takes all of ~2 minutes to develop a proper project name. Those are 2 minutes well spent.
The purpose of this section is to sum the entire body of work into a 3–5 word title, so it can be clearly referenced. So, summarize wisely. It shouldn't be too vague. It ought not be too long. It doesn't have to be catchy. It just has to be succinct, yet descriptive. A good test will be how it reads among the rest of your UXR projects. You've nailed it when it relays the essence of the project at first glance 👀, and isn't easily confused with other lines of work.
Tips for titling a good project name: Begin with the the product's name that's in focus, adjoined by the main research method underway. For example: "Ads Manager Cognitive Testing", "Completion Meter Evaluative Testing", "Ads Incubator Focus Groups", etc. Also, append versioning, such as V1, V2, etc. Both help to keep UXR projects tightly framed and iterative in nature.
Return to overview ⤴UXR projects come from your relationship with a breadth of internal stakeholders. PMs, PDs, DS, Eng, Ops, UXRs, and others are your partners when it comes to doing meaningful work in any organization. The least you can do is list the names of your collaborators in the Project Brief. Call it name dropping, if you like. Adding the names of key stakeholders tied to your UXR project is a vital 2nd step.
The purpose of this section is to list everyone tied to the project, so that all disciplines are properly accounted. Again, this only takes ~2 minutes to list who's who (in the zoo). Pull up your internal org chart, find your stakeholders, copy their names, paste their titles, separate with commas, and move on to step 3. It'll benefit anyone reading your document, as well as the future you, who's bound to forget 🤷 this level of project detail.
Tips for listing stakeholders: Create hyperlinks, abbreviate last names, use parenthesis to indicate roles, and include yourself. Create clickable hyperlinks to each stakeholders internal bio, whether that's the org chart, their workplace homepage, etc. Doing so saves time for yourself and others when later searching. Abbreviate last names, because they're often easy to misspell, and first names with a single last name letter are specific enough within a workforce. Example: Matt K., Paul S., Tom T. Use parenthesis to indicate shorthand titles. Example: Matt K. (PM), Paul S. (UXR), Tom T. (PD). This gives an at-a-glance understanding of who's in charge of what. Lastly, don't forget to include yourself. You're an important part of this project!
Return to overview ⤴Oh context... it's so very important. Especially, in a fast-changing business environment. On every UXR project you're expected to learn a lot of new terms and related details. The business context section is where you can get it all out of your head (and the heads of others), so you can soon focus on making progress on the actual research.
The purpose of this section is to extract/discuss the product background with others, so that you can identify the most important parts to internalize. Your notes 📝 from early stakeholder meetings will most often populate the business context section. What's the product, who's the user, why are we working on this, where have previous efforts led us, etc. You'll fill in all the foundational context about the work at hand.
Tips for documenting relevant business context: Utilize 3 paragraphs to outline the context — past, present, and future. Write down what's gone on with the product historically, such as wins, losses, challenges, stages of evolution, etc. Then, document where we're at today, including what's the angst, why we need to do work, what are the main drivers, etc. Lastly, detail out what we need to be successful in the future, for example, where we're aimed, what success looks like, what do we broadly need to learn/change/try.
Return to overview ⤴Product metrics are a great topic to bring up early, and often. Do it now, or forever hold your peace. Metrics make product goals very concrete, and they need to be documented for all to see. Getting your product partners to describe the key product metrics helps to quantify your potential impact. They're important to justify your work now, and validate your efforts later.
The purpose of this section is to make note of specific metrics, so that everyone is clear how success is measured for the product. Without clear metrics in place, goal posts 🥅 tend to shift over time. Metrics create clarity on what's ultimately important to affect within the product and related user experience. They also help guide your UXR recommendations, and prioritization thereof, later in the project.
Tips for identifying associated product metrics: Ask your product manager (PM) to share these with you. It's not the UX researcher's job to come up with product metrics. Through conversations/chat/email elicit 2–5 key business metrics that your research has the ability to impact.
Return to overview ⤴OK, now we're getting to our field of interest. The research goal is our guiding light for our research objectives, questions, and activities to come. Summarized in this statement will be key points derived from all sections prior. While everything following will expand on how to solve for this goal. Think of the research goal as the pinch point ⌛ of the information funnel within the brief.
The purpose of this section is to summarize the research intent into a 1-sentence statement, so that the focus and intended impact of the UXR are cemented. Without a single, concrete research goal, projects tend to chase too many topics. The 1-sentence goal will keep your work on a focused path to answering it. When in doubt, re-read your research goal to regain direction and block on unnecessary intrusions. It also serves as a useful tool for succinctly communicating to leaders, peers, and stakeholders what's being done.
Tips for crafting a to-the-point research goal: Begin with a 'How might we...' statement to set the expectation that solving the research goal is a question to be answered by all, and through a variety of possible approaches. Also, use/summarize key points from the 3rd paragraph (forward looking) of the business context section to write the crux of the goal. Then, append a 'so that...' clause that summarizes the most relevant metrics to provide reasoning and justification.
Return to overview ⤴Objectives provide the opportunity to double click on the goal and break it apart into respective sub-focal points. If the research goal sets the high-level direction and reasoning, the objectives establish the measurable action items for research. For example: Test [X], Assess [Y], Measure [Z], Analyze [A], Gather feedback on [B], Generate [C]...
The purpose of this section is to document tactical actions that solve for the research, so that progress can be measured. Without research objectives you might overemphasize certain research avenues later. They serve a purpose in helping you to assign equal weight 🏋️ to various activities that ladder up to the common goal. They also tend to be more tangible and specific than the goal itself.
Tips for generating related research objectives: Develop 2–4 research objectives to cover enough bases. Too few won't expand enough on the goal, and too many indicate you're seeking to accomplish more than any one project should. Additionally, leverage the objectives as a basic outline when crafting key questions in step 8.
Return to overview ⤴Note: not always applicable. For instance, secondary research, quantitative analysis, dog-fooding and some other project approaches won't require this section. However, moderated, unmoderated, surveys, usability, observations, focus groups, and more will make use of target participants.
The purpose of this section is to specify exactly with whom we're seeking to research, so that the how can be figured out in later stages. Clearly specifying target 🎯 participants helps fellow stakeholders get on board with your plan. With a better understanding of the research participants, stakeholders will be more able/willing to help generate key research questions, tasks, and activities in the following steps.
Tips for framing target participants: Use bullet point format to list out who's in scope. Detail specific attributes you're seeking. Think through how many participants, what they do, what they've done, how they engage, how often, what's the mix, etc. Leverage internal UX Personas, when available and applicable.
Return to overview ⤴'Key questions to answer' is the section we've found the most collaboration from stakeholders. They've most likely had questions floating around for some time. This is the section to begin jotting down. Note: this is not the actual research protocol. This is just the precursor. Consider it a brainstorm of the general and/or specific topics we wish to cover in the protocol to come.
The purpose of this section is to outline early thoughts on question topics / details, so that internal alignment on the path forward is gained. By filling in this section with others, it helps give everyone a sense for what will be covered in the future research sessions. Everyone gets a chance to share ideas 💡, and the UXRr gets the opportunity to steer/note/augment that input.
Tips for outlining key questions to answer: Separate 'key questions to answer' into 2 broad buckets — high-level and specific questions. You'll get a bit of both from stakeholders. They'll often jump quickly from broad-based question sets to very pointed questions examples they want to see covered. Notate both, and separate where possible.
Return to overview ⤴'Activities to generate insight' is where you outline your choice of research methods. What are the 1–4 ways you'll be creating data? Heuristic evaluations, moderated interviews, pop-up surveys, etc. We need to know the approach / method in order to move forward into additional planning ✅.
The purpose of this section is to decide which UXR methods to undertake, so that workstreams can be established. From this short list, you'll be able to further break down your operational to-do list (outside of this document). For example, if you're taking on moderated interviews as an 'activity to generate insight', a to-do on your personal agenda will be to establish screener criteria, connect with recruiter, set dates for sessions, build the protocol, and more.
Tips for surfacing activities to generate insights: Keep the list short. You can't do everything in one project. If you have too many research activities planned (more than 3 or 4), then you won't be able to move as quickly. In which case, consider breaking your project into smaller phases, or iterations (V1, V2, etc.).
Return to overview ⤴Now, the timeline is short and sweet. When do you expect the work to be completed? Within Q1, by X/Y date, yesterday (JK but... no, really). Timelines won't have many words, but may be up for some debate.
The purpose of this section is decipher the timeline of deliverables, so that stakeholders know when to expect results. Without a timeline from the beginning, projects will stretch and morph 😐. Keep it tight. Keep it right.
Tips for nailing down the timeline: Be semi-realistic. You want to make the UXR timeline a stretch goal you can achieve. Strive for a timeline you can hit if you find efficiencies, gain collaboration, or lower the fidelity of deliverables. Don't set the bar too high, but not too low either. Focus on building strong relationships with partners through reasonable expectation setting.
Return to overview ⤴The 'archive of deliverables' is the only component completed after the research. Upon finishing the project, you'll have a host of key deliverables. Interview protocols, journey maps, insight themes, and recommendations are a few examples of typical outputs from a UXR project. You'll want to keep tabs on these for future reference. Therefore, it's a good idea to link them from the the Project Brief — it starts the project, it ends the project.
The purpose of this section is to house links to key deliverables from the UXR project — after completion — so that everything is neatly documented in one place. The brief is your project overview, from front to back. From this point onward, anyone looking for information about the project can easily reference the brief to understand the context, metrics, goal, activities, and learnings. Once you have 10, 20, 30+ projects under your belt, these briefs will become a tremendous asset. A library of UXR.
Tips for keeping an archive of deliverables: Use anchor links, and label them well. Point readers directly to the key deliverables and project outcomes. Prototypes, decks, results, and more are all fair game. Don't forget, link them while they're still fresh 🌱.
Return to overview ⤴
Great! You like what you see. And you'd like to use our Project Brief process within your own work. We're flattered. That's exactly our hope. We've crafted this framework through hard work, trial, and error. Seeing how others do it, borrowing, modeling, and molding is how we've reached our 10 🙌 components for a UXR Project Brief.
Whether you use it without refinement, or make it your own, we're happy to share the Project Brief template for planning UXR projects. We look forward to working with you on a UXR project in the future, and seeing how you've evolved the Project Brief for your team and company.
Back to top ⤴
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference 👇 guide — free to download!
Get the Playbook
Learn More
