Architectural Blueprint and Strategic Implementation for the Who Cares Wizard on 2ia.org

Full report

On this page

Executive summary

The strongest version of the Who Cares Wizard is not a long questionnaire that asks vulnerable users to “prove” their problem. It is a trauma-informed, privacy-preserving, jurisdiction-aware routing system that begins with safety, narrows the grievance from broad to specific, and ends with a concrete next action: a hotline, regulator, legal aid provider, public service locator, or trusted information source. The uploaded concept memo already points in the right direction by emphasizing progressive disclosure, a graph-like decision structure, anti-victim-blaming language, and a final “resolution” layer; this report turns that vision into a production-ready blueprint for web and mobile deployment.

A sound operating principle is: visible flow should be short, backend logic can be deep. The wizard should usually present only four to seven on-screen steps in ordinary cases, while the routing engine behind those steps remains much richer. That balance matters because trauma-informed practice emphasizes safety, trust, collaboration, and empowerment, and WCAG 2.2 explicitly adds requirements that are directly relevant to grievance-routing products, including consistent help, redundant entry, accessible authentication, minimum target size, and focus visibility.

For 2ia.org, I recommend a five-part architecture: a responsive web front end; a safety interrupt layer; a rules engine that traverses a directed graph of questions; a curated, jurisdiction-tagged resource registry; and a governance layer for privacy, verification, and analytics. Because the domain is short and visually simple, it also deserves domain-spoofing defenses and secure application verification practices. Unicode’s security guidance warns that visually confusable characters can create security attacks, ICANN has specifically discussed IDN homograph spoofing, and OWASP ASVS provides a rigorous basis for verifying web-app controls.

The core grievance groups that best fit a general “gripe” router are: immediate danger and abuse; housing and utilities; health, mental health, disability, and caregiving; work, income, debt, and benefits; children, youth, and family; discrimination, immigration, legal status, and civil rights; and community, environment, disaster, and public services. These groups map well to official or primary sources such as SAMHSA and 988, HUD, ACL, OSHA, EEOC, NLRB, CFPB, DOJ, ADA.gov, USCIS, UNHCR, EPA, FEMA, and USAGov, while leaving room for carefully vetted specialist nonprofits where official systems are incomplete.

The product should therefore do four things exceptionally well: interrupt for danger, classify the grievance, collect only the metadata needed to localize and prioritize, and show one primary route plus fallback routes with clear explanations and next actions. If the system cannot confidently route to a local official destination, it should say so plainly and fall back to the nearest official directory or specialist helpline rather than pretending certainty.

Foundational design choices

Product objective

The wizard’s job is to answer a precise user question:

“Given what I’m dealing with, who can help me now, who can tell me my rights, and who can take a report or action?”

That sounds simple, but it requires the product to distinguish three very different modes of use. One is acute safety routing, where ordinary questions should stop and the user should be shown immediate options. Another is service access, where the user wants shelter, utility help, treatment, eldercare, benefits, or local assistance. The third is rights-and-accountability routing, where the right destination may be a housing or labor regulator, civil-rights enforcer, immigration legal aid service, or consumer complaint system. Official services in these areas are fragmented and often deadline-sensitive, which is why the wizard should ask about danger first, deadlines second, and narrative detail last.

The system’s tone should be validating but operational. SAMHSA’s trauma-informed approach centers safety, trust, collaboration, and empowerment, which is a good fit for a tool that may be used by people under stress. The uploaded concept memo likewise rejects victim-blaming and imagines the product as a bridge between individual distress and real-world institutions that are trying to help.

Recommended application architecture

A useful mental model is to keep the question graph separate from the content registry. The first decides what to ask next; the second decides what to show at the end. This separation makes it easier to add a new grievance category or update a resource without rewriting the whole flow.

flowchart LR
    A[User on web or mobile] --> B[Question Flow UI]
    B --> C{Safety Interrupt Engine}
    C -->|Immediate danger| D[Emergency and crisis results]
    C -->|No immediate danger| E[Rules Engine]
    E --> F[Resource Registry]
    E --> G[Human Navigator Queue]
    F --> H[Primary route + fallback routes]
    B --> I[Consent + privacy controls]
    H --> J[Save, print, or share summary]

