Website Usability Testing: Watch a Real Task, Then Decide What to Fix

Ask someone to find out whether your company serves their building. Watch where they look, what they read and how they reach an answer. You may learn more from that attempt than from asking whether they like the website.

Here is an original hypothetical example. Harbour Window Care is an invented business, and no participant sessions were conducted for this guide.

A suitable participant is someone who helps arrange maintenance for an office building. Give them this task:

“You’re arranging window cleaning for a three-storey office building in Toronto. Use this website to decide whether this company is suitable to contact. Show what information supports your decision.”

Now imagine they open Services, return to the homepage and then search the Contact page. They eventually find the service-area information after a hint from the facilitator.

The useful finding is specific: the person had difficulty locating information needed to assess fit, and the facilitator helped them find it. The next question is whether placing a clear coverage summary near the enquiry route would make that decision easier. “Customers hate the navigation” would go well beyond the example.

That is website usability testing in practice: give people a realistic task, observe their attempt and use what happens to improve the experience. The goal is to understand a task problem well enough to act on it.

What a usability test can answer

Usability testing is useful when you need to know whether people can find information, understand a choice or complete an action. It can reveal unclear labels, surprising navigation, missing instructions and recovery problems that a team familiar with the website overlooks.

It also shows how success can conceal effort. Someone may eventually request a quote after several detours and a mistaken start. Recording only “completed” loses the part of the experience that could be improved.

The method is less suited to questions such as whether a market wants your service or what price customers will pay. People can understand an offer and still decide it is unsuitable. For questions about buying situations and decisions, use customer interviews.

A reviewer inspecting the page without participants is conducting an expert review or audit. That can identify useful problems, but the predictions should not be reported as observed behaviour. The landing-page audit guide covers that earlier diagnostic pass.

A small usability round also cannot establish a conversion increase or certify an entire site as accessible. It can uncover a serious barrier, inform a repair and show how particular people approach a task. Those are valuable outcomes when described accurately.

The UK Government Digital Service’s moderated-testing guidance describes observation of relevant tasks with neutral instructions. The examples here apply that principle to a service-business website, with a deliberately bounded enquiry journey.

Choose a question the team can act on

“Test our website” is an invitation to collect a little information about everything. A more useful starting question is: “Can someone decide whether we serve their building and prepare a quotation request without help?”

That question tells you which pages matter, whom to invite and what the session should reveal. It also gives the team a practical decision afterward: change eligibility information, repair the request form or investigate a particular misunderstanding.

Choose a small set of connected tasks. For Harbour, the round can cover service fit, preparing an enquiry and understanding the confirmation. A study of that route does not need to assess every blog article, careers page and customer-support function.

Agree the endpoint. If the task ends before submission, success means a request is ready to send. It does not mean the form delivered an enquiry. If the task begins at a simulated confirmation, a correct interpretation does not establish a successful end-to-end submission.

Decide who will use the findings. A content lead can clarify service information. A developer can repair field behaviour. Operations must confirm what a request actually triggers. Involving those people early makes it less likely that research ends as a presentation nobody knows how to implement.

The GDS guidance on planning a research round connects actionable questions with planning and analysis. A short brief can cover the decision, intended participants, tasks, page version and important limits. Keep it useful enough to guide the work without making documentation the main activity.

Choose a session format that fits the question

In a moderated session, a facilitator is present. They introduce tasks, observe and ask neutral follow-up questions. This is useful when you expect unfamiliar language, complicated decisions or surprises that need clarification.

An unmoderated session gives people tasks to attempt without a live facilitator. It can be useful for focused, clearly written tasks, but you have fewer opportunities to clarify an unexpected action. A poorly worded task may remain confusing throughout the recording or response.

Remote and unmoderated are different choices. A live video session can be moderated remotely. An in-person session can also be structured with little intervention. Choose based on the research question and participant needs, rather than treating location as a method by itself.

For Harbour’s first round, moderated sessions are a reasonable proposal because the team wants to understand how people interpret eligibility and next steps. Notes may be sufficient. Recording is optional and should have a clear purpose, appropriate permission and handling arrangements.

A live site, staging site or prototype can all support useful work. Explain what is functional. If the prototype cannot search or submit, that limitation will affect the tasks it can answer. A realistic-looking button with no working destination can produce frustration unrelated to the eventual live experience.

