Write a testable opportunity brief

Journey maps and interviews produce a list of questions, but a decision owner needs a statement of what is worth testing now. An opportunity brief is not a project name or a purchase request. It describes who faces an obstacle, in what task, on what evidence, and what outcome should improve under defined constraints. “Launch a smart booking app” chooses a solution before alternatives have been compared. “Improve everyone's experience” gives the team no starting point or test. Useful boundaries make a proposed direction revisable when new evidence appears.

Use five elements: the user segment and job, baseline, evidence and confidence, measurable desired outcome, and what is outside the experimenter's mandate. In the fictional library, the segment is a visitor trying to book a room within the next two days. The job is to understand availability and submit a request whose result is clear. Defined logs show 54 submissions among 90 calendar viewers, on the assumption that they are unique people in one week. Small interviews suggest some confusion about “provisionally available” but cannot estimate its prevalence. A desired outcome could be a higher share of visitors who complete a valid request without help, provided ineligible bookings do not increase. Do not promise a percentage improvement before testing, or treat the wording as the sole established cause.

Choose a primary measure and a guardrail measure. The primary measure tests the uncertainty relevant to the decision: for example, the proportion completing a valid request in an observed session from seeing the calendar to receiving a clear confirmation. Its denominator is people who began that task in the sample, not every library website visitor. A guardrail detects an adverse effect that might make an apparent gain misleading, such as more ineligible bookings or complaints about hidden eligibility conditions. Do not choose click count merely because it is easy to collect; clicks may fall because people give up. State each measure's source, period and decision owner if harm appears. These are measures for learning in a bounded experiment, not a commercial promise or accredited learning hours.

The specialist has an authority boundary. They may be able to prepare an offline wording prototype or propose a test with consenting visitors, but cannot unilaterally change room-eligibility rules or expand personal-data collection. Write “service-owner decision required” next to a policy change and “privacy and accessibility review” when a test needs screen recording or a new interface. Include a time and budget limit only if one has actually been granted. If resources have not been specified, mark them unknown and ask the sponsor to set them before live implementation.

Before circulating the brief, draw a simple decision chain: what may the specialist do now, what observation requires revision or stopping, and what needs an authorized signature? Make the triggers specific. If prototype participants cannot distinguish “available” from “confirmed,” revise the text before any live test. If clearer text obscures eligibility conditions, do not improve completion at the cost of invalid bookings; review the condition with the service owner. This connects the outcome measure with the guardrail and prevents optimizing one number while degrading the service.