What you will learn
- How screening questions are designed for people in stressful situations
- How program rules are encoded without becoming a legal advice tool
- What a results page must show: likely, possible, and unlikely, with next steps
- How screening hands off to applications without losing the person
- How screening data improves outreach without violating privacy
What the project is
Benefits programs, food assistance, housing support, healthcare coverage, energy help, and cash assistance, each have eligibility rules based on household size, income, age, disability, immigration status, and other factors. A screening tool encodes those rules as a question flow: household composition, income, expenses, and circumstances, asked in plain language, with help text where a question is confusing. The result is a personalised list: programs the person likely qualifies for, programs they may qualify for, and programs they likely do not, each with the reason and the next step.
The honesty boundary is critical. A screener estimates eligibility; it does not determine it. Only the administering agency decides an application, and the tool must say so plainly, or it will create false hope and angry applicants. The results page should therefore distinguish likely from possible, explain the key rule behind each result, and hand off to the real application with the person's answers pre-filled where the application system allows it, so the screener saves effort rather than duplicating it.
Core features
Plain-language questions are the feature. A screener that asks questions the way a benefits form does will be abandoned by the people who need it most.
- Question flow in plain language, with help text, multiple languages, and a save-and-return option for people without a stable device.
- Program rule engine with rules as configuration, so a program change updates screening without a code release.
- Results page showing likely, possible, and unlikely programs, each with the key rule and the next step.
- Application handoff: links, pre-filled data where the application system supports it, and a checklist of documents needed.
- Anonymous screening option, so a person can check eligibility without creating an account or sharing identity.
- Referral integration: screening results can be shared with a caseworker, with the client's consent, for follow-up help.
- Analytics on screening patterns: which programs are most often likely, and where applicants drop off, to improve outreach.
How it is built
Build the question flow with the people who will use it, including people with low literacy and limited English, before encoding program rules. A screener designed by benefits experts alone will ask expert questions.
- Program study: list the programs, their rules, and their application routes, and agree the screening scope with the agencies involved.
- Question design: draft the flow in plain language, test it with real users, and revise where users stall or misunderstand.
- Rule engine build: encode rules as configuration, and validate screening results against known cases with agency staff.
- Results and handoff: results pages, application links, and document checklists, tested with users end to end.
- Launch and maintenance: assign ownership for rule updates, because a screener with last year's rules misleads applicants.
Tech considerations
The technical core is a rule engine that non-developers can update and a question flow that survives low literacy, low connectivity, and high stress.
- Rule engine with program rules as data, versioned, so a rule change is traceable and reversible.
- Question flow with branching, save-and-return, and anonymous mode, designed for mobile and basic devices.
- Results generation that explains each result's key rule, so users understand why, not just what.
- Application handoff via links and pre-fill where supported, without storing sensitive data longer than needed.
- Analytics on aggregate screening patterns, with individual screening data minimised and protected.
Challenges to plan for
Screening tools fail on jargon, stale rules, and false certainty. Each failure either deters an eligible person or misleads an ineligible one.
- Jargon: questions written in benefits terminology will be misunderstood, and misunderstood answers produce wrong results.
- Stale rules: benefit rules change, and a screener that does not update becomes a misinformation tool.
- False certainty: a result presented as a guarantee creates anger when the agency decides differently, so language must stay estimated.
- Digital exclusion: a screener that only works online, in one language, on a modern phone, excludes the people who need it most.
Who it is for, and honest limits
This fits social services agencies, community organisations, and benefits advice services that help people navigate applications. It fits less well as a standalone consumer app without agency links, because screening without an application handoff leaves users informed but unaided.
It does not decide eligibility or replace benefits advice. It gives people a fast, honest estimate and a next step. If a person's situation is complex, the right result is a referral to an adviser, and the tool should say so rather than guessing.
Frequently asked questions
Is a screening result a guarantee?
No. Screening estimates eligibility from the answers given; only the administering agency decides an application. Results should be labelled likely or possible, never guaranteed, and the key rule behind each result should be shown.
Can someone screen anonymously?
Yes, anonymous screening should be offered, because many people will not share identity before knowing whether help is likely. Anonymous results cannot be followed up, so the tool should offer an optional consent-based referral to a caseworker.
What if a person's situation is complex?
The tool should recognise complexity, such as mixed immigration status or variable income, and refer to an adviser rather than forcing a simple answer. A referral is a better result than a confident wrong one.
How are program rules kept current?
By assigning ownership for rule updates to program staff, with a review routine when programs change. The rule engine should version rules, so a result can be traced to the rules in force when it was generated.
Can screening data be used for outreach?
In aggregate, yes: which programs are most often likely, and where users drop off, can guide outreach. Individual screening data should be minimised, protected, and never used for purposes the user did not consent to.