Summary
Product content should be plain, specific, and action-oriented. It should help users understand records, obligations, evidence, status, and next steps without needing specialist software or governance knowledge.
Labels
Use concrete labels that match how coordinators and committees talk about work: "Document owner", "Approval date", "Funding agreement", "Acquittal due", "Committee minute".
Empty States
Empty states should explain what belongs here and offer the next action.
Use: "No funding agreements have been added yet. Add the agreement so milestones, reports, and approvals can be tracked."
Avoid: "Nothing to see here."
Teaching Moments
Use Universal Design for Learning when the product teaches a workflow or concept. Offer short explanations, examples, and steps so people can understand what to do without needing prior governance, grant, or software experience.
| Situation | Helpful pattern |
|---|---|
| First-time setup | Short summary, checklist, and example record |
| Evidence upload | Accepted file types, naming example, and why the evidence matters |
| Status change | Plain definition, consequence, and next action |
| Report export | What is included, what is not included, and where the file can be used |
Audit Trail Copy
Audit copy should be factual and plain.
| Event | Pattern |
|---|---|
| Created | "Created by Alex Nguyen on 13 Jun 2026." |
| Updated | "Status changed from Draft to Review due." |
| Approved | "Approved by the Committee Chair." |
| Exported | "Register exported as CSV." |
Compliance Language
Use compliance language when it helps users understand an obligation. Do not use it to create fear. Pair every warning with a concrete path to resolution.
Checks
- Is the message plain and specific?
- Does it explain what happened, why it matters, and what to do next?
- Does it avoid fear-based compliance language?
- Would a first-time user understand it without product or governance expertise?