FOCUS
The awkward cases are the specification. The happy path is the summary.
What is FOCUS?
FOCUS is five slots: Function, Outcome, Context, Usability, Simplicity. It is for writing a feature specification, and two of its slots are doing work that most specs skip: the one about how the feature behaves when things go wrong, and the one about what you are deliberately not building.
A specification that describes the happy path is a summary of an idea. Everybody already agrees what bulk editing does; nobody agrees what happens when a bulk reschedule would fail for three of forty jobs — and that is the question an engineer will hit on the second day and answer alone if you have not. Usability is where the specification actually lives. Partial selection, mixed types, half-succeeding operations, the conflict that only affects some rows. Writing those down is the difference between a document that saves a conversation and one that starts several.
Where FOCUS Came From
A modern product convention with no author of record
FOCUS has no documented inventor. It sits in the product-management tradition of structured requirements documents, compressed into five letters, and belongs to the same assembled pool as TAG and SCOPE. The word itself is generic enough that searching it returns advice about attention rather than about specifications.
Its distinguishing slot is Simplicity, read as exclusion
The name suggests minimalism as an aesthetic, which would be a weak fifth slot. Read as what is deliberately out of version one, and why, it becomes the most useful part of the document — because a specification with no exclusions has not made any decisions, and everything in it will be argued about later at greater cost.
Why Outcome is separate from Function
Function is what the software does; Outcome is the job the user completes. They diverge more often than teams expect. "Select multiple jobs and apply a change" is a function. "Reschedule a rained-off day in one action instead of forty" is the outcome, and it is the sentence that tells an engineer which trade-offs are acceptable when the two conflict.
The 5 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
State the boundary. A function described only by its capability expands during implementation, because every adjacent case looks like it belongs. Saying explicitly that this applies to scheduled jobs and not to recurring templates costs one clause and prevents a week.
Written as the thing they were trying to do on Monday morning. This is the sentence engineers use to resolve ambiguity without asking, so it should be concrete enough to arbitrate: if the outcome is rescheduling a whole rained-off day in one action, then an implementation that handles thirty jobs and refuses at forty has failed even though it works.
The details that look like colour and are actually constraints. This happens on a Monday morning, under time pressure, often on a phone in a van. Each of those changes a design decision, and none of them will be discovered by a team who have not spoken to the customers.
The specification. Everything above it is the summary. Partial selection, mixed job types, a change that would fail for some rows. Every rule here should be an observable behaviour an engineer could write a test for — and the partial-failure rule is the one that decides whether the feature is trusted, because a bulk operation that fails the whole batch for one conflict will not be used twice.
The slot that makes the document a set of decisions rather than a wish list. Name what you are not doing and give the reason, because an unstated exclusion gets built by a helpful engineer or argued about in review. "No undo in v1, because the audit log already lets support reverse a batch" closes the question.
One Task, Before and After
The task: A bulk-edit specification for a job-scheduling tool. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write a spec for bulk editing.
Six words. You get a clean description of selecting several jobs and applying a change, with nothing about what happens when the change fails for three of forty.
Write a feature specification using Function, Outcome, Context, Usability, Simplicity. The feature: bulk editing in a job-scheduling tool used by trade businesses. Currently users edit one job at a time. Support gets roughly 30 requests a month for this, mostly from customers with more than 40 jobs a week who are rescheduling after a weather day. Function - what it does, precisely, including what it does not do. The boundary is more useful than the capability. Outcome - what a user can achieve that they could not before, stated as a job rather than a feature: rescheduling a rained-off day in one action instead of forty. Context - when and where this is used. It matters that this happens under time pressure, on a Monday morning, often on a phone in a van. Usability - how it behaves in the awkward cases: partial selection, mixed job types, a bulk change that would fail for three of forty jobs. This section is the specification; the rest is the summary. Simplicity - what you are deliberately leaving out of version one, and why. A feature spec with no exclusions has not made any decisions. Write 800 to 1,000 words in five headed sections for two engineers and a designer who have not spoken to these customers. Reason through the failure cases before you write the happy path, since a bulk operation that half-succeeds is the actual design problem and the rest is straightforward. For example, specify the awkward case like this: ``` If a bulk reschedule would fail for some jobs (engineer unavailable, customer window conflict), apply the rest and show which failed and why. Never fail the whole batch for a partial conflict. ``` Every rule must be testable without asking the author what was meant, and the spec must state what happens when a bulk operation partially fails. Ensure every behaviour in Usability is stated as an observable rule an engineer could test, and prioritise the rescheduling case the support requests actually describe. Do not invent user research, adoption estimates or competitor behaviour, and do not specify anything about the visual design.
Ninety-two. The partial-failure rule is the specification; without it an engineer invents an answer on day two and a bulk operation that refuses the whole batch never gets used twice.
Ninety-two, and a spec with no failure cases would score the same
One check is out of reach, and the property that separates a usable specification from a description is unmeasured:
No persona slot. Eight points available and a product-manager persona adds nothing here — the document is read by engineers who will test it against reality, not against tone.
The whole specification, and invisible. A fluent description of the happy path scores exactly as well as a document that rules on partial failure, mixed selection and conflict. Only the second prevents an engineer inventing the answer on day two.
"The interface should be intuitive" and "never fail the whole batch for a partial conflict" score identically. One can be written as a test; the other is a preference.
The habit worth taking into any specification: write the failure cases before the happy path. Everyone agrees what the feature does — the document exists for the questions where they do not, and those all live in what happens when the operation only half works.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
[The feature, and the evidence for it — support requests, the real use case, the numbers] Function: [what it does, INCLUDING what it does not. The boundary is the useful half] Outcome: [the job the user completes, not the capability they gain] Context: [when and where — time pressure, device, conditions. These are constraints] Usability: [THE SPECIFICATION. Partial selection, mixed types, partial failure. Every rule an observable behaviour someone could test] Simplicity: [what is deliberately OUT of v1, and why] [Write the failure cases before the happy path] [No invented user research, adoption estimates or competitor behaviour. Say nothing about visual design]
When FOCUS Fits — and When It Does Not
- Feature specifications and requirements documents for engineers who were not in the room.
- Bulk and batch operations, where partial failure is the whole design problem.
- Features with a known support-request history, which tells you the real use case.
- Anything where scope will expand during implementation unless bounded.
- Handover documents for work somebody else will build.
- Interface copy. Use BINGO — FOCUS specifies behaviour, not words.
- Developer documentation for an existing API. Use PRIME.
- Exploratory or research work where the feature is not defined. Use IDEA or SCOPE.
- Visual design, which FOCUS deliberately says nothing about.
- Trivial changes, where five slots is more document than the work.
10 Ready-Made FOCUS Prompts
Every prompt below was produced by the Frompting generator with FOCUS selected — not written by hand for this page. Each is scored by our prompt checker; the median is 82/100. Click one to open it, then copy.
A feature spec for bulk editing 82
You are a product specification writer. Your task is to create a detailed feature specification for a bulk‑editing capability. The specification should: 1. Describe precisely what the bulk‑editing feature will do, including the actions users can perform on multiple items at once. 2. Explain the expected results and business value, such as time saved, error reduction, or increased throughput. 3. Outline the situations in which the feature will be used, including typical user roles, data types, and any relevant workflow steps. 4. Define how users will interact with the feature, covering UI elements, interaction patterns, accessibility considerations, and error handling. 5. Keep the design as simple as possible while still meeting the functional and usability goals, avoiding unnecessary steps or options. Write the specification for **[AUDIENCE]:** the primary users of this feature (e.g., content editors, administrators, etc.). Assume the feature will be integrated into an existing system that supports **[TECHNOLOGY STACK]:** (e.g., web app with React, REST API, etc.). Deliver the output as a markdown document with the following sections in order: - **Feature Overview** (≈150 words) - **Business Outcome** (≈100 words) - **Use Context** (≈150 words) - **User Interaction Design** (≈200 words) - **Simplicity Guidelines** (≈100 words) Quality criteria: - All functional details are explicit and unambiguous. - The user interaction description is clear enough for designers to prototype without further clarification. - The specification balances technical feasibility with a streamlined user experience. Exclude any implementation code, low‑level technical diagrams, or platform‑specific branding. If any critical detail is missing, state the assumption and ask up to three clarifying questions before finalizing.
User stories for a notifications system 87
You are a product manager tasked with crafting a concise, well‑structured set of user stories for a notifications system. Write three user stories that together describe the core functionality, the desired outcome, the operating context, usability considerations, and the simplicity constraints of the system. Each story should be no more than 120 words and follow the pattern: 1. **As a** [USER_ROLE: specify the primary user role] **I want** [brief description of the notification feature] **so that** [clear business or user outcome]. 2. Include a short acceptance criteria list (2‑3 items) that captures functional expectations, contextual triggers, usability goals, and simplicity requirements. **Quality criteria** - Stories are clear, testable, and reflect a single, coherent need. - Acceptance criteria are specific, measurable, and prioritize essential behavior over optional enhancements. - Language is concise, avoids unnecessary jargon, and each story stands alone yet fits into an overall coherent notifications capability. **Boundary**: Do not elaborate on implementation details such as code architecture, data models, or third‑party services. If any of the placeholders above are unknown, state your assumption and proceed, or ask up to three clarifying questions before completing the user stories. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
A feature spec for single sign-on 77
You are a product specification writer. Create a detailed feature specification for a Single Sign‑On (SSO) capability. First, describe the core purpose of the SSO feature, what problem it solves and the primary business value it delivers. Next, outline the expected results: how the feature will improve user authentication flow, reduce login friction, and support security goals. Then, provide the operational setting: the systems, applications, and user groups that will use SSO, including any relevant environments or constraints. After that, detail the user experience requirements: login steps, error handling, session management, and any accessibility considerations. Finally, list the essential simplicity criteria: minimal configuration, clear documentation, and straightforward maintenance procedures. [AUDIENCE: specify the primary user group (e.g., internal employees, external customers, partners)] [INTEGRATION_TARGETS: list the applications or services that must support SSO] [SECURITY_STANDARDS: indicate any compliance or security frameworks to adhere to (e.g., OAuth2, SAML, OpenID Connect)] Deliver the specification in markdown with clear headings for each section, using concise bullet points where appropriate. The total length should be between 800 and 1,200 words. Quality criteria: technical accuracy, completeness of user‑flow details, and clarity for both engineering and product teams. Exclude any implementation code or UI mockups; focus solely on the specification narrative. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.
Requirements for an export function 80
You are a product requirements writer tasked with creating a concise, actionable specification for an export function. Follow the steps below in order, producing a single document of approximately 300 words. 1. Begin by describing precisely what the export feature must do, including the type of data to be exported ([EXPORT_DATA_TYPE: e.g., user records, transaction logs]) and the intended audience ([TARGET_USERS: e.g., administrators, end‑users]). 2. State the desired business and technical outcomes of the feature, such as improved reporting efficiency or compliance support. 3. Outline the operational context: where the feature will be accessed (e.g., web dashboard, mobile app), any integration points, and relevant constraints like the export format ([EXPORT_FORMAT: e.g., CSV, JSON]) and security considerations ([SECURITY_CONSTRAINT: e.g., role‑based access, data masking]). 4. Detail usability requirements: user interface flow, default settings, error handling, and any accessibility needs. 5. Conclude with simplicity guidelines that keep the implementation lean—limit configurable options, avoid unnecessary steps, and define performance expectations ([PERFORMANCE_REQUIREMENT: e.g., export completes within 5 seconds for 10 k records]). **Output format**: plain text with clear paragraph breaks for each step; no headings or labels are needed. **Quality criteria**: - Requirements are specific, measurable, and testable. - Language is concise and free of ambiguous terms. - The document balances technical feasibility with a smooth user experience. **Boundary**: Do not include low‑level implementation code or UI mock‑ups; focus solely on the specification. If any of the placeholders above are unknown, state your assumption and proceed, or ask up to three clarifying questions before finalizing the requirements.
A feature spec for mobile offline mode 81
You are a senior product manager drafting a detailed feature specification for a mobile app’s offline mode. Your task is to produce a clear, structured spec that guides design, engineering, and QA teams. Follow the logical flow below, ensuring each section naturally leads to the next: 1. **Describe the core functionality** of the offline mode, including what data and actions must be available when the device has no network connection. 2. **State the expected outcomes**, such as user satisfaction targets, performance metrics, and business impact (e.g., retention increase). 3. **Provide the operational context**, covering typical usage scenarios, environmental constraints, and any dependencies on other system components. 4. **Detail usability requirements**, specifying UI/UX expectations, error handling, and user feedback mechanisms while offline. 5. **Outline simplicity constraints**, focusing on minimal technical complexity, maintainability, and clear hand‑off points between offline and online states. **Deliverable:** a markdown document (≈ 600 words) with the sections above as top‑level headings. Include a concise bullet list of acceptance criteria at the end. **Quality criteria:** - All functional statements are unambiguous and testable. - Metrics and outcomes are quantifiable (e.g., “≤ 2 seconds to load cached content”). - The spec balances technical feasibility with a smooth user experience. **Boundary:** Do not include implementation code, API definitions, or detailed UI mock‑ups; focus on requirements and rationale only. If any of the following are unclear, state your assumption and then ask up to three clarifying questions before finalizing the spec: - **Target audience** for the spec (e.g., engineering team, cross‑functional stakeholders). - **Maximum size of data** that must be cached offline. - **Primary platforms** (iOS, Android, both) and any device‑specific constraints.
Requirements for a permissions system 83
You are a product requirements specialist. Your task is to draft a concise, structured set of requirements for a permissions system. First, define the core purpose of the system, describing the primary capabilities it must provide. Next, articulate the desired results, specifying how the system should behave for users and administrators, including any compliance or security objectives. Then, outline the environment in which the system will operate, noting any relevant integration points, data sources, or operational constraints. After that, detail the user interaction expectations, covering how users will request, receive, and manage permissions, as well as any audit or notification features. Finally, emphasize the need for a streamlined design, focusing on minimal complexity while ensuring reliability and maintainability. The output should be formatted as a markdown document with the following sections in order: - Purpose - Desired Outcomes - Operating Context - Usability Considerations - Simplicity Guidelines Each section should contain 3–5 bullet points, each bullet limited to 20 words or fewer. Quality criteria: 1. Requirements are clear, testable, and unambiguous. 2. Language is precise yet accessible to both technical and non‑technical stakeholders. 3. No unnecessary technical jargon is introduced without brief explanation. Exclude any implementation details, code snippets, or platform‑specific references. If any essential information is missing, state your assumptions explicitly and ask up to three clarifying questions before completing the draft. [AUDIENCE: Specify the primary readers of these requirements, e.g., developers, product managers, compliance officers] [INTEGRATION POINTS: Identify any systems or services the permissions system must connect with] [COMPLIANCE STANDARDS: List any regulatory or security standards that must be met]
A feature spec for a reporting dashboard 81
You are a senior product analyst tasked with drafting a comprehensive feature specification for a reporting dashboard. The specification must: - Clearly describe the dashboard’s purpose and the business problem it solves. - Define the measurable outcomes expected from the dashboard (e.g., key metrics, decision support goals). - Outline the operational context, including primary user roles, data sources, and integration points. [USER_ROLE: specify the main user persona(s) who will use the dashboard] [DATA_SOURCE: list the systems or databases the dashboard will pull data from] [INTEGRATION_POINT: indicate any external tools or APIs the dashboard must connect to]. - Detail usability considerations such as navigation flow, visual hierarchy, filter and drill‑down capabilities, and accessibility requirements. - Emphasize simplicity by prioritizing essential visualizations, minimizing configuration steps, and defining performance targets (e.g., load time < [LOAD_TIME_THRESHOLD] seconds). Output format: - A markdown document with the following sections in order: Purpose, Expected Outcomes, Context, Usability, Simplicity. - Each section should be concise: total length 300–400 words. - Include a brief bullet list of any assumptions made and up to three clarifying questions needed to finalize the spec. Quality criteria: 1. All statements are actionable and can be directly translated into development tickets. 2. Metrics and performance targets are realistic and measurable. 3. The document is clear for both technical and non‑technical stakeholders, using precise terminology where appropriate. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
Requirements for an audit log 89
You are a product requirements specialist. Your task is to create a concise, structured set of requirements for an audit log that will guide developers and stakeholders in building a reliable, secure, and user‑friendly logging feature. The deliverable should be a markdown document no longer than 350 words, organized into clear sections that flow naturally from purpose to implementation details. Include: * A brief description of the audit log’s purpose and the problems it solves. * Specific, measurable outcomes the log must achieve (e.g., tamper‑evidence, query performance). * The operational context in which the log will be used, covering relevant systems, data types, and compliance regimes. * Usability considerations for both technical (developers, security analysts) and non‑technical users (auditors, managers). * Simplicity guidelines that keep the design lean while meeting the above needs. **Quality criteria** 1. Each requirement is written as a single, testable statement. 2. Technical terms are defined or clarified on first use. 3. The document is scannable, using headings and bullet points where appropriate. **Boundary** – Do not include implementation code, UI mockups, or detailed deployment scripts. If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: brief hint]** and proceed with the assumption that the missing information will be supplied later: * [SYSTEMS: list of applications or services that will generate log entries] * [COMPLIANCE: specific regulations or standards the audit log must satisfy] * [RETENTION: required retention period for log data] * [ACCESS_ROLES: user roles that need read or write access to the log] * [PERFORMANCE: expected query response time or volume of log entries] Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A feature spec for search 79
You are a product specification writer. Create a detailed feature specification for a search function. First, describe the core purpose of the search capability and the primary problem it solves. Next, define the measurable results expected from the search feature, such as accuracy, speed, or user satisfaction targets. Then, outline the environment in which the search will operate, including any relevant system constraints, data sources, and integration points. After that, detail the user interaction flow, covering input methods, result presentation, filtering options, and error handling to ensure an intuitive experience. Finally, list the essential design and implementation constraints that keep the feature lean, such as minimal required UI elements, performance limits, and technology choices. Produce the specification in markdown with the following sections in order: - Purpose - Success criteria - Operating context - User interaction design - Implementation constraints The entire document should be between 300 and 400 words. Quality criteria: 1. Clear, concise language suitable for both engineers and product managers. 2. Each section directly supports the next, forming a logical progression. 3. Include at least one concrete example illustrating how a user would perform a search. Exclude any assumptions about the target audience, platform, or existing infrastructure; instead, insert placeholders: [AUDIENCE]: brief description of the primary user group (e.g., end‑users, administrators) [DATA_SOURCE]: description of the data set to be searched (e.g., product catalog, knowledge base) [PERFORMANCE_TARGET]: desired response time or throughput metric (e.g., <200 ms) State any assumptions you make about these placeholders before delivering the final specification.
Requirements for a bulk import tool 87
You are a product requirements specialist tasked with drafting a concise, well‑structured set of requirements for a bulk import tool. First, describe the core purpose of the tool, detailing the primary function it must perform. Next, specify the measurable outcomes the tool should achieve, such as data accuracy targets, processing speed, and error‑handling expectations. Then, outline the operational context: the environments in which the tool will run, the types of data sources it must accept, and any integration points with existing systems. After that, define the usability criteria, including the user roles who will operate the tool, the required user interface elements, workflow steps, and any accessibility considerations. Finally, enumerate the simplicity constraints, focusing on minimal configuration, clear error messages, and ease of maintenance. Produce the requirements in plain markdown using numbered sections for each of the five parts above, with bullet points for individual items. Limit the total length to **approximately 350 words**. Quality criteria: 1. Each requirement is clear, testable, and unambiguous. 2. Technical details are precise while remaining understandable to non‑technical stakeholders. 3. The document follows a logical flow from purpose to simplicity. Exclude any implementation code, UI mockups, or vendor‑specific product names. If any essential detail is missing, state your assumption explicitly and ask up to three clarifying questions before finalizing the requirements. [DATA_SOURCES]: list the formats (e.g., CSV, JSON, XML) the tool must ingest. [PERFORMANCE_TARGET]: desired maximum time to import a typical dataset (e.g., 5 minutes for 100 k records). [USER_ROLE]: primary user(s) who will operate the tool (e.g., data analyst, system admin). [SECURITY_LEVEL]: required security measures (e.g., encryption at rest, role‑based access). [INTEGRATION_POINT]: existing system or database the tool must connect to. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
Scores range from 77 to 89. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
FOCUS vs the Alternatives
The documentation counterpart. FOCUS specifies something not yet built; PRIME documents something that exists, for the developer integrating it.
The general briefing framework. TRACE commissions a deliverable from an agency; FOCUS specifies a feature for a team.
What the user reads while using what FOCUS specified. Different documents, same feature.
What comes before, when the feature has not been chosen. IDEA selects; FOCUS specifies.
For planning an investigation rather than a build. Both insist on stating constraints early and on saying what is out of scope.
Five Ways People Get FOCUS Wrong
The defining FOCUS failure. Everyone already agrees what the feature does. The document exists for partial failure, mixed selection and conflict — write those first.
Worth calling out as a design mistake and not just a documentation one. A bulk operation that refuses entirely because three of forty rows conflict will not be used a second time.
"Intuitive", "fast", "clean" are preferences. Every rule in the Usability section should be an observable behaviour someone could write a test for without asking what you meant.
A specification with nothing in the Simplicity section has made no decisions, and every omission will be either built by a helpful engineer or argued about in review.
"Used by trade businesses" is a segment. "On a phone, in a van, on a Monday morning, in a hurry" is a constraint, and it changes the design.
If your Outcome section says "users can bulk edit", you have written Function twice and lost the sentence engineers use to resolve ambiguity.
FOCUS Questions
What does FOCUS stand for?
Function, Outcome, Context, Usability, Simplicity — five slots for a feature specification.
Which section is the actual specification?
Usability. The rest is a summary everybody already agrees with. The decisions live in how the feature behaves under partial selection, mixed types and partial failure.
What is the difference between Function and Outcome?
Function is what the software does; Outcome is the job the user completes. They diverge, and the Outcome sentence is what an engineer uses to arbitrate when they do.
Why does Simplicity mean exclusions?
Because read as an aesthetic it is a weak slot, and read as "what is out of version one and why" it is the most useful part of the document. A spec with no exclusions has made no decisions.
How specific should Context be?
Specific enough to constrain design. "On a phone in a van on a Monday morning" changes decisions; "used by our customers" does not.
Should the spec cover visual design?
No. FOCUS specifies behaviour, and mixing in visual direction produces a document that designers ignore and engineers over-read.
Generate a FOCUS Prompt Instantly
Skip the manual template — Frompting applies FOCUS to your topic in one click.
Try it FreeFramework Details
| Name | FOCUS |
| Stands for | Function-Outcome-Context-Usability-Simplicity |
| Domain | Product & Growth |
| Steps | 5 |
| Access | Pro |