Fictional studio example / annotated wireframe
An inspectable design specimen, not a client screenshot, completed provider integration or measured result. Interface choices illustrate the task described in this guide.
Show the feature doing one job
- Name the user task: assign a request and see what happens next.
- Caption the actual feature shown; do not imply unsupported automation or integrations.
- Link to the relevant use case before asking for a demo.
Show the feature’s distinct task and limits
Give the request queue a separate feature page only when its owner, status and next-action task answers a distinct buyer question. Pair that brief with the clearly labeled concept screen. Keep automation, history and integration claims unverified until their owner supplies evidence, rather than letting the interface imply unseen capabilities.
Worked example — illustrative data.
| Brief field | Specimen content | Evidence required |
|---|---|---|
| Buyer question | Can I see who owns the next request? | Actual buyer need before a real feature claim |
| Task | Open the queue and inspect owner, status and next action | Fictional request-queue screen attached in preview |
| Screen | Review catalog update — Alex — Ready for review; clarify export fields — Sam — Needs information | Clearly labeled concept, not a product screenshot |
| Limits | Automation, history, retention and integrations not demonstrated | Current product owner evidence for each future claim |
| Next reading | Workflow use case and setup documentation | Verified destination and content owner |
Compare the proposed page with the product, use-case and documentation pages before drafting. State what decision it answers that those pages do not. Use a current screenshot or clearly labeled fictional sketch to demonstrate the capability. Put prerequisites and meaningful limits beside the explanation, not in a footnote. Link setup steps to documentation rather than reproducing instructions that will quickly drift. Review the feature name for consistency across the site.
Role and plan restrictions belong beside feature claims
A feature available only to a specific role or plan can sound universal in a heading. Qualify the claim where the buyer encounters it and verify current availability before publication.
Create the page only when its task and evidence are sufficiently distinct. Keep a shorter explanation on the parent page if no separate decision or supported detail exists.
Continue with Guides for stores, software teams and local businesses, SaaS website design and development and Plan SaaS use-case pages around product fit.