Summary
Opries documents should feel structured, practical, printable, and easy to trust. Whether produced in Word, exported from the website, or generated as a PDF, documents should use the same core logic: clear purpose, visible hierarchy, accessible typography, practical grids, useful metadata, and enough structure for readers to scan before they commit to reading.
Documents are part of the brand system because they carry evidence. Proposals, business cases, reports, quotes, letters, and governance papers should help people understand what is being proposed, what decision is needed, what evidence supports it, and what happens next.
Document Modes
Opries should support two connected document modes: editable documents and web-to-print documents. The mode should be chosen by the document's job, not by habit.
| Mode | Best for | Guidance |
|---|---|---|
| Word-style document | Drafting, review, tracked changes, collaboration with external parties, funding submissions that require .docx | Use defined styles, accessible headings, page numbers, clear tables, and print-safe margins |
| Website-rendered document | Business cases, proposals, product-backed documents, public reports, repeatable templates, generated records | Use the documentation site's design system, print CSS, semantic HTML, and static PDF export where required |
| Static PDF | Final issue, board packs, signed records, public publishing, formal quote or invoice issue | Export from a controlled source and include date, version, status, page numbers, and contact details |
Do not treat PDF as the working source unless there is no other option. The source should usually be the Word-style file, structured web page, or underlying content system.
Document Types
| Document type | Primary job | Structure emphasis |
|---|---|---|
| Business case | Explain a need, options, recommendation, risks, cost, and decision | Executive summary, decision required, evidence, comparison tables, implementation steps |
| Proposal | Explain what Opries will do, why it matters, and what is included | Scope, outcomes, approach, inclusions, exclusions, timeline, investment |
| Report | Present work completed, evidence, findings, and next actions | Summary, method, findings, evidence, implications, recommendations |
| Briefing note | Help a reader make or prepare for a decision quickly | Context, issue, options, recommendation, next step |
| Formal letter | Communicate clearly with a recipient and create a printable record | Recipient, date, Re:, message, inclusions, sign-off, contact details |
| Quote or invoice | Support payment, acceptance, audit, and filing | Recipient, date, document number, project/reference, line items, terms, contact details |
Page Pattern
Substantial documents should follow a predictable sequence so readers can orient quickly.
| Section | Use |
|---|---|
| Cover or title area | Document title, subtitle, recipient or audience, date, version/status, and Opries identity |
| Quick reference | Purpose, audience, status, owner, date, version, and decision required where relevant |
| Executive summary | Short plain-language overview of the issue, recommendation, and next action |
| Main content | Structured sections with descriptive headings, short paragraphs, tables, and examples |
| Evidence and sources | Data, references, assumptions, image credits, consultation notes, or attachments |
| Inclusions and exclusions | Clear list of what is included, what is not included, and what must be supplied separately |
| Next steps | Decision, approval, acceptance, payment, review, or implementation action |
| Footer and metadata | Page number, document title or reference, date, version, and website or contact detail |
For shorter documents, combine sections but keep the logic visible. A two-page proposal still needs a purpose, scope, inclusions, next step, and date.
Front Matter and Metadata
Documents should make their state visible. This is especially important for governance, funding, compliance, and operational records.
| Metadata | Use |
|---|---|
| Title | Plain document name, not a marketing headline |
| Purpose | What the document helps the reader decide, approve, understand, or do |
| Audience | Who the document is written for |
| Status | Draft, in review, approved, issued, superseded, or final |
| Date | Issue date or last updated date |
| Version | Version number where the document may change |
| Owner | Person, role, or team responsible |
| Reference | Project, grant, quote, invoice, policy, or internal reference |
Use metadata as a quick reference, not a decorative cover-table. It should help someone file, review, approve, or audit the document later.
Layout and Grids
Use Swiss/International grid principles to organise documents without making them feel over-designed. The grid should make the document easier to read, compare, print, and review.
| Context | Preferred structure |
|---|---|
| Short formal document | Single main column with generous margins and clear metadata |
| Long printed document | Constrained single column or two-column body where line length becomes tiring |
| Business case | Main reading column plus right-side or table-based decision metadata where useful |
| Proposal | Strong section rhythm, scope tables, inclusions/exclusions, and visible next action |
| Web-to-print page | Screen layout can be broader, but print CSS must produce readable A4 pages |
| Appendix or evidence pack | Tables, captions, references, and page numbers should be more important than expressive design |
Avoid full-width dense prose on A4. If a section becomes visually exhausting, shorten paragraphs, add subheadings, use tables, or move dense reference material into appendices.
Word-Style Documents
Word-style documents should be built with styles, not manual formatting. This keeps them easier to edit, export, and make accessible.
| Element | Requirement |
|---|---|
| Styles | Use named heading, body, caption, table, quote, header, footer, and source styles |
| Headings | Use heading levels in order so navigation panes and PDF bookmarks work |
| Body text | Arial 10.5-12 pt, left aligned, ragged right |
| Margins | Use print-safe margins; do not place critical content too close to edges |
| Headers and footers | Include document title/reference, page number, date, version, or status where useful |
| Tables | Use header rows, repeat header rows where possible, and avoid overly small type |
| Images | Include captions, source notes, and meaningful alt text where distributed digitally |
| Export | Check PDF bookmarks, selectable text, page breaks, and table splitting before issue |
Web-to-Print Documents
Website-rendered documents should use semantic HTML first, then print CSS. The screen page can support navigation and review, but the print version must behave like a real document.
| Element | Requirement |
|---|---|
| Print stylesheet | Define A4 page size, margins, page breaks, headers/footers where supported, and hidden screen-only navigation |
| Source structure | Use real headings, lists, tables, captions, and references rather than visual-only blocks |
| Page breaks | Prevent headings from being stranded at the bottom of a page |
| Tables | Avoid splitting small tables; repeat or restate context for long tables |
| Links | Show useful URLs or references in the print version where the link target matters |
| Colour | Ensure the document still works in greyscale or low-quality office printing |
| Export | Test browser print, generated PDF, and physical print where the document is formal |
Web-to-print output should not feel like a screenshot of a website. It should feel like a designed document that happens to be generated from web content.
Proposal and Business Case Pattern
Proposals and business cases should make the decision path obvious. They should avoid long persuasive prose where structured evidence would do the work better.
| Section | Guidance |
|---|---|
| Title | Name the proposal or business case directly |
| Purpose | State what decision or action the document supports |
| Summary | Explain the situation, recommendation, and requested decision in plain language |
| Context | Describe the landcare, NRM, governance, funding, or operational context |
| Options | Compare realistic options, including doing nothing where relevant |
| Recommendation | Name the recommended path and why it is preferred |
| Scope | List what is included and excluded |
| Cost and resourcing | Show assumptions, ranges, dependencies, and responsible roles |
| Risk and compliance | Identify obligations, evidence, approvals, or audit needs |
| Timeline | Show major stages and decision points |
| Next action | Make the required approval, acceptance, review, or follow-up explicit |
Accessibility and Learning
Documents should be designed for mixed reading confidence, time pressure, and different review contexts. A reader may skim on screen, print for a meeting, or revisit the document months later during audit or reporting.
Support this by using:
- summary first structure for orientation
- descriptive headings that explain the document shape
- bold keywords as a skim path
- tables for comparisons, scope, risks, options, and responsibilities
- captions and source notes for images, charts, maps, and evidence
- inclusions and exclusions so expectations are clear
- plain next actions so readers know what happens after reading
Checks
- Is the document's purpose visible in the first page or first screen?
- Can a reader understand the structure from headings and tables alone?
- Are date, status, owner, version, and reference visible where they matter?
- Is the document readable when printed on A4?
- Are line lengths, paragraph lengths, and table density comfortable?
- Does the print version hide navigation and preserve the document content?
- Are inclusions, exclusions, sources, and next actions clear?
- Would the document still make sense months later as a record?