How do we most effectively use Filters/Facets and Target Terms?

Data Management
1

One of the most popular features on sites like [search.wa211.org](https://search.wa211.org) is the sidebar filters ([see an example search for Utility Assistance in Spokane County]( https://search.wa211.org/search?query=BV-8900.9300&query_label=Utility+Assistance&query_type=taxonomy&location=Spokane+County,+Washington,+United+States&coords=-117.42503,47.659016 )).

Our clients often debate how these filters should work, and it sometimes causes confusion. When someone selects a facet like “Veteran,” should it boost results that have that facet, or filter out results that don’t?

A solution to this question needs to balance the needs of both help seekers and data managers. I think of these needs as two user stories:

  1. As a help-seeker, I want to quickly find the resources that fit me best, so I can focus my time where it counts.
  2. As a data manager, I want facets to make resources easier to browse without adding much work to managing data.

What doesn’t work

One approach I’ve seen fail is adding a facet, like “Veteran”, and then tagging every record that veterans qualify for. This causes two problems:

1. It’s the most work for data managers. Every record a veteran might qualify for has to be tagged, or it gets left out.

2. It hides specialization. Many resources serve veterans, but there may be a few that are extra relevant. When _everything_ is tagged, those few don’t stand out.

A better approach

I propose an approach that minimizes management and helps prioritize relevant results at the same time:

1. Data managers should be able to create and add facets to any resource.

2. Beyond just selecting facets for resources (think a checkbox), let each facet be set as either a Target or a Requirement:

  • Target: Boost this resource when the facet is selected.

  • Requirement: Hide this resource when a *different* facet in the same group is selected.

Today, filters usually work like this: “Hide everything that doesn’t have this facet.” That forces data managers to tag every possible record for each facet, which is especially arduous for broad facets such as target populations.

Instead, we should add facets only when they are significant differentiators; otherwise, they should be left blank by default. Further, Requirements should only be used when a help-seeker would be turned away for not meeting it.

An example

Say we have a “Gender” facet group with three options: “Woman,” “Man,” and “Other” (kept short for this discussion).

  • Target: I mark “Woman” as a Target on a transitional shelter. The shelter serves all genders but focuses on women. If someone selects “Woman,” the shelter is boosted. If someone selects “Other,” the shelter still shows up, just not boosted.
  • Requirement: I mark “Woman” as a Requirement on WIC. If someone selects “Woman,” WIC stays in the results, along with everything else tagged “Woman” and everything with no Gender facet selected. However, if someone selects “Man,” WIC is filtered out.

In short: WIC is for women. If we don’t know someone’s gender, we keep WIC in the list because they might be a woman. Once they select “Man,” we can safely remove it. For resources where gender doesn’t matter, we ignore the Gender group entirely.

Where this gets tricky

Requirements work best in groups where a person usually fits only one option. Then, when someone picks one option, it’s safe to hide resources that require a different one.

Some facet lists in use today would need reorganizing to work this way. For example, I’ve seen “Target Populations” lists with more than a dozen options. Even if one of them, like “Veteran,” is sometimes required, a veterans-only resource shouldn’t disappear just because someone selected “Homeless,” because a person can be both homeless and a veteran.

From this, I’d suggest two tips, although I’d love feedback on them:

  1. Split large facet groups into smaller groups of related options where a person would only pick one.
  2. For large groups that can’t be split, skip Requirements and only use Targets.

Open questions

  • Are there cases where a resource needs more than one Requirement in the same group?
  • If so, does that usually mean “requires any one of these” or “requires all of these”?
  • Are requirements and eligibility one and the same? Under what conditions could requirements be _not_ eligibility-related?
  • What other questions should we be asking about facets?

Conclusion

My thoughts are heavily informed by years of feedback from Hannah Newton, Lindsay Paulsen, Sasha Rienoso, Cathleen Dwyer, and others.

I’m keenly interested in feedback from our stakeholders in Connect 211 and the broader Open Referral community.

2

Just a small caveat since it is a resource from my system that was highlighted :slight_smile: the data manager for that area definitely over tagged services with filters, and we have been removing them as we can.

I like the idea of boosting vs. hiding, but I am not sure the Requirement option is workable because there are too many and/or variables. Like in your scenario, a person would need to check homeless and veteran, but for shelter a person couldn’t be a woman with children and a woman without children even though it is a requirement that someone be one or the other.

To answer your question, “Are requirements and eligibility one and the same?” I would say no. If a food bank is only open on Wednesdays, I would put Wednesday as a requirement, but it is not an eligibility.

What I wish filters did better is not just boosting resources you are eligible for but actively removing resources you are not eligible for. For instance with rent assistance, we have resources for veterans, for college students, for people with cancer, etc. and sometimes it’s hard to find the services that aren’t targeted. I created a “General” Focus Population, but it’s not intuitive and is probably not widely used.