Thread by @allafarce

I want to think out loud a little bit about a concept that has been stuck in my head for the past few months:

"Rationing by friction"

the (sometimes unintentional, sometimes malicious) phenomenon of restricting access to govt services by way of process & paperwork requirements

In a lot of ways, the ideas we talk about (user-centered design, service design, usability, feedback loops, instrumentation) are often taken as niceties, when in fact they are targeting a core problem:

every friction-laden step prevents some # of people from getting help

In the academic literature, this is referred to as "administrative burden" and the best background paper is this: batten.virginia.edu/sites/default/…

breaking down burden into 3 buckets (learning, psychological, and compliance)

From the work I've done on SNAP, I've come to see a parallel between administrative burden and code complexity.

To my mind, there are two types of friction:
1. Inherent friction
2. Incidental friction

This is an analogous typology to software complexity: pressupinc.com/blog/2014/05/r…

"Inherent friction" is when public policy objectives actually require some level of friction and complexity to achieve the goals.

For example, if we want people to be able to deduct utility costs, and some people use propane, maybe that requires an additional question/language.

Yes we are adding some cost in complexity in friction by having more verbiage and maybe a longer question, but it buys us a benefit: in theory it gives people who substantively deserve a deduction get it, even though it's a less common situation.

"Incidental friction" is when complexity and burden arises not to serve some intentional goal, but rather just as a side effect of how a policy is implemented.

Ex: that ppl searching for "food stamps" are overwhelmingly on mobile, but in most states the sites aren't responsive.

Critical note: "incidental friction" does mean that some actors won't use administrative implementation to serve their own goals (i.e. make it harder) — but it's important to define it as "the decisions not constrained by upstream policy"

(And of course the debate around work requirements in Medicaid is largely because it is an attempt to use friction [more paperwork] to ration at a sub-policy level by actors who disagree with policy. The lit does show this happens.)

But the reason this is important is that the effect of friction/administrative burden on public program delivery is MEASURABLE: it is an empirical phenomenon at its core.

And this is the idea I can't stop thinking about—that THIS is the promise "digital services" in government, that it's about taking the unmeasured cost of friction and making it visible, measurable, and part of policy and implementation decisionmaking.

As an aside this is why you can often find me ranting when people are lifting up technical solutions (we made it easier!) instead of measurable user outcomes.

Sure there are basics that We Should Just Do.

But the critical value is the measurement of friction.

And the reason this matters is if you can *measure* the friction and rationing that occurs from complexity, then you can *consider* it in decisions.

Sure, adding a new exception that requires a new question on a form will get some outcomes — but some people may then drop off!

In a lot of ways, I think that the effective use of "digital services" in govt services is actually potentially the comparable revolution of econometrics and costing models in public policy analysis...

It used to be that the space for what could be politically contested on policy questions was wide open: some would say "it will cost nothing and do everything!" and the other side would say "it will be ineffective and cost millions!"

We've actually solved that via institutional innovations like the CBO, LAO, OMB, and other policy analysis shops.

How? We moved a critical decision input from a subjective, contestable thing to something we (mostly) can agree on. So we then argue cost vs. benefit.

But take a common decision in delivering govt services online:

How does adding alllllll of the "here are the exceptions" language to be on a page and make everyone read it (vs hide it in a dropdown) change conversion?

How does it change *understanding*? (the actual goal)

We have a host of decisions in govt service delivery that are made, more or less, without a significant amount of empirical backing.

In general on the tech side, many of these decisions are thrown over the wall to a vendor, and we just pray they know some UX.

And this is kind of what we try to model differently in GetCalFresh:

For example, we evaluate our document upload tool not by "clients can upload documents from a phone" (a requirements mindset)

but rather by "how many documents do they upload?"
medium.com/code-for-ameri…

And further, we are evaluating based on "how many documents they upload" to an even further *upstream* outcome — the correlation of document uploads with a reduction in denials due to missing docs (aka more ppl getting benefits)

And that's kinda the point:

we measure features not by "do they do the thing we said it should"

but rather by actual program outcomes (procedural denial rates)

And okay last point:

Technology, used effectively for measurement, also means you have a really effective way to measure the costs of complexity in POLICY decisions.

Having different definitions of income for SNAP and Medicaid is a policy decision. That complexity has a cost.

And it may well be the case that the cost of complexity (and concomitant friction) is worth it to achieve policy goals.

But I do believe one big promise of "digital services" in govt is making that complexity cost—which clients and administrators bare—transparent and known.

So yeah, technology can improve experience. But experience is also a determinant of program outcomes, and technology helps us measure it in a much more fine-grained way. And what we can measure we can manage, and simplify, and improve.

(End stream of consciousness)

BTW this seemed to resonate with a fair number of people. If so I recommend checking out papers by @donmoyn.