A note-taking app is working when authorized users can capture information, find it again, use it on the needed devices, and recover it after a mistake or account change. A long feature list does not answer those questions. Use a small scorecard with observable tasks, a fixed sample of notes, and explicit pass criteria, then repeat the same checks after important changes.
Define the jobs that matter
List three to five real tasks, such as capturing a meeting note, retrieving a decision, opening an attachment, sharing a page with the correct person, and exporting a project notebook. Identify which devices and account types are in scope. Set a reasonable completion standard for each task. The goal is not to prove that every feature works; it is to test the workflow people actually depend on.
Measure capture reliability
Create a small test note from each supported device and include text, a checklist, a link, and one harmless attachment. Record whether the note saves without an error and appears on a second authorized device with the expected content and timestamp. Repeat the check after reconnecting from an offline period if offline work is part of the requirement. Treat unresolved duplicates or silent content loss as failures, not minor inconveniences.
Measure retrieval quality
Choose a fixed sample of known notes and search for each one by title, phrase, tag, date, and notebook. Record whether the correct note appears, how many attempts it takes, and whether the result exposes enough context to choose confidently. Also test navigation without search because users sometimes remember a project or section but not the exact wording. A useful retrieval measure is repeatable and tied to known answers.
Measure sharing and access
Use test accounts with the roles the team actually uses. Confirm that an intended reader can open the shared note and that a person without access cannot. Remove a test collaborator and verify that access ends. Review ownership of shared notebooks and document what happens when the owner leaves. Do not use private production notes for these checks.
Measure export portability
Export a bounded test notebook and open the downloaded result outside the normal daily workflow. Microsoft documents that full OneNote notebook export through the web is available for notebooks stored in personal OneDrive, but not for notebooks stored in work or school OneDrive or SharePoint. That limitation illustrates why portability must be tested with the actual account type rather than assumed from a menu label. Check text, attachments, links, section order, and dates in the export.
Measure recovery, not just backup creation
Restore a disposable section or selected pages into a test notebook. Microsoft explains that OneNote can open backup sections for review and copy pages or sections into another notebook, but only if backups were created before the loss. Confirm that the restored material matches the test sample and that the process does not overwrite current notes. Record the backup date, restore date, result, and any missing content.
Review a compact scorecard
Track pass rate for capture tests, retrieval success, sync conflicts, sharing errors, export completeness, and restore success. Add the time required for the most important tasks and the number of unresolved incidents. Review weekly while adopting or migrating the app, then monthly once the workflow is stable. Investigate a trend before changing tools; one temporary outage and a repeated design limitation are different problems.
Decide with evidence
Keep the app when the critical tasks pass consistently and recovery is proven. Repair the workflow when failures come from training, naming, permissions, or configuration. Consider replacement only when essential requirements repeatedly fail or the account cannot produce a usable export. Record the test data and decision so a later review can distinguish improvement from a change in expectations.
Sources
- Export OneNote notebooks — Microsoft Support
- Restore notes from a backup — Microsoft Support