[daguar]

Great question! Overall I'd say our gov't partners are incredibly supportive.

A lot of why these processes are hard are not by intentional design, but rather by _unintentional, non-design_.

What do I mean? It's that these systems evolve over time, via massive waterfall IT procurement processes, and you often have someone (say, one county, or one unit) who proposes to add one more question because it makes it better for their unit or a subset of users.

Iterated over years and years — and with no systemic actor responsible for pushing back and saying, "but this creates more burden for the majority of users" — you get overwhelming user experiences. Sometimes I've jokingly called this the "no feature left behind" approach.

What we do is basically design & build a service that puts users at the center, and when someone wants us to add something ask ourselves, "will this help people quickly and easily get through the benefit enrollment process?"

It's essentially applying "products are about saying no," just to a domain where there's currently no one there to say no.

[simplicitea]

Actually, to follow up -- you mention simplifying the process to be easier on the user. Are myriad of questions one must laboriously answer to enroll in EBT programs a matter of... legislation? taxes? I would imagine that the questions have to do with honing in on a complex placement within the law which determines benefit levels. How do you go about simplifying a process which requires a large number of distinct data points by law or by census design?

[daguar]

That's a fantastic question. There's a few strategies we've used to build a service design that deals with those things:

1. After the initial application, the next step is a phone interview where they're going to ask many of the same questions and verify information anyway. So what we do is focus on the 10-15 questions that make getting someone to that interview as quick and efficient on the gov't side as possible, as well as prepares the interviewer with the best information.

For example, there are complex rules around income and expenses (earned/unearned, self-employed, utilities, child care expenses) but we basically have found that the best situation is — since they'll be talking with someone who knows those rules extremely well — focus on the basics: who's in your household, do you qualify for expedited (emergency) service, etc.

2. Many of those ~200 questions really CONDITIONAL on some (eg, do you have a felony? do you have a felony for DRUGS?) —— but candidly many online gov't forms are just the digitization of paper forms (which obviously can't do conditional showing easily.)

3. We've found that there's a ton of low-hanging fruit. For example, we have an easy way for clients to take pictures of documents they need to submit from their phone (these days, these are often SUPER high quality, even on low-end devices.) We send those to counties via secure e-mail, which means it comes instantly. This has been so successful in one county that they're now using this document feature across ALL programs (health insurance, cash aid) and actually asking clients to send in documents WHILE they're on the phone with them, meaning they can hold for a second, check the email, see the pic, and issue the benefits immediately (rather than waiting for them to mail/fax/scan and upload after creating an account.)

Overall, we've found that despite that "intrinsic complexity," there's still a huge space for simplification just using what computers — and web sites — are good at.