1 Scope

What this clause covers

Clause 1 is short and it decides every later argument about scope. It puts the draft in the middle of the product process rather than at the end of it: the help is designed, developed and evaluated, not bolted on after release. It names two routes into mobile help. One is content written for the mobile setting. The other is content that already exists for print, desktop or the web and is transformed by responsive design. The draft keeps the interface hardware out of its own remit. That exclusion is precise: a team still has to make the help readable on the screen it has, but the draft does not specify the screen, the speaker or the sensor.

What to put in place before publication

1. Write a one page scope statement for your user assistance that names the apps, the platforms and the languages covered.
2. List the help forms in play, such as embedded help, coach marks, a help site, a chatbot and video, and mark which are in scope this year.
3. Record which existing content will be transformed by responsive design and which will be written fresh for mobile.
4. State the exclusions plainly, including hardware specifications and any content owned by another team.
5. Name the person who owns the scope statement and the date it was last checked against the app roadmap.

Evidence to keep

Where teams usually fall short

• The scope is a sentence in a project ticket, not a document the team can test against.
• Responsive transformation is treated as a copy and paste job with no owner.
• The help is planned for the app store release, after the content freeze.

What happens next

When the FDIS text appears, check whether the scope sentence changed and whether the exclusion of hardware specifications still stands. Re-read the clause before the first release that follows publication.