Written . Original operational guidance, not legal advice.
Write the question before opening the screen
A useful evaluation starts with an administrative task: find a record, review a change, explain a status, or retrieve an export. Write down who performs the task, what information they need and what a satisfactory result looks like. This makes it harder for an attractive screen to answer a different question from the one your team actually has.
Use fictional examples in a public tour. A demonstration is not the place to discover whether sensitive records are retained or sent to a third party. Keep real contact lists, donor histories and private team notes outside the evaluation until access and data handling have been established.
Separate four kinds of evidence
An interaction you complete is direct evidence about that particular screen. A prewritten example is evidence of presentation. A vendor statement describes a claimed service. A written agreement defines the scope being offered. These sources can all help, but they answer different questions.
For example, saving a sample email draft proves that the preview can display a changed draft. It does not prove delivery, suppression handling, approvals between users or a durable database. A sample CSV proves an export can be generated from those sample values; it does not establish reconciliation against a live source.
- Observed: what did you personally complete?
- Claimed: what did the vendor describe but not demonstrate?
- Excluded: what did the demonstration explicitly disable?
- Unresolved: what evidence is needed before a decision?
Test the handoff and the recovery path
After the happy path, change one condition. Search for a record that is not present. Clear a filter. Switch modules and return. Reset the preview. Ask whether another coordinator could understand the result without hearing your explanation. These small checks reveal more about the administrative experience than another list of feature names.
Record expected and actual behavior separately. If a page says a message was sent while delivery is disabled, that is an error, not a reassuring demonstration. If a feature is unavailable, an honest limitation is useful evidence. Do not reward software for concealing the boundary.
Close with a short evidence log
Keep one row per requirement: task, input, expected result, actual result, evidence location and outstanding question. Separate live-service verification from interface evaluation. Share the log with the person responsible for procurement, data handling and operational review before moving real records.
The BlueRoots public demo is deliberately limited to fictional browser workflows. Use it to inspect search, sample review states and navigation. Confirm availability, pricing, access controls, record retention and provider responsibilities separately. A clean demo can make that conversation more specific; it cannot replace it.