Avoid adding software because it appears professional. A reliable session link, a usable task card and a prepared facilitator are more important than a complicated research setup. Use tools that participants can access and that meet your organization’s privacy and security requirements.

Recruit people who recognize the situation

The best participant for a task is someone whose circumstances make the task meaningful. For Harbour, that may be someone who has helped arrange building maintenance. They do not need to know Harbour’s terminology or website layout.

Ask about relevant experience. “What part have you played in arranging building maintenance?” is more useful than selecting participants solely by age or job title. “Which device would you normally use to investigate a new supplier?” can inform the session setup.

Friends and colleagues can help rehearse the script. They may also be suitable participants if their experience fits, but convenience alone does not establish that fit. Staff who know where every page lives bring a different perspective from unfamiliar prospective customers.

Existing customers and new prospects may both matter. Keep their familiarity visible when interpreting what happens. A returning customer might navigate quickly because they learned the route months ago. A first-time visitor may reveal a label that makes sense only after that learning.

Recruit across the circumstances that could materially change the task: building type, language, device, responsibility or access needs. You do not need to collect a detailed personal biography. Ask only what helps establish fit and make participation workable.

The GDS recruitment guidance is a useful primary reference for finding actual or likely users. In your report, state who was included and which important groups or situations remain unexamined. A round involving desktop users should not quietly become evidence about the whole mobile journey.

Make participation workable

Ask what people need to participate comfortably: breaks, a preferred communication format, their own device or an interpreter. Avoid requiring unnecessary medical or personal details to arrange access.

Compensation should reflect time and participation, rather than positive feedback. Explain what happens if someone stops early. Where a manager or customer relationship is involved, make declining practical and free from pressure.

For bilingual work, prepare tasks that make sense in the language being tested. English observations do not establish that the French route is understandable. Terminology, content and form behaviour can differ even when the design is shared.

How many participants do you need?

There is no fixed number that guarantees you have found every important issue. The answer depends on the variety of users and tasks, how likely a problem is to appear and the consequence of missing it.

For a focused early round, plan a manageable group and leave time to fix problems and return. Add coverage deliberately when an important scenario is absent or findings conflict. Repeating the same easy task with very similar people may tell you less than examining an untested route.

Laura Faulkner’s original research on usability sample sizes found substantial variation in the problems discovered by different small subsets of users. The lesson here is to avoid treating a small count as a promise of comprehensive coverage. It does not supply a universal sample requirement for your website.

An issue observed once can still matter greatly. If a legitimate user cannot complete a consequential task, investigate it. A common preference for a different colour does not automatically deserve priority over that barrier.

Report the scope plainly: who attempted which tasks, what happened and what is still unknown. Avoid converting a handful of sessions into a percentage claim about all customers. The value comes from understanding the problem and checking a repair, not making the study sound larger than it is.

Give participants a goal without naming the route

A good task sounds like a situation someone could actually face. It should tell them what they want to accomplish while leaving the route for them to discover.

Compare these prompts:

The leading versions test whether someone can follow directions. The revised versions reveal where they look and how they interpret what they find.

Keep the participant’s task separate from your definition of completion. The facilitator can know that coverage and building height must be understood without putting those exact navigation clues into the prompt.

Allow legitimate alternative routes. A participant who finds accurate information through site search has succeeded even if you expected them to use a menu. Your preferred path is not the only acceptable path.

Avoid making the scenario artificially precise in ways that supply the answer. If the website’s menu uses “commercial envelope services,” do not place that phrase in the task unless real customers would use it. A familiar problem expressed in ordinary language is more revealing.

Three task cards for the Harbour example

These cards are hypothetical teaching material. Adapt them to the real service and test environment before using them.

Task: decide whether to contact the business

Participant prompt: “You’re arranging window cleaning for a three-storey office building in Toronto. Use this website to decide whether this company is suitable to contact. Show what information supports your decision.”

What to watch: where the person looks, which conditions they notice and whether they can explain their conclusion. A confident answer based on the wrong service limit is different from an accurate answer reached after a detour.

Completion: the person reaches a supported decision about the building’s fit. If the service genuinely excludes the building, a correct decision not to contact the company can be successful completion.

Task: prepare a quotation request

Participant prompt: “You’ve decided to ask about a quotation for the building. Use the supplied sample details to prepare the request as you normally would. Stop before sending anything.”

