The question this answers
What is the technical deliverable that turns application design into something a platform team can build?
What the problem looks like without a design specification
You’ve agreed on what your grant application form should do. Better questions. Proportionate pathways. Structured evidence. Lifecycle data architecture.
Then someone asks: “So what do we actually build in SmartyGrants?”
Nobody knows. The design lives in a strategy document, a few meeting notes, and the heads of people who were in the room. The platform team gets a list of questions in a Word document and builds what they think you meant.
Conditional logic gets simplified to yes/no branching. Evidence pathways collapse into one form with optional fields. Validation rules are skipped because nobody specified them. The structured data architecture becomes free-text fields because that’s what was easiest to build.
Six months later, you’re looking at the same problems you started with. Not because the design was wrong, but because it was never translated into a build-ready specification.
What I design
A complete application design specification covering:
- Every question: wording, purpose, and which decision it supports
- Sequencing: the order applicants move through the form and why
- Conditional logic rules: what triggers each pathway, what each pathway contains, and what is excluded
- Field types: structured fields, dropdowns, uploads, numerical inputs, not free text where evidence is needed
- Validation rules: what the form accepts, rejects, and flags before submission
- Evidence requirements: what must be provided at each tier and in what format
- Data structure: how every field maps to eligibility, assessment, contracting, reporting, and evaluation
This is not a questionnaire with instructions. It is a technical blueprint that a grants platform can implement directly.
What good looks like vs what bad looks like
Bad: A Word document listing 25 questions with a note saying “add conditional logic where appropriate.”
The platform team interprets “where appropriate.” Half the conditional logic is lost. Free-text fields replace structured inputs because the specification didn’t define field types. The form goes live and nobody can explain why it doesn’t work the way it was designed.
Good:
| Specification element | What it defines | Why it matters |
|---|---|---|
| Question wording | Exact phrasing tested for clarity and evidence extraction | Prevents platform team from rewriting questions and changing what they elicit |
| Conditional logic rules | If project value > $100,000, display fields 12–18. If < $10,000, skip to field 19 | Proportionate pathways only work if the logic is specified precisely |
| Field types | Field 7: numerical input, whole numbers only, AUD. Field 12: file upload, PDF only, max 5MB | Structured fields produce comparable data. Free text produces interpretation |
| Validation rules | Field 3: ABN must be 11 digits. Field 9: total budget must equal sum of line items | Catches errors before submission rather than creating work for staff |
| Data mapping | Field 7 → assessment criterion 2, contract schedule B, annual report field 4.3 | Every piece of data collected once and reused across the lifecycle |
The platform team builds exactly what was designed. Nothing is lost in translation.
Why it matters
The gap between good design and good implementation is where most grant application improvements fail. Programs invest in rethinking their approach, then hand a list of questions to a platform team without specifying how the form should behave, what logic drives it, or how the data connects to downstream systems.
A design specification is the artefact that bridges that gap. It is the difference between a form that was redesigned and a form that was re-engineered. Without it, your investment in better application design lives in documents and conversations rather than in the system applicants actually use.
You are not receiving a prettier form. You are receiving a decision architecture ready for implementation.
More Application & Evidence Design Deliverables
Are You Funding Good Writers, Not Good Projects? → An intelligently designed grant application form that functions as a decision engine, not a questionnaire. Conditional logic creates evidence pathways scaled to project size and risk. Structured prompts force specificity and internal consistency, making weak proposals and AI-generated responses expose themselves without staff needing to detect them. Assessors compare evidence, not narrative skill.
Why do you keep asking applicants for the same information? → A lifecycle data architecture built into the form so every question maps to eligibility, assessment, contracting, reporting, evaluation, and cross-program analysis. Information is collected once, structured for reuse, and eliminates the duplication most programs never notice until reporting season.
Why do small organisations give up before they finish your application? → Proportionate evidence pathways built through conditional logic so the form automatically scales. Small projects follow a short pathway with minimal evidence requirements. Complex projects provide deeper substantiation including implementation plans, governance, and risk management. The burden of proof matches the funding risk.