The registry should be governed by a source hierarchy. My recommendation is: first, official government, court, or UN sources; second, official service locators or government-backed directories; third, national specialist nonprofits with a demonstrable referral function; and fourth, local community providers that have been manually vetted. This ranking minimizes false authority while still allowing the product to route to expert survivor or community support when government alone is not enough.

Security posture for 2ia.org

Because the experience may handle sensitive grievances, the product should be isolated from ordinary site content as much as possible. A dedicated app surface, isolated cookies, strict CSP, and application verification against OWASP ASVS are appropriate. For the domain itself, a short domain like 2ia.org should be treated as potentially vulnerable to confusable-character and homograph abuse; Unicode’s security mechanisms and ICANN’s homograph guidance make that a real concern, not a theoretical one.

In practice, that means the wizard should include a clearly branded, stable origin; defensive monitoring for confusable look-alikes; visible trust cues; and a conservative external-link policy for outbound referrals. Do not place sensitive grievance logic inside ad-tech-heavy page templates or plugin ecosystems that are not needed for the routing flow.

User personas and grievance taxonomy

Inferred personas and contexts

No detailed personas were specified in the prompt, so the following are inferred design personas for a general grievance router. They are deliberately broad because the product should work even before the user knows which system they need.

Across all personas, the cross-cutting contexts are similar: mobile-only access, low bandwidth, limited privacy on device, limited literacy, multilingual need, disability accommodations, and fear of retaliation or surveillance. That is why the product should begin with short closed-ended questions, preserve anonymity by default, and keep free-text optional until the end.

Primary grievance categories, subcategories, and target groups

The table below is the core taxonomy I would use in the first production version.

A practical note: because the prompt assumes no specific jurisdiction, the wizard should not hard-code legal conclusions at the category level. It should instead use category selection to determine which jurisdictional fields become required next. For example, a civil-rights or labor complaint needs a country and usually a state or province before the system can reliably suggest an official filing route, while a general information journey may not.

Layered question flows and routing logic

The universal trunk flow

The right way to structure the interview is from general to specific, but with a rule that safety outranks specificity. The first visible question should therefore be a danger check. The second should be broad category classification. The third should identify the actual subtype. The fourth should gather missing localization and access details. The fifth should present the result or, if confidence is low, one more clarifier.

flowchart TD
    A[Start] --> B{Is anyone in immediate danger right now?}
    B -->|Yes| C[Emergency interrupt]
    B -->|No| D{Who is affected?}
    D --> E[Me or someone I know]
    D --> F[My household, neighborhood, or community]
    E --> G{What best describes the issue?}
    F --> G
    G --> H[Safety or abuse]
    G --> I[Housing or utilities]
    G --> J[Health, disability, or caregiving]
    G --> K[Work, money, debt, or benefits]
    G --> L[Child, youth, or family]
    G --> M[Discrimination, immigration, or legal status]
    G --> N[Environment, disaster, or public services]
    H --> O[Subtype + urgency + channel needs]
    I --> O
    J --> O
    K --> O
    L --> O
    M --> O
    N --> O
    O --> P[Route to primary help group + fallback options]

Decision-tree question layers with sample phrasing

The table below shows a production-friendly pattern of at least three layers deep for each major grievance group. The phrasing is intentionally direct, plain-language, and non-judgmental.

Recommended routing algorithm

The routing algorithm should not be a black box. It should be understandable enough to explain to users why a route was chosen. I recommend a weighted model with hard overrides:

• Safety override if risk is immediate.
• Deadline override if a complaint, hearing, shutoff, eviction, or benefit-termination date is near.
• Issue match as the strongest ordinary factor.
• Jurisdiction match next.
• Language and accessibility match after that.
• Preferred channel and user goal after that.

A practical scoring model is:

• Issue match: 40
• Jurisdiction and coverage: 20
• Urgency and service hours: 15
• Demographic or cultural competence: 10
• Modality fit: 10
• Language/accessibility fit: 5

If the top two routes are close, the interface should show a primary route and a clearly labeled also consider secondary route.