What to watch: whether the person finds the route, understands the questions and can enter the fictional details. Notice guesses, uncertainty and errors, not just whether every box eventually contains something.

Completion: the request is ready to send using the supplied details, without directional help. The stopping point prevents a real enquiry and means delivery has not been tested.

Task: interpret the confirmation

Participant prompt: “For this separate task, imagine the sample request has been sent. Starting from this simulated confirmation screen, tell us what has happened and what you would expect next.”

What to watch: whether the person distinguishes an enquiry from a confirmed appointment and what wording creates that expectation.

Completion: their explanation matches the actual process represented by the screen. Reset everyone to the same starting screen, including anyone who could not prepare the form, so the confirmation question can still be examined. Keep it separate from the earlier task result.

Rehearse the session before inviting participants

Run the script with a colleague who has not written it. Check whether the task makes sense, whether the sample details are sufficient and whether the prototype supports the intended route.

This rehearsal is useful for finding preparation mistakes. If the task asks people to assess a building-height restriction that has not been added to the prototype, decide whether missing information is the question you intend to investigate or simply unfinished setup.

Check the safe boundary yourself. A staging form can still email the real sales team if someone connected it to production. A simulated calendar may unexpectedly create an appointment. Verify that the planned task cannot trigger an unwanted action.

Reset entered answers and navigation state between sessions. A previous participant’s search or expanded panel could make the next task easier. Record the page or prototype version so observations remain connected to what people actually saw.

Leave time between sessions to check notes, reset the environment and address practical problems. A packed schedule can encourage rushed consent, incomplete records and improvised task changes.

If a material change is necessary during the round, label the new version and report it. Do not quietly combine observations from different interfaces as if everyone used the same one. A correction can be sensible while still affecting how the results should be interpreted.

Notice what an earlier task teaches

Task order can change the experience. Once someone has found Harbour’s service-area page, a later eligibility question may be easier because they remember the route. That learning may reflect a natural connected journey, but it should not be mistaken for a first-time discovery.

If you want to examine two independent entry routes, consider separate starting states or varying their order. Keep track of the order used. With a small round, this helps interpretation without proving that every learning effect has been removed.

Timing needs similar care. A person who stops to discuss a question with the facilitator is no longer completing an uninterrupted task. Notes about a lengthy detour can be useful, but a loosely timed session should not become a precise speed benchmark.

Watch the sequence and consequence first. Did the person find the needed information? Did they recover from an error? What help changed the outcome? Those questions usually provide a clearer first repair than comparing seconds collected under different conditions.

Explain participation and protect the boundaries

Before the session, tell people who is organizing it, what you want to learn, who will attend and what information will be collected. Explain how notes or recordings will be used, who can access them and how long they will be kept.

Give people a way to ask questions, skip a task or stop. Explain withdrawal and any practical limits on removing material already processed or de-identified. Do not promise deletion you cannot carry out.

The GDS informed-consent guidance provides a practical research reference. Your organization still needs to establish applicable privacy and consent requirements for its own situation.

Participant codes help keep names out of findings, but they do not guarantee anonymity. Distinctive job details or a separate code key can identify someone. Collect the minimum detail needed and store recruitment contacts separately from the observation notes.

If you plan to record, transcribe automatically or add observers, explain that before seeking agreement. Do not add a new service during the session because it is convenient. Research participation also does not authorize turning someone’s comments into a public testimonial.

For the Harbour tasks, supply fictional details and stop before sending. If a participant starts entering a password, real customer information or another sensitive detail outside the agreed scope, interrupt. Protecting the participant takes priority over preserving an uninterrupted observation.

Facilitate without teaching the website

A facilitator’s instinct is often to help. During usability testing, a hint can remove the very difficulty you need to understand. Give people room to attempt the task while keeping the session respectful and comfortable.

An opening for the hypothetical notes-only session could be:

“We’re looking at how this website works. You can pause, skip a task or stop. We’ll take the notes described in the information sheet; we won’t record this session. Please use the supplied sample details and stop before sending anything. You can tell us what you’re looking for as you go, whenever that feels comfortable.”

Present one task at a time. Let the person read or hear it in the format that works for them. Do not insist on constant speech; someone may need to concentrate, read carefully or listen to assistive technology.

