{"id":440,"date":"2026-02-09T23:20:29","date_gmt":"2026-02-10T04:20:29","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/?post_type=chapter&#038;p=440"},"modified":"2026-03-12T17:50:38","modified_gmt":"2026-03-12T21:50:38","slug":"6-4-conducting-ux-research","status":"publish","type":"chapter","link":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-4-conducting-ux-research\/","title":{"raw":"6.4 UX Research Methods","rendered":"6.4 UX Research Methods"},"content":{"raw":"The frameworks and principles we\u2019ve covered so far on the rhetorical situation and the Five Planes of User Experience are useful ways to think about UX design. But thinking only gets you so far. If you want to design products that actually work for people, you have to understand those people: who they are, what they\u2019re trying to do, how they behave in real situations, and what trips them up. You don\u2019t get that understanding from gut instinct. You get it from research.\r\n\r\nIf you\u2019ve already worked through Chapter 5, you\u2019re not starting from zero here. The habits you\u2019ve been practicing like finding and evaluating sources, narrowing a research focus, setting boundaries, and doing ethical research with human participants carry directly into UX. This section builds on that foundation by introducing a set of research techniques UX designers use to learn about users and make better design decisions: <strong>User Personas, Interviews, Contextual Inquiry,<\/strong> and <strong>Surveys<\/strong>\r\n\r\nNone of these methods belong exclusively to UX. Many come from social science, anthropology, and technical communication research. What UX has done is adapt them to the realities of interactive products, where \u201cunderstanding\u201d isn\u2019t just about what people say they need, but what they actually do when they\u2019re trying to use the design to complete a task.\r\n<h1>The Role of Research in UX Design<\/h1>\r\nResearch shows up in different ways depending on where you are in the design process.\r\n\r\nEarly on, it\u2019s mostly about <strong>empathy<\/strong>: getting a grounded sense of users\u2019 lives, goals, constraints, and everyday frustrations, along with the context in which they\u2019ll use the product. That kind of work feeds directly into the strategy plane. It helps teams define user needs and set product goals that actually connect to those needs, instead of guessing or designing for an imaginary \u201caverage user.\u201d\r\n\r\nUX folks often talk about a design lifecycle, and the names vary by organization, but the rhythm is pretty consistent: learn about users and their context, define the problem, create and refine possible solutions, test those solutions with users, then iterate based on what you learned (see illustration in <strong>Figure 6.4.1<\/strong>). The important point is that research isn\u2019t a one-time \u201cdiscovery phase\u201d you check off at the beginning. It comes back throughout the project, with different methods depending on what you\u2019re trying to find out.\r\n\r\n[caption id=\"attachment_512\" align=\"alignnone\" width=\"1024\"]<img class=\"wp-image-512 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-1024x574.png\" alt=\"Diagram of an iterative software\/project design lifecycle shown as a circular loop of arrows: Initial Planning \u2192 Planning \u2192 Requirements \u2192 Analysis &amp; Design \u2192 Implementation \u2192 Deployment \u2192 Testing \u2192 Evaluation, returning back to Requirements\/Analysis &amp; Design for the next cycle.\" width=\"1024\" height=\"574\" \/> <strong>Figure 6.4.1<\/strong> The UX Design Life Cycle[\/caption]\r\n<h1>User Personas<\/h1>\r\nOne of the most common ways UX teams capture and share what they\u2019ve learned about users is developing a \u201cpersona.\u201d A persona is a research-based portrait of a user type. In other words, it is a fictional composite character that represents a real segment of your audience. The point isn\u2019t to invent a cute character. It\u2019s to make research findings easier to remember and easier to use when the team is making decisions.\r\n\r\nThe \u201cresearch-based\u201d part is doing a lot of work there. Strong personas are derived from interviews, observation, surveys, support logs, analytics, and anywhere else you can gather evidence about actual users. When a persona is created without that grounding, it usually turns into a stereotype of bundled assumptions dressed up with a name and a headshot. Research-backed personas do the opposite. They keep the team oriented toward real needs and real constraints, even when the users aren\u2019t in the room.\r\n\r\nA solid persona usually includes a few standard pieces:\r\n<ul>\r\n \t<li>Name and photo (often a stock image or AI-generated picture) to make it memorable. The persona isn\u2019t a real person, but the human framing helps the team talk about user needs in concrete terms.<\/li>\r\n \t<li>Basic background details like age range, role\/occupation, location, and relevant context. Useful for setting the scene, but rarely the main driver of design decisions.<\/li>\r\n \t<li>Goals: what this user is trying to accomplish with the product, and what \u201csuccess\u201d looks like for them.<\/li>\r\n \t<li>Pain points: what gets in their way: confusing steps, missing information, accessibility barriers, time pressure, anxiety about making mistakes, and so on.<\/li>\r\n \t<li>Often, you\u2019ll also see behaviours (how they currently do the task), motivations (what matters to them and why), and a short quote written in a natural voice that captures their mindset.<\/li>\r\n<\/ul>\r\nUsed well, personas are less about pretending you \u201cknow\u201d a user and more about keeping the team honest: reminding everyone that every feature, label, and workflow lands on a person with a goal, a context, and a limited amount of patience. You can find and create Persona templates , like the one in <strong>Figure 6.4.2<\/strong>, in various online platforms such as Canva and Figma.\r\n\r\n[caption id=\"attachment_514\" align=\"alignnone\" width=\"1024\"]<img class=\"wp-image-514 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-1024x683.png\" alt=\"A persona template showing: photo placeholder, name (e.g., 'Maria Chen'), and key details organized in sections. Includes: Demographics (age 34, marketing manager, urban), Goals (find information quickly, complete tasks on mobile, avoid unnecessary steps), Frustrations (cluttered interfaces, required account creation, slow load times), Quote ('I don't have time to figure out how your app works\u2014it should just work.'), and a brief scenario of typical use.\" width=\"1024\" height=\"683\" \/> <strong>Figure 6.4.2<\/strong> Sample User Persona (created using Figma and Copilot)[\/caption]\r\n\r\nPersonas only pay off if a team actually uses them, not if they get filed away in a slide deck and never mentioned again. In design discussions, they give you a simple way to stay grounded: \u201cHow would Maria approach this? Would she understand what this button does? Would this flow help her finish the task, or would it add friction?\u201d\r\n\r\nThey\u2019re also useful when new ideas start flying around. If someone proposes a new feature, personas let you respond with something more concrete than opinion: \u201cWhich persona is this for?\u201d \u201cWhat goal does it support?\u201d \u201cDoes it solve a problem we\u2019ve actually seen, or are we designing for a hunch?\u201d That shift away from \u201cI think users want\u2026\u201d and toward \u201cOur research suggests\u2026\u201d can defuse a lot of unproductive debate.\r\n\r\nMost products need more than one persona, because different groups come to the same system for different reasons. A university site is a good example: prospective students, current students, parents, faculty, and community members all show up with different questions, time pressures, and levels of familiarity. At the same time, more personas aren\u2019t automatically better. Three to five strong, research-backed personas usually beat a dozen thin ones. The goal isn\u2019t to cover every demographic category; it\u2019s to capture the differences that actually change what the design needs to do.\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>EXERCISE 6.8<\/strong> Build a Persona from Observation<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nYou are part of a team that has been asked to improve the self-checkout system at your campus bookstore. Your job is to start creating a user persona. You will begin this task by using direct observations and experience following these steps:\r\n<ol>\r\n \t<li>Observe three to five people using the self-checkout system. Note their approximate age range, how confidently they approached the machine, where they hesitated, and whether they needed help.<\/li>\r\n \t<li>Based on those observations, draft a single persona using the format described above. Include a <strong>name<\/strong> and brief <strong>background<\/strong>, <strong>goals<\/strong> (what they\u2019re trying to accomplish), <strong>pain points<\/strong> (where the current system makes things harder), and a <strong>short quote<\/strong> capturing their mindset.<\/li>\r\n \t<li>Write a brief paragraph (three to five sentences) explaining what additional research you would need to do to strengthen this persona. What are you guessing about that you\u2019d want evidence for?<\/li>\r\n<\/ol>\r\nShare your persona with a partner. How do your personas differ? What assumptions did you catch yourself making? How does this connect to the audience profile questions from Chapter 2.2?\r\n\r\n<\/div>\r\n&nbsp;\r\n\r\n<\/div>\r\n<h1>Interviews and Contextual Inquiry<\/h1>\r\n<strong>INTERVIEWS<\/strong> are one of the best ways to understand users because they not only tell you <em>what<\/em> people do, they also instead help you uncover <em>why<\/em> they do it. A good interview can surface motivations, workarounds, mental models, and small frustrations users have gotten so used to that they don\u2019t even think to report them in a survey. It also gives you something you can\u2019t get from a fixed questionnaire: the ability to follow the conversation where it needs to go, especially when a participant says something unexpected or reveals a problem you didn\u2019t know to ask about.\r\n\r\nMost UX interviews are semi-structured. You might have a list of key topics, a rough sequence, a few must-hit questions, etc.; however, you don\u2019t treat it like a script. If the participant brings up something important, you pause and dig in. That flexibility is where a lot of the value comes from.\r\n\r\nThe best interview questions are open-ended and grounded in real events. You\u2019re trying to get participants to describe what actually happened, not to agree with your framing. \u201cTell me about the last time you tried to\u2026\u201d will usually get you a story: what they were doing, what they expected, where they got stuck, what they did next. A question like \u201cDo you find it easy to\u2026?\u201d tends to produce a quick yes\/no (or a polite answer) and doesn\u2019t give you much to work with. The goal is simple: get people talking about their experience in their own terms, then listen for the details that reveal needs, assumptions, and pain points.\r\n<div class=\"textbox textbox--key-takeaways\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\" style=\"text-align: center\"><strong>Crafting\u00a0 Effective Interview Questions<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<strong>Ask about specific experiences: <\/strong>\"Walk me through the last time you renewed a library book online.\"\r\n\r\n<strong>Avoid leading questions: <\/strong>Instead of \"Was the checkout process confusing?\" ask \"How did you find the checkout process?\"\r\n\r\n<strong>Probe for details: <\/strong>\"You mentioned that was frustrating\u2014can you tell me more about what happened?\"\r\n\r\n<strong>Ask about workarounds: <\/strong>\"When the app doesn't do what you need, what do you do instead?\"\r\n\r\n<strong>Explore the context: <\/strong>\"Where are you usually when you use this? What else is going on around you?\"\r\n\r\n<\/div>\r\n<\/div>\r\n&nbsp;\r\n\r\n<strong>CONTEXTUAL INQUIRY<\/strong>\u00a0is basically what happens when you stop relying on people\u2019s memory and watch them work in real life. Instead of interviewing someone in a conference room and asking them to describe what they <em>usually<\/em> do, you observe them doing the task in their actual environment. If you\u2019re studying how nurses use an electronic medical records system, you learn far more by being at the nursing station during a shift than by showing them screenshots in a quiet room. The real setting exposes the stuff people forget to mention: interruptions, time pressure, noisy surroundings, handoffs between coworkers, and the little workarounds they\u2019ve built to cope.\r\n\r\nThe mix of observation and interview is what makes it so useful. You can see what someone does and then ask about it right away. When a participant takes an unexpected path, you can follow up in the moment: \u201cI noticed you clicked there instead of using the menu. What were you looking for?\u201d Those quick questions often uncover the best insights, because they reveal the user\u2019s logic and expectations, not just the \u201cofficial\u201d workflow.\r\n\r\nInterviews and contextual inquiry also raise the ethical stakes, especially when you\u2019re in workplaces or other sensitive environments. The basics from Chapter 5.5 Engagement and Consultation apply directly: you need to consider issues like informed consent, confidentiality, and participant welfare. People should know what they\u2019re agreeing to, how recordings or notes will be used, and that they can stop at any time. Researchers also need to be careful about privacy both in terms of the participants and anyone else who might appear in the background. Making a better product is a good goal, but it doesn\u2019t outweigh the responsibility to treat participants with respect.\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>EXERCISE 6.9\u00a0<\/strong> Mini Contextual Inquiry: Observe, then Ask<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nContextual inquiry is a method where you observe someone performing a task in their real environment and then ask follow-up questions in the moment. Try this simplified classroom version.\r\n\r\n<strong>Setup<\/strong>: Form into pairs where one person is the \"user\" and one person is the \"researcher.\" The user will attempt a task on a real digital product while the researcher observes and takes notes. After five minutes, switch roles with a different task.\r\n\r\n<strong>Suggested User Tasks: <\/strong>\r\n<ul>\r\n \t<li>Find the office hours and email address for a specific instructor on your university\u2019s website or LMS.<\/li>\r\n \t<li>Figure out how to request a transcript through your school\u2019s student portal.<\/li>\r\n \t<li>Find and compare two products on an e-commerce site using only the site\u2019s filtering tools.<\/li>\r\n \t<li>Locate the return policy for a specific online retailer without using the site\u2019s search bar.<\/li>\r\n<\/ul>\r\n<strong>Researcher Instructions<\/strong>:\u00a0 Watch silently for the first two minutes. Note where the user clicks, pauses, backtracks, or shows signs of frustration. Then, during the remaining time, ask short follow-up questions in the moment: \u201cWhat were you expecting to find there?\u201d \u201cWhat made you click that link?\u201d \u201cWhat would you try next?\u201d\r\n\r\n<strong>After both rounds, discuss:<\/strong>\r\n<ul>\r\n \t<li>What did you notice as a researcher that the user didn\u2019t mention on their own?<\/li>\r\n \t<li>What did you learn as a user from being observed\u2014did the experience make you more aware of your own habits or assumptions?<\/li>\r\n \t<li>How does this compare to the kind of audience analysis you\u2019d do before writing a document (Chapter 2.2)? What can observation reveal that inference alone cannot?<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\n<h1>Surveys<\/h1>\r\nInterviews are great for depth, but they don\u2019t tell you how common something is. That\u2019s where surveys shine. With a well-built survey, you can reach hundreds or thousands of users and start seeing patterns you\u2019d never pick up from a dozen interviews: how many people are primarily on mobile, whether satisfaction differs by user segment, which features matter most, where people tend to drop off, and so on.\r\n\r\nThe catch is that surveys are easy to do badly. A vague question produces vague data. A leading question produces the answer you were hoping for. A long survey produces half-finished responses as people bail. Keep questions clear and specific, avoid loaded wording, make response options cover the full range without overlapping, and keep the survey as short as you can while still getting what you need. Here are <a href=\"https:\/\/www.nngroup.com\/articles\/survey-best-practices\/\" target=\"_blank\" rel=\"noopener\">10 Best Practices<\/a> for writing good survey questions.\r\n\r\nIn UX work, surveys tend to show up in a few common roles:\r\n<ul>\r\n \t<li>Screeners to recruit the right participants for interviews or usability tests (e.g., \u201cHave you done X in the last month?\u201d \u201cWhat device do you use most?\u201d).<\/li>\r\n \t<li>Satisfaction surveys to track attitudes over time, often using standardized scales so results are comparable.<\/li>\r\n \t<li>Feature prioritization surveys to help teams make tradeoffs when they can\u2019t build everything at once.<\/li>\r\n \t<li>Post-task surveys given right after someone completes a task, when their reaction is immediate and specific.<\/li>\r\n<\/ul>\r\nUsed well, surveys don\u2019t replace interviews; rather, they complement them. Interviews help you discover what to ask. Surveys help you find out how widespread the answers are.\r\n<div class=\"textbox textbox--key-takeaways\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\" style=\"text-align: center\"><strong>The System Usability Scale (SUS)<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nOne widely used survey instrument in UX research is the<a href=\"https:\/\/measuringu.com\/sus\/\" target=\"_blank\" rel=\"noopener\"> System Usability Scale<\/a>, a ten-item questionnaire that provides a quick, reliable measure of perceived usability. Developed in 1986 and validated across thousands of studies, the SUS yields a score from 0 to 100 that can be compared against established benchmarks. A score above 68 is considered above average; scores above 80 indicate excellent usability. The SUS is freely available and can be administered after any user interaction with a product.\r\n\r\n<\/div>\r\n<\/div>\r\nSurveys are strongest when they\u2019re part of a mixed-method approach. They\u2019re good at telling you <em>what<\/em> is happening at scale (e.g, what people use, where they struggle, how satisfaction differs across groups) but they usually can\u2019t tell you <em>why<\/em>.\r\n\r\nSo when a survey shows that users are abandoning a feature or rating it poorly, you bring in interviews, contextual inquiry, or usability testing to figure out why that is happening. Conversely, when interviews uncover a need or a frustration, a survey can help you answer the next question: is this a niche issue, or something many users experience?\r\n\r\nThat\u2019s why mature UX research programs rarely lean on a single method. They combine approaches so the weaknesses of one method get covered by the strengths of another: breadth plus depth, numbers plus stories, patterns plus explanations.\r\n<h1>From Research to Design<\/h1>\r\nResearch gives you raw material. Design asks you to make choices. The bridge between the two is analysis and synthesis: figuring out what the data is really telling you and turning it into something a team can act on. This is where the qualitative research skills you\u2019ve built in technical communication start to matter a lot.\r\n\r\nAfter interviews, researchers usually go back through recordings and notes looking for patterns. What comes up again and again across participants? Which problems show up independently in multiple conversations? Where do people seem to share the same mental model, and where do they interpret the product in totally different ways? That pattern-finding work, often called <strong><em>thematic analysis<\/em><\/strong>, is what turns a pile of individual stories into insights you can design around.\r\n\r\nThose insights can be captured in a few common formats:\r\n<ul>\r\n \t<li>Personas, which condense patterns into a handful of user types.<\/li>\r\n \t<li>Journey maps, which lay out the steps users take to reach a goal and spotlight friction points and missed opportunities.<\/li>\r\n \t<li>Empathy maps, which organize what users say, think, feel, and do so the team keeps the user\u2019s perspective in view.<\/li>\r\n<\/ul>\r\nThese artifacts aren\u2019t just \u201cresearch deliverables.\u201d They\u2019re reference points the team can come back to when discussions around design choices drift toward assumptions or personal preference.\r\n\r\nOne of the most important outcomes of synthesis is a clear statement of user needs and design requirements. The best requirements are specific and tied to evidence. If research shows that users abandon checkout because they don\u2019t see shipping costs until the end, a requirement might be: <em>Show estimated shipping costs before checkout begins.<\/em> If research shows mobile users are squeezing tasks in between other activities, a requirement might be: <em>Make core tasks completable in under 60 seconds on mobile.<\/em> These become criteria you can use to judge design solutions: does the new flow meet the requirement or not?\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>SYNTHESIS EXERCISE:\u00a0 \u00a0From Research to Requirements<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nThe information above describes how research findings get turned into personas, journey maps, and design requirements. This exercise asks you to practice that synthesis step.\r\n\r\n<strong>Scenario<\/strong>:\u00a0 Imagine you\u2019ve just completed five interviews with students who use your university\u2019s online financial aid portal. Here are condensed findings from those interviews:\r\n<ul>\r\n \t<li>Student A:\u00a0 \u00a0\u201cI never know where I am in the process. Did I submit everything? Is something missing? I just get silence until there\u2019s a problem.\u201d<\/li>\r\n \t<li>Student B:\u00a0 \u00a0\u201cI filled out the FAFSA on my phone because I was at work, and half the form didn\u2019t display right. I had to go home and redo it on my laptop.\u201d<\/li>\r\n \t<li>Student C:\u00a0 \u00a0\u201cMy parents don\u2019t speak English well, and they had to verify some of the financial information, but the portal doesn\u2019t offer anything in Spanish.\u201d<\/li>\r\n \t<li>Student D:\u00a0 \u201cEvery time I call the financial aid office, they tell me something different than what the portal says. I don\u2019t know which one to trust.\u201d<\/li>\r\n \t<li>Student E:\u00a0 \u201cI got an email saying my aid was adjusted, but when I logged in, nothing looked different. I still don\u2019t know what changed or why.\u201d<\/li>\r\n<\/ul>\r\n<strong>Your Task<\/strong>:\r\n<p style=\"padding-left: 40px\"><strong>Identify<\/strong> three to four themes or patterns across these responses.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Write<\/strong> two concrete, evidence-based design requirements that address the most critical user needs. Follow the format described above: each requirement should be specific and tied to something you observed in the data. (For example: \u201cProvide a visible status tracker showing each step of the financial aid process and its current state.\u201d)<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Identify<\/strong> one question you\u2019d want to investigate further, either through more interviews, a survey, or contextual inquiry. Explain what method you\u2019d choose and why.<\/p>\r\n<strong>Discussion: <\/strong>Compare your themes and requirements with a partner. Did you prioritize the same issues? How did you decide what was most critical? This is where the \u201clearn, build, test, revise\u201d cycle from Section 6.1 starts to become concrete.\r\n\r\n<\/div>\r\n<\/div>\r\nTaken together, the research methods in this chapter give you a practical way to move from guesswork to understanding. They help you see users more clearly, identify the problems that actually matter, and translate what you learn into personas, maps, and concrete design requirements a team can use. That\u2019s the through-line of UX research: creating user-centred decisions grounded in evidence, not assumptions.\r\n\r\n&nbsp;","rendered":"<p>The frameworks and principles we\u2019ve covered so far on the rhetorical situation and the Five Planes of User Experience are useful ways to think about UX design. But thinking only gets you so far. If you want to design products that actually work for people, you have to understand those people: who they are, what they\u2019re trying to do, how they behave in real situations, and what trips them up. You don\u2019t get that understanding from gut instinct. You get it from research.<\/p>\n<p>If you\u2019ve already worked through Chapter 5, you\u2019re not starting from zero here. The habits you\u2019ve been practicing like finding and evaluating sources, narrowing a research focus, setting boundaries, and doing ethical research with human participants carry directly into UX. This section builds on that foundation by introducing a set of research techniques UX designers use to learn about users and make better design decisions: <strong>User Personas, Interviews, Contextual Inquiry,<\/strong> and <strong>Surveys<\/strong><\/p>\n<p>None of these methods belong exclusively to UX. Many come from social science, anthropology, and technical communication research. What UX has done is adapt them to the realities of interactive products, where \u201cunderstanding\u201d isn\u2019t just about what people say they need, but what they actually do when they\u2019re trying to use the design to complete a task.<\/p>\n<h1>The Role of Research in UX Design<\/h1>\n<p>Research shows up in different ways depending on where you are in the design process.<\/p>\n<p>Early on, it\u2019s mostly about <strong>empathy<\/strong>: getting a grounded sense of users\u2019 lives, goals, constraints, and everyday frustrations, along with the context in which they\u2019ll use the product. That kind of work feeds directly into the strategy plane. It helps teams define user needs and set product goals that actually connect to those needs, instead of guessing or designing for an imaginary \u201caverage user.\u201d<\/p>\n<p>UX folks often talk about a design lifecycle, and the names vary by organization, but the rhythm is pretty consistent: learn about users and their context, define the problem, create and refine possible solutions, test those solutions with users, then iterate based on what you learned (see illustration in <strong>Figure 6.4.1<\/strong>). The important point is that research isn\u2019t a one-time \u201cdiscovery phase\u201d you check off at the beginning. It comes back throughout the project, with different methods depending on what you\u2019re trying to find out.<\/p>\n<figure id=\"attachment_512\" aria-describedby=\"caption-attachment-512\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-512 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-1024x574.png\" alt=\"Diagram of an iterative software\/project design lifecycle shown as a circular loop of arrows: Initial Planning \u2192 Planning \u2192 Requirements \u2192 Analysis &amp; Design \u2192 Implementation \u2192 Deployment \u2192 Testing \u2192 Evaluation, returning back to Requirements\/Analysis &amp; Design for the next cycle.\" width=\"1024\" height=\"574\" srcset=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-1024x574.png 1024w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-300x168.png 300w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-768x430.png 768w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-1536x861.png 1536w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-65x36.png 65w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-225x126.png 225w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle-350x196.png 350w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/UX-Design-Life-Cycle.png 1892w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-512\" class=\"wp-caption-text\"><strong>Figure 6.4.1<\/strong> The UX Design Life Cycle<\/figcaption><\/figure>\n<h1>User Personas<\/h1>\n<p>One of the most common ways UX teams capture and share what they\u2019ve learned about users is developing a \u201cpersona.\u201d A persona is a research-based portrait of a user type. In other words, it is a fictional composite character that represents a real segment of your audience. The point isn\u2019t to invent a cute character. It\u2019s to make research findings easier to remember and easier to use when the team is making decisions.<\/p>\n<p>The \u201cresearch-based\u201d part is doing a lot of work there. Strong personas are derived from interviews, observation, surveys, support logs, analytics, and anywhere else you can gather evidence about actual users. When a persona is created without that grounding, it usually turns into a stereotype of bundled assumptions dressed up with a name and a headshot. Research-backed personas do the opposite. They keep the team oriented toward real needs and real constraints, even when the users aren\u2019t in the room.<\/p>\n<p>A solid persona usually includes a few standard pieces:<\/p>\n<ul>\n<li>Name and photo (often a stock image or AI-generated picture) to make it memorable. The persona isn\u2019t a real person, but the human framing helps the team talk about user needs in concrete terms.<\/li>\n<li>Basic background details like age range, role\/occupation, location, and relevant context. Useful for setting the scene, but rarely the main driver of design decisions.<\/li>\n<li>Goals: what this user is trying to accomplish with the product, and what \u201csuccess\u201d looks like for them.<\/li>\n<li>Pain points: what gets in their way: confusing steps, missing information, accessibility barriers, time pressure, anxiety about making mistakes, and so on.<\/li>\n<li>Often, you\u2019ll also see behaviours (how they currently do the task), motivations (what matters to them and why), and a short quote written in a natural voice that captures their mindset.<\/li>\n<\/ul>\n<p>Used well, personas are less about pretending you \u201cknow\u201d a user and more about keeping the team honest: reminding everyone that every feature, label, and workflow lands on a person with a goal, a context, and a limited amount of patience. You can find and create Persona templates , like the one in <strong>Figure 6.4.2<\/strong>, in various online platforms such as Canva and Figma.<\/p>\n<figure id=\"attachment_514\" aria-describedby=\"caption-attachment-514\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-514 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-1024x683.png\" alt=\"A persona template showing: photo placeholder, name (e.g., 'Maria Chen'), and key details organized in sections. Includes: Demographics (age 34, marketing manager, urban), Goals (find information quickly, complete tasks on mobile, avoid unnecessary steps), Frustrations (cluttered interfaces, required account creation, slow load times), Quote ('I don't have time to figure out how your app works\u2014it should just work.'), and a brief scenario of typical use.\" width=\"1024\" height=\"683\" srcset=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-1024x683.png 1024w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-300x200.png 300w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-768x512.png 768w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-65x43.png 65w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-225x150.png 225w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen-350x233.png 350w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Persona-Maria-Chen.png 1536w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-514\" class=\"wp-caption-text\"><strong>Figure 6.4.2<\/strong> Sample User Persona (created using Figma and Copilot)<\/figcaption><\/figure>\n<p>Personas only pay off if a team actually uses them, not if they get filed away in a slide deck and never mentioned again. In design discussions, they give you a simple way to stay grounded: \u201cHow would Maria approach this? Would she understand what this button does? Would this flow help her finish the task, or would it add friction?\u201d<\/p>\n<p>They\u2019re also useful when new ideas start flying around. If someone proposes a new feature, personas let you respond with something more concrete than opinion: \u201cWhich persona is this for?\u201d \u201cWhat goal does it support?\u201d \u201cDoes it solve a problem we\u2019ve actually seen, or are we designing for a hunch?\u201d That shift away from \u201cI think users want\u2026\u201d and toward \u201cOur research suggests\u2026\u201d can defuse a lot of unproductive debate.<\/p>\n<p>Most products need more than one persona, because different groups come to the same system for different reasons. A university site is a good example: prospective students, current students, parents, faculty, and community members all show up with different questions, time pressures, and levels of familiarity. At the same time, more personas aren\u2019t automatically better. Three to five strong, research-backed personas usually beat a dozen thin ones. The goal isn\u2019t to cover every demographic category; it\u2019s to capture the differences that actually change what the design needs to do.<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>EXERCISE 6.8<\/strong> Build a Persona from Observation<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>You are part of a team that has been asked to improve the self-checkout system at your campus bookstore. Your job is to start creating a user persona. You will begin this task by using direct observations and experience following these steps:<\/p>\n<ol>\n<li>Observe three to five people using the self-checkout system. Note their approximate age range, how confidently they approached the machine, where they hesitated, and whether they needed help.<\/li>\n<li>Based on those observations, draft a single persona using the format described above. Include a <strong>name<\/strong> and brief <strong>background<\/strong>, <strong>goals<\/strong> (what they\u2019re trying to accomplish), <strong>pain points<\/strong> (where the current system makes things harder), and a <strong>short quote<\/strong> capturing their mindset.<\/li>\n<li>Write a brief paragraph (three to five sentences) explaining what additional research you would need to do to strengthen this persona. What are you guessing about that you\u2019d want evidence for?<\/li>\n<\/ol>\n<p>Share your persona with a partner. How do your personas differ? What assumptions did you catch yourself making? How does this connect to the audience profile questions from Chapter 2.2?<\/p>\n<\/div>\n<p>&nbsp;<\/p>\n<\/div>\n<h1>Interviews and Contextual Inquiry<\/h1>\n<p><strong>INTERVIEWS<\/strong> are one of the best ways to understand users because they not only tell you <em>what<\/em> people do, they also instead help you uncover <em>why<\/em> they do it. A good interview can surface motivations, workarounds, mental models, and small frustrations users have gotten so used to that they don\u2019t even think to report them in a survey. It also gives you something you can\u2019t get from a fixed questionnaire: the ability to follow the conversation where it needs to go, especially when a participant says something unexpected or reveals a problem you didn\u2019t know to ask about.<\/p>\n<p>Most UX interviews are semi-structured. You might have a list of key topics, a rough sequence, a few must-hit questions, etc.; however, you don\u2019t treat it like a script. If the participant brings up something important, you pause and dig in. That flexibility is where a lot of the value comes from.<\/p>\n<p>The best interview questions are open-ended and grounded in real events. You\u2019re trying to get participants to describe what actually happened, not to agree with your framing. \u201cTell me about the last time you tried to\u2026\u201d will usually get you a story: what they were doing, what they expected, where they got stuck, what they did next. A question like \u201cDo you find it easy to\u2026?\u201d tends to produce a quick yes\/no (or a polite answer) and doesn\u2019t give you much to work with. The goal is simple: get people talking about their experience in their own terms, then listen for the details that reveal needs, assumptions, and pain points.<\/p>\n<div class=\"textbox textbox--key-takeaways\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\" style=\"text-align: center\"><strong>Crafting\u00a0 Effective Interview Questions<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p><strong>Ask about specific experiences: <\/strong>&#8220;Walk me through the last time you renewed a library book online.&#8221;<\/p>\n<p><strong>Avoid leading questions: <\/strong>Instead of &#8220;Was the checkout process confusing?&#8221; ask &#8220;How did you find the checkout process?&#8221;<\/p>\n<p><strong>Probe for details: <\/strong>&#8220;You mentioned that was frustrating\u2014can you tell me more about what happened?&#8221;<\/p>\n<p><strong>Ask about workarounds: <\/strong>&#8220;When the app doesn&#8217;t do what you need, what do you do instead?&#8221;<\/p>\n<p><strong>Explore the context: <\/strong>&#8220;Where are you usually when you use this? What else is going on around you?&#8221;<\/p>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<p><strong>CONTEXTUAL INQUIRY<\/strong>\u00a0is basically what happens when you stop relying on people\u2019s memory and watch them work in real life. Instead of interviewing someone in a conference room and asking them to describe what they <em>usually<\/em> do, you observe them doing the task in their actual environment. If you\u2019re studying how nurses use an electronic medical records system, you learn far more by being at the nursing station during a shift than by showing them screenshots in a quiet room. The real setting exposes the stuff people forget to mention: interruptions, time pressure, noisy surroundings, handoffs between coworkers, and the little workarounds they\u2019ve built to cope.<\/p>\n<p>The mix of observation and interview is what makes it so useful. You can see what someone does and then ask about it right away. When a participant takes an unexpected path, you can follow up in the moment: \u201cI noticed you clicked there instead of using the menu. What were you looking for?\u201d Those quick questions often uncover the best insights, because they reveal the user\u2019s logic and expectations, not just the \u201cofficial\u201d workflow.<\/p>\n<p>Interviews and contextual inquiry also raise the ethical stakes, especially when you\u2019re in workplaces or other sensitive environments. The basics from Chapter 5.5 Engagement and Consultation apply directly: you need to consider issues like informed consent, confidentiality, and participant welfare. People should know what they\u2019re agreeing to, how recordings or notes will be used, and that they can stop at any time. Researchers also need to be careful about privacy both in terms of the participants and anyone else who might appear in the background. Making a better product is a good goal, but it doesn\u2019t outweigh the responsibility to treat participants with respect.<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>EXERCISE 6.9\u00a0<\/strong> Mini Contextual Inquiry: Observe, then Ask<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>Contextual inquiry is a method where you observe someone performing a task in their real environment and then ask follow-up questions in the moment. Try this simplified classroom version.<\/p>\n<p><strong>Setup<\/strong>: Form into pairs where one person is the &#8220;user&#8221; and one person is the &#8220;researcher.&#8221; The user will attempt a task on a real digital product while the researcher observes and takes notes. After five minutes, switch roles with a different task.<\/p>\n<p><strong>Suggested User Tasks: <\/strong><\/p>\n<ul>\n<li>Find the office hours and email address for a specific instructor on your university\u2019s website or LMS.<\/li>\n<li>Figure out how to request a transcript through your school\u2019s student portal.<\/li>\n<li>Find and compare two products on an e-commerce site using only the site\u2019s filtering tools.<\/li>\n<li>Locate the return policy for a specific online retailer without using the site\u2019s search bar.<\/li>\n<\/ul>\n<p><strong>Researcher Instructions<\/strong>:\u00a0 Watch silently for the first two minutes. Note where the user clicks, pauses, backtracks, or shows signs of frustration. Then, during the remaining time, ask short follow-up questions in the moment: \u201cWhat were you expecting to find there?\u201d \u201cWhat made you click that link?\u201d \u201cWhat would you try next?\u201d<\/p>\n<p><strong>After both rounds, discuss:<\/strong><\/p>\n<ul>\n<li>What did you notice as a researcher that the user didn\u2019t mention on their own?<\/li>\n<li>What did you learn as a user from being observed\u2014did the experience make you more aware of your own habits or assumptions?<\/li>\n<li>How does this compare to the kind of audience analysis you\u2019d do before writing a document (Chapter 2.2)? What can observation reveal that inference alone cannot?<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h1>Surveys<\/h1>\n<p>Interviews are great for depth, but they don\u2019t tell you how common something is. That\u2019s where surveys shine. With a well-built survey, you can reach hundreds or thousands of users and start seeing patterns you\u2019d never pick up from a dozen interviews: how many people are primarily on mobile, whether satisfaction differs by user segment, which features matter most, where people tend to drop off, and so on.<\/p>\n<p>The catch is that surveys are easy to do badly. A vague question produces vague data. A leading question produces the answer you were hoping for. A long survey produces half-finished responses as people bail. Keep questions clear and specific, avoid loaded wording, make response options cover the full range without overlapping, and keep the survey as short as you can while still getting what you need. Here are <a href=\"https:\/\/www.nngroup.com\/articles\/survey-best-practices\/\" target=\"_blank\" rel=\"noopener\">10 Best Practices<\/a> for writing good survey questions.<\/p>\n<p>In UX work, surveys tend to show up in a few common roles:<\/p>\n<ul>\n<li>Screeners to recruit the right participants for interviews or usability tests (e.g., \u201cHave you done X in the last month?\u201d \u201cWhat device do you use most?\u201d).<\/li>\n<li>Satisfaction surveys to track attitudes over time, often using standardized scales so results are comparable.<\/li>\n<li>Feature prioritization surveys to help teams make tradeoffs when they can\u2019t build everything at once.<\/li>\n<li>Post-task surveys given right after someone completes a task, when their reaction is immediate and specific.<\/li>\n<\/ul>\n<p>Used well, surveys don\u2019t replace interviews; rather, they complement them. Interviews help you discover what to ask. Surveys help you find out how widespread the answers are.<\/p>\n<div class=\"textbox textbox--key-takeaways\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\" style=\"text-align: center\"><strong>The System Usability Scale (SUS)<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>One widely used survey instrument in UX research is the<a href=\"https:\/\/measuringu.com\/sus\/\" target=\"_blank\" rel=\"noopener\"> System Usability Scale<\/a>, a ten-item questionnaire that provides a quick, reliable measure of perceived usability. Developed in 1986 and validated across thousands of studies, the SUS yields a score from 0 to 100 that can be compared against established benchmarks. A score above 68 is considered above average; scores above 80 indicate excellent usability. The SUS is freely available and can be administered after any user interaction with a product.<\/p>\n<\/div>\n<\/div>\n<p>Surveys are strongest when they\u2019re part of a mixed-method approach. They\u2019re good at telling you <em>what<\/em> is happening at scale (e.g, what people use, where they struggle, how satisfaction differs across groups) but they usually can\u2019t tell you <em>why<\/em>.<\/p>\n<p>So when a survey shows that users are abandoning a feature or rating it poorly, you bring in interviews, contextual inquiry, or usability testing to figure out why that is happening. Conversely, when interviews uncover a need or a frustration, a survey can help you answer the next question: is this a niche issue, or something many users experience?<\/p>\n<p>That\u2019s why mature UX research programs rarely lean on a single method. They combine approaches so the weaknesses of one method get covered by the strengths of another: breadth plus depth, numbers plus stories, patterns plus explanations.<\/p>\n<h1>From Research to Design<\/h1>\n<p>Research gives you raw material. Design asks you to make choices. The bridge between the two is analysis and synthesis: figuring out what the data is really telling you and turning it into something a team can act on. This is where the qualitative research skills you\u2019ve built in technical communication start to matter a lot.<\/p>\n<p>After interviews, researchers usually go back through recordings and notes looking for patterns. What comes up again and again across participants? Which problems show up independently in multiple conversations? Where do people seem to share the same mental model, and where do they interpret the product in totally different ways? That pattern-finding work, often called <strong><em>thematic analysis<\/em><\/strong>, is what turns a pile of individual stories into insights you can design around.<\/p>\n<p>Those insights can be captured in a few common formats:<\/p>\n<ul>\n<li>Personas, which condense patterns into a handful of user types.<\/li>\n<li>Journey maps, which lay out the steps users take to reach a goal and spotlight friction points and missed opportunities.<\/li>\n<li>Empathy maps, which organize what users say, think, feel, and do so the team keeps the user\u2019s perspective in view.<\/li>\n<\/ul>\n<p>These artifacts aren\u2019t just \u201cresearch deliverables.\u201d They\u2019re reference points the team can come back to when discussions around design choices drift toward assumptions or personal preference.<\/p>\n<p>One of the most important outcomes of synthesis is a clear statement of user needs and design requirements. The best requirements are specific and tied to evidence. If research shows that users abandon checkout because they don\u2019t see shipping costs until the end, a requirement might be: <em>Show estimated shipping costs before checkout begins.<\/em> If research shows mobile users are squeezing tasks in between other activities, a requirement might be: <em>Make core tasks completable in under 60 seconds on mobile.<\/em> These become criteria you can use to judge design solutions: does the new flow meet the requirement or not?<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>SYNTHESIS EXERCISE:\u00a0 \u00a0From Research to Requirements<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>The information above describes how research findings get turned into personas, journey maps, and design requirements. This exercise asks you to practice that synthesis step.<\/p>\n<p><strong>Scenario<\/strong>:\u00a0 Imagine you\u2019ve just completed five interviews with students who use your university\u2019s online financial aid portal. Here are condensed findings from those interviews:<\/p>\n<ul>\n<li>Student A:\u00a0 \u00a0\u201cI never know where I am in the process. Did I submit everything? Is something missing? I just get silence until there\u2019s a problem.\u201d<\/li>\n<li>Student B:\u00a0 \u00a0\u201cI filled out the FAFSA on my phone because I was at work, and half the form didn\u2019t display right. I had to go home and redo it on my laptop.\u201d<\/li>\n<li>Student C:\u00a0 \u00a0\u201cMy parents don\u2019t speak English well, and they had to verify some of the financial information, but the portal doesn\u2019t offer anything in Spanish.\u201d<\/li>\n<li>Student D:\u00a0 \u201cEvery time I call the financial aid office, they tell me something different than what the portal says. I don\u2019t know which one to trust.\u201d<\/li>\n<li>Student E:\u00a0 \u201cI got an email saying my aid was adjusted, but when I logged in, nothing looked different. I still don\u2019t know what changed or why.\u201d<\/li>\n<\/ul>\n<p><strong>Your Task<\/strong>:<\/p>\n<p style=\"padding-left: 40px\"><strong>Identify<\/strong> three to four themes or patterns across these responses.<\/p>\n<p style=\"padding-left: 40px\"><strong>Write<\/strong> two concrete, evidence-based design requirements that address the most critical user needs. Follow the format described above: each requirement should be specific and tied to something you observed in the data. (For example: \u201cProvide a visible status tracker showing each step of the financial aid process and its current state.\u201d)<\/p>\n<p style=\"padding-left: 40px\"><strong>Identify<\/strong> one question you\u2019d want to investigate further, either through more interviews, a survey, or contextual inquiry. Explain what method you\u2019d choose and why.<\/p>\n<p><strong>Discussion: <\/strong>Compare your themes and requirements with a partner. Did you prioritize the same issues? How did you decide what was most critical? This is where the \u201clearn, build, test, revise\u201d cycle from Section 6.1 starts to become concrete.<\/p>\n<\/div>\n<\/div>\n<p>Taken together, the research methods in this chapter give you a practical way to move from guesswork to understanding. They help you see users more clearly, identify the problems that actually matter, and translate what you learn into personas, maps, and concrete design requirements a team can use. That\u2019s the through-line of UX research: creating user-centred decisions grounded in evidence, not assumptions.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"author":254,"menu_order":4,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["justin-lewis"],"pb_section_license":""},"chapter-type":[],"contributor":[67],"license":[],"class_list":["post-440","chapter","type-chapter","status-publish","hentry","contributor-justin-lewis"],"part":412,"_links":{"self":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/users\/254"}],"version-history":[{"count":8,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/440\/revisions"}],"predecessor-version":[{"id":780,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/440\/revisions\/780"}],"part":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/parts\/412"}],"metadata":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/440\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/media?parent=440"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapter-type?post=440"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/contributor?post=440"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/license?post=440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}