When a locale is known, date capture becomes critical. In the United States, for example, OSHA notes that safety and health complaints relating to incidents older than six months will not result in violations, the EEOC says many employment-discrimination charges must be filed within 180 days or 300 days where state or local law overlaps, and HUD’s Fair Housing process says allegations under the Fair Housing Act should be filed within one year of the last discriminatory act. Those examples show why the wizard should ask for incident date very early once a rights-enforcement path becomes likely.

Resource mapping and escalation model

Routing rules and criteria

The next table translates answers into target groups and concrete actions. This is the operational heart of the wizard.

Escalation paths and thresholds

Escalation should be explicit and deterministic.

The system should always allow a manual escalation path: “This doesn’t fit — show me a human or a broader list.” That matters because many real grievances are multi-system problems. A person may simultaneously face housing loss, disability accommodation barriers, caregiver strain, and debt. In such cases, the product should show a composite result rather than force one label.

Privacy, security, and consent

Privacy model

The privacy baseline should be anonymous use by default, opt-in sharing by exception. NIST’s Privacy Framework is a strong foundation because it explicitly organizes privacy work around governance, control, communication, and protection, and it treats data minimization and privacy-risk assessment as core operational concerns.

That has concrete product consequences. The wizard should not require account creation for basic routing. It should not ask for exact street address until a local service search genuinely requires it. It should avoid mandatory free-text narratives at the top of the flow. It should store only enough data to return results, provide opt-in save/resume where justified, and make deletion simple.

It is also important to describe the privacy regime accurately. HHS explains that HIPAA applies to covered entities and business associates, not every website or app, and the FTC stresses that many health apps are not covered by HIPAA even though health-breach rules may still apply. So the wizard should not market itself as “HIPAA compliant” unless that is actually true for the relevant deployment and data flows.

If the product intentionally collects information from children under 13, or has actual knowledge that it is doing so, COPPA duties become relevant, including parental notice and consent obligations, reasonable security, and limits on collecting more information than is necessary. Even if the wizard is not child-directed, youth-safe design still matters because family and child-welfare grievances are in scope.

Suggested user metadata to collect

For high-risk categories, the product should default to structured choices rather than open narrative. That reduces accidental oversharing and keeps the routing process more legible.

Safety, device privacy, and consent wording

For abuse and stalking contexts, device safety is part of product safety. The National Domestic Violence Hotline publishes technology-safety guidance, including clearing search history and thinking through online abuse, and encourages survivors to consider whether their internet use may be monitored. That strongly supports a quick-exit button, discreet page titles, and a “don’t save my answers” mode.

A plain-language consent pattern should look like this:

Before we continue: You can use this tool anonymously. We ask only for the details needed to show the most relevant help and information. Your answers will not be sent to another organization unless you choose to share them. If someone is in immediate danger, leave this tool and contact local emergency services now. By selecting Continue, you consent to the temporary processing of your answers to generate results.

For any handoff, the product should require field-by-field review:

Share this summary? We will send only the fields shown below to [organization name]: issue category, urgency, city/region, language, accessibility needs, preferred contact method, and your optional summary. You can remove any field before sending.

Security and trust requirements

At minimum, the deployment should include encrypted transport, secret management, least-privilege admin roles, tamper-evident audit logs for content changes, security testing aligned with OWASP ASVS, and monitoring for confusable or spoofed domains relevant to 2ia.org. Unicode and ICANN’s guidance make the spoofing risk real; OWASP ASVS makes verification repeatable.

Implementation, accessibility, localization, and metrics

Web and mobile integration notes

For product reach and maintenance, I recommend a responsive web app first, optionally installable as a PWA later. That avoids duplicating the same highly sensitive decision logic across separate native codebases, while still allowing excellent mobile performance.

The UX design should adopt the following patterns as default product rules:

If the wizard ever serves a public-sector or government-adjacent deployment, the 2024 DOJ Title II rule is highly relevant because it concretely ties public web and mobile accessibility to WCAG 2.1 AA. Even for a private deployment, that is a useful legal-grade benchmark. WCAG 2.2 extends that baseline with improvements especially relevant to forms, support placement, touch input, and authentication.

Accessibility and localization