If they ask “Is this the right button?”, try “What would you expect it to do?” If they pause, wait before assuming they are stuck. A neutral prompt such as “What are you considering?” can help you understand the moment without naming the answer.

Avoid praise that steers behaviour. “Exactly, that’s the page we wanted” tells the person they have found your preferred route. A calm acknowledgment lets them continue without making the session feel like a quiz.

When someone cannot continue

Do not leave a participant struggling indefinitely. Offer to move on when they say they are stuck, when continuing would be unproductive or when a safety boundary is reached. If later steps matter, provide the minimum help needed and record it.

In the Harbour example, pointing to the coverage page allows the session to continue. It also means that part of the task was completed with route guidance. Keep that distinction instead of reporting an independent success.

Repeating the unchanged prompt is different from pointing to a menu item. An agreed interpreter or someone’s normal assistive technology is not automatically route assistance. Describe what actually changed the person’s knowledge of how to complete the task.

Ask follow-ups about what happened

“You returned to the homepage twice. What were you looking for?” is tied to an observed action. “Would a bigger button have helped?” introduces a solution and invites agreement.

A participant’s explanation can reveal an expectation, but it is still their account of the experience. It may not establish the technical cause. Preserve the action and explanation so the team can investigate both.

Brief observers to stay quiet, avoid visible reactions and route questions through the facilitator. Defending the design in front of a participant makes candid feedback harder. Save design discussion for after the session.

A short fictional session, choices explained

The following exchange is invented to demonstrate facilitation. It is not a transcript from a real participant. The task concerns preparing a quotation request for a standalone office building using sample details.

Facilitator: “Use these sample details to prepare the request. Stop before sending anything.”

Participant: “It asks for a unit number. This building doesn’t have one. Should I put zero?”

The facilitator should resist inventing a workaround. Saying “Yes, zero works” would hide the question the form created and might introduce an incorrect operational detail.

Facilitator: “What would you normally do here?”

Participant: “I’d leave it blank.”

The person tries to continue and receives a message saying the field is required. They look at the sample details again, then say they cannot provide an answer.

At this point, the observation is already useful. A valid scenario has reached an irrelevant requirement. The facilitator does not need to make the person spend the rest of the session attempting different invented numbers.

Facilitator: “Let’s pause that task. For the next part, I’ll open a separate example confirmation screen.”

The notes should say that the form-preparation task stopped at the required unit field. The confirmation task begins from a supplied state. If the person later understands that screen, it does not retroactively make the earlier task successful.

Now imagine the confirmation reads “You’re all set” in large type, with “We have received your quotation request” in smaller text.

Facilitator: “What has happened, and what would you expect next?”

Participant: “I think they’ve booked the visit. I’m not sure when.”

Facilitator: “What on the screen gave you that impression?”

This follow-up seeks the cue, rather than announcing that the interpretation is wrong. If the participant points to the large heading, the team gains a concrete wording and hierarchy question to investigate. The observation alone still does not prove that every visitor will interpret the screen that way.

A less useful facilitator response would be “Actually, it’s only an enquiry. Can you see the smaller sentence?” That teaches the intended meaning before the team has understood the original interpretation.

The session can end with a neutral chance to add anything unclear. The participant should not have to defend their reading or persuade the designer that their difficulty is legitimate. The team can review the design after the person leaves.

Include access needs without a single universal test

A participant who uses a screen reader, magnification, voice input or another interaction method may reveal barriers that a mouse-based review misses. Plan the session so they can use an appropriate setup and participate without unnecessary adaptation to the observers’ convenience.

Ask about practical needs rather than diagnoses. Joining instructions, consent information and task cards should also be usable. A well-prepared website task is of little help if someone cannot access the meeting or read the information explaining participation.

W3C’s guidance on involving users in accessibility evaluation explains both the value and limits of participant involvement. One person’s experience cannot stand for everyone with similar access needs, and user observation does not replace standards-based evaluation.

If a task breaks, record the relevant interaction and environment. The page, browser, assistive technology or an interaction between them may need investigation. Do not guess the cause or describe the participant’s normal way of working as the problem.

Useful assistance should not be confused with coaching. Providing an agreed accessible task format enables participation. Telling someone which hidden menu item contains the answer changes the task evidence. Keep that distinction clear when discussing completion.

A barrier can warrant action even when it appears in one session. The research report should state the observed consequence and route it to the appropriate specialist, without requiring a large occurrence count before the team takes exclusion seriously.

Take notes that preserve what you saw

Separate observation, interpretation and proposal. They are related, but they answer different questions.

These are fictional examples, not a log from completed sessions. They show why “the navigation is confusing” loses useful information: it collapses the action, explanation and proposed solution into one judgement.

Use a participant code, task name and page version. Record the important sequence, whether the task was completed and any help supplied. You do not need a new classification system to begin.

The GDS note-taking guidance emphasizes observations and clear session context. Keep quotations exact when you record them as quotations. A paraphrase is useful too, provided it is identified as your summary.

Do not count every repeated click as another person encountering a problem. Several unsuccessful attempts can belong to one task. Likewise, a participant who never reached a confirmation screen cannot tell you whether that screen was understandable.

Review notes soon after the session while the sequence is fresh. Resolve uncertainty with the observer or recording if available and permitted. If you cannot establish what happened, retain the uncertainty rather than filling the gap with a plausible memory.

Turn the fictional observations into specific fixes

Harbour’s sample tasks reveal three different kinds of issue. Each calls for a different response.

Coverage is difficult to locate. The proposed repair is to make relevant service limits available where a visitor evaluates fit, perhaps through a short summary and a clear route to detail. The retest asks whether people can find and interpret the information, rather than whether they click a particular link.

A unit-number field blocks a legitimate building. Confirm whether operations needs a unit number for every request. If not, make it optional or conditional as appropriate. Test that a standalone-building request can proceed while a multi-unit request still carries the information the team needs.

A receipt sounds like a booking. First confirm what submission actually does. If it creates an enquiry, the confirmation should say so and explain the next step. Do not invent a response deadline or appointment guarantee merely to make the wording reassuring.

The fixes differ because the evidence differs. One concerns information location, one concerns a form rule and one concerns the meaning of a message. A general recommendation to “simplify the website” would not tell the team what to implement.

Prioritize the consequence. A blocked valid request or materially mistaken booking expectation can deserve prompt attention even if it appeared in one session. Navigation detours may also matter, but their effect should be described rather than assigned an arbitrary numerical score.

Discuss alternatives before committing to a large redesign. A new coverage block could help discovery but add clutter. Removing the unit field everywhere could harm multi-unit enquiries. Choose the smallest change that addresses the observed problem while preserving necessary information.

Find the differences behind conflicting observations

When one person completes a task easily and another struggles, avoid treating the difference as noise to remove. It may reveal something important about the task or the website.

Compare the circumstances. Was one person an existing customer? Did they use a different device? Did an earlier task reveal the information? Were the sample buildings different? A required unit field may affect standalone buildings while posing no difficulty for offices in multi-unit properties.

Review the session wording too. If the facilitator named a menu item in one session but stayed neutral in another, the attempts no longer provide the same opportunity to observe navigation. Keep the clarification in the record and decide whether a fresh attempt is needed.

Do not force every difficult moment into one explanation. A person may fail to find a policy because the label is unfamiliar, because the page omits the information or because the task itself is unclear. Those possibilities lead to different repairs.

The GDS analysis guidance supports reviewing observations and developing findings with the team. In practice, put the relevant notes together, describe the pattern and keep contradictory evidence visible. The useful output is a reasoned finding, not a collection of matching sticky-note colours.

If the evidence cannot separate two plausible causes, design the next check around that uncertainty. For Harbour, the team might first confirm that coverage information is complete, then observe whether unfamiliar visitors can find it. That is more focused than redesigning every menu because two navigation paths differed.

Check the repair with the right evidence

A developer can verify that the revised form accepts a standalone-building sample. A participant can show whether the revised question makes sense without coaching. Those checks complement each other.

Retest the original task with the revised page. Fresh participants help reveal whether the repair works without remembering the earlier route. Returning participants can provide useful feedback, but keep their prior exposure visible.

Maintain the task’s meaning and completion criteria where possible. If you change the task, audience and page together, the next round may still be informative, but it becomes harder to explain why the experience differs.

Inspect surrounding behaviour too. A new eligibility summary may help one decision while pushing another important explanation farther away. A clearer confirmation heading may still be undermined by a contradictory email. Follow the relevant route far enough to understand those effects.