Localization should be treated as a structural concern, not a translation afterthought. W3C’s internationalization guidance recommends using UTF-8 throughout, supporting local name/address/date formats, declaring page language with the lang attribute, and using dir="rtl" when needed for right-to-left languages. W3C also stresses that internationalization means designing the system to adapt across cultures, scripts, and formats, not merely swapping strings.

For this product, that implies:

• a visible language switcher on every page;
• externalized strings and locale-aware date and address handling;
• structured support for English, Spanish, and right-to-left scripts as early targets;
• resource cards filtered by language and accessibility channel;
• no text baked into images;
• readable plain-language copy with culturally neutral examples.

Those choices align with the reality of the services themselves. The National Domestic Violence Hotline supports live advocates and interpretation across hundreds of languages, 988 offers Spanish services and Deaf/Hard of Hearing pathways including ASL videophone and TTY relay guidance, and HUD housing counseling can be accessed in a variety of languages. The wizard should therefore ask about language and communication preference early enough to influence ranking instead of treating those as afterthoughts.

Sample UI question screens

Who Cares Wizard
Step 1 of 5

Are you or someone else in immediate danger right now?

( ) Yes, right now
( ) Urgent help is needed today
( ) No immediate danger

[Continue]   [Quick exit]
Need help now? Call, text, or chat options

Who Cares Wizard
Step 2 of 5

What best describes the issue?

[ Safety or abuse ]
[ Housing or utilities ]
[ Health, disability, or caregiving ]
[ Work, money, debt, or benefits ]
[ Child, youth, or family ]
[ Discrimination, immigration, or legal status ]
[ Environment, disaster, or public services ]

[Back] [Continue]

Who Cares Wizard
Results

Primary route: Housing counselor and eviction support
Why this was chosen:
- You said eviction is likely within 7 days
- You are not looking for shelter tonight
- You want rights and negotiation help first

Start here
[ Call / Chat / Open official site ]

Also consider
- Fair housing complaint path
- Free legal aid near you

Before you go
[ Download summary ] [ Share selected fields ] [ Start over ]

Sample response templates and next-step actions

Emergency response template

Get help now. You told us someone may be in immediate danger. Skip the rest of the questionnaire. Use one of the crisis options below now.

Next actions: choose call/text/chat; confirm your location; choose language or accessibility support; if safe, return later for ongoing support resources.

Official complaint route template

Best first route: file or prepare an official report. Your answers suggest this problem is time-sensitive and handled by an official agency.

Why this route fits: you reported a recent incident, a likely legal or administrative deadline, and a category with a formal complaint pathway.

Next actions: gather dates, notices, screenshots, letters, worksite or landlord details; open the official complaint page; if you want, also contact legal aid.

Service-navigation template

Best first route: service locator and human support. Your answers suggest you need access to a service more than a formal complaint.

Why this route fits: you reported a need for housing, care, treatment, or benefits rather than enforcement first.

Next actions: search nearby providers; choose the safest contact method; save your result; ask for language or disability accommodations when contacting the provider.

Ambiguous or multi-system route template

You may need more than one system. Your answers suggest this problem overlaps more than one area.

Primary route: the first place most likely to help immediately.

Secondary route: the agency or legal-support option for rights or accountability.

Next actions: start with the primary route today; use the secondary route if the first system cannot act or if you need to file a complaint.

Metrics to evaluate effectiveness

The product should be evaluated on safety, routing quality, user trust, accessibility, and outcomes, not just completion rate.

The analytics design should itself be privacy-conservative. Aggregate event telemetry is enough for most product learning. Raw grievance text should not be retained by default, and any content-level review workflow should be explicitly consented and tightly controlled.

Recommended final product stance

The best strategic framing for the Who Cares Wizard is this:

• It is not a generic help center.
• It is not a legal-advice engine.
• It is not a crisis service pretending to replace crisis services.

It is a layered routing and explanation system that helps a user move from “Something is wrong” to “This is the right group, this is why, and this is what I should do next.” If built with a short visible flow, a deep rules layer, an official-source-first registry, strong privacy controls, and accessibility/localization as first-class requirements, it can make the simple question “Who cares?” answerable in a way that is fast, credible, and humane.