Do not call the repair a conversion win solely because a later session looks easier. To evaluate business outcomes, use an appropriate measurement design and consistent definitions. Usability testing can justify a clear repair while its commercial effect remains unmeasured.

The usability-study templates include a facilitator script, blank and fictional planning files, observation sheets and issue records. They are manual aids. Their example data and file checks do not represent participant research or a live website test.

Share findings in the order the team needs them

Lead with the decisions: what needs fixing, what needs investigation and what worked well enough to preserve. Follow with short examples from the actual sessions, using only material participants agreed could be shared with that audience.

Describe the participants and tasks without exposing unnecessary identifying details. Include the page version, assistance given and important coverage gaps. Keep a skipped task distinct from an unsuccessful attempt.

Avoid a highlight reel that shows only the most dramatic moments. Include observations that challenge your preferred interpretation. If some people found coverage easily while others struggled, examine what differed instead of forcing a single explanation.

Give each proposed repair a responsible owner and a clear check. “Allow a standalone-building request without a unit number” is more actionable than “improve forms.” Make the next research question equally specific when the cause remains unresolved.

A useful round ends with the team understanding a real task more clearly. Watch, listen, make a focused change and return to the task. If you need help turning observed friction into a practical repair plan, explore Canada Create’s conversion-rate optimization services.

Frequently asked questions

How can I test the usability of my business website?

Give someone who fits your audience a realistic task, then watch their attempt without coaching them. Start with a question the team can act on, such as whether a visitor can decide that you serve their building and prepare a quote request without help. That question tells you which pages matter, whom to invite and what each session should reveal.

What is website usability testing in simple terms?

Website usability testing means asking a real person to complete a task on your site and observing what happens. You watch where they look, what they read and how they reach an answer, then use that to improve the experience. It shows whether people can find information, understand a choice or finish an action, which is different from asking whether they like the design.

What does a usability test look like on a service business website?

The guide uses an invented window cleaning company and asks a participant to decide whether it suits a three-storey office building in Toronto. The participant opens Services, goes back to the homepage, searches the Contact page and only finds the service area after a hint. The useful finding is narrow: information needed to judge fit was hard to locate. The next step is testing whether a coverage summary near the enquiry route makes that decision easier.

Are five participants enough for a website usability test?

No fixed number of participants ensures that a round has found every important issue. The right count depends on how varied your users and tasks are, how likely a problem is to show up and what it costs to miss it. Laura Faulkner's research found that different small groups of users uncovered quite different problems, so a small count is no promise of full coverage. Plan a manageable first round, fix what you find and add people where a key scenario is missing.

How is website usability testing different from user acceptance testing?

User acceptance testing checks whether a finished system does what was agreed before it goes live. Usability testing asks whether real people can find information, understand choices and complete a task, and it can reveal unclear labels or recovery problems even when every feature works as specified. A form can pass acceptance checks and still confuse a first-time visitor who cannot tell what happens after sending it.

Should a website usability test be moderated or unmoderated?

Choose moderated sessions when you expect unfamiliar wording, complicated decisions or surprises that need a neutral follow-up question. Unmoderated sessions suit focused, clearly written tasks, but there is no chance to clarify an unexpected action, and a poorly worded task stays confusing for the whole recording. Remote and unmoderated are separate choices, since a live video call can still be moderated.

How do you measure website usability without overstating it?

Record what happened on each task, including detours, mistaken starts and any hint the facilitator gave, because a bare completed mark hides the effort. Report who attempted which tasks, what went wrong and what remains unknown. Avoid turning a handful of sessions into a percentage about all customers. A small round can uncover a serious barrier, but it cannot prove a conversion increase or certify the whole site as accessible.

What questions should I ask during a website usability test?

Write tasks as goals someone could actually have, such as deciding whether the company can help with a building, and leave the route for them to find. Avoid instructions like click Service Areas, because those only test whether a person can follow directions. Afterwards, ask neutral follow-ups about what happened on screen and what they expected next instead of asking whether they liked the page.

How do I improve website usability after a test round?

Turn each observation into a specific repair, such as moving coverage details near the enquiry form or fixing a field that rejects valid input. Involve the people who can act early: a content lead for service information, a developer for field behaviour and operations for what a request actually triggers. Then check each repair with evidence that fits it, and share findings in the order the team needs them.