Read on Twitter
I gave a talk yesterday to a bunch of folks who do product work in government technology.
I heard my comments on approaches to “self service” were helpful — so I figured I’d share here in case any others could benefit.
(also helps me distill my own thinking)
I heard my comments on approaches to “self service” were helpful — so I figured I’d share here in case any others could benefit.
(also helps me distill my own thinking)
I've personally found "self service" portals to be an especially pernicious idea in govt services—they're downright dangerous.
The intent is good: let's make things easier for people!
But *really-existing* approaches to self service often end up as mere burden shifts to users.
The intent is good: let's make things easier for people!
But *really-existing* approaches to self service often end up as mere burden shifts to users.
There are usually two goals behind the development of "self service" options:
1. Make it easier for people, "let them get their stuff resolved without having to talk to someone"
2. Reduce workload for common requests
1. Make it easier for people, "let them get their stuff resolved without having to talk to someone"
2. Reduce workload for common requests
The problem?
If you build a self-service options, and it *doesn't* make it easier for people, but rather makes it more difficult
AND reduces your awareness of people failing to get what they need
...you've accomplished #2, but you've done so through, effectively, rationing.
If you build a self-service options, and it *doesn't* make it easier for people, but rather makes it more difficult
AND reduces your awareness of people failing to get what they need
...you've accomplished #2, but you've done so through, effectively, rationing.
There's a dimension to such services that is, "how easy is it for someone to express that it is NOT working" (and, corollary, how easy is it for the agency to know things are not working)
I call this, loosely, "receptiveness" (looking for better words)
I call this, loosely, "receptiveness" (looking for better words)
If you can call an agency and talk to a human, in general "receptiveness" is high.
If they ask you for your address, and you say you're currently homeless and couchsurfing, the other person can deal with that edge case immediately — "okay, I just need your city"
If they ask you for your address, and you say you're currently homeless and couchsurfing, the other person can deal with that edge case immediately — "okay, I just need your city"
...whereas with a web form that makes address a required field — that person is stuck.
You'll note — this person is *homeless*; an even more vulnerable user than on average.
(And that's where I get all weird in these talks and bring up a 40 year old anthropology book.)
You'll note — this person is *homeless*; an even more vulnerable user than on average.
(And that's where I get all weird in these talks and bring up a 40 year old anthropology book.)
The failure points of low-receptiveness service designs
(e.g. address required, no easy way to get help if you're homeless and in a more complicated situation)
do not create pain equally. They distributionally tend to have an outsized impact on the most underserved users.
(e.g. address required, no easy way to get help if you're homeless and in a more complicated situation)
do not create pain equally. They distributionally tend to have an outsized impact on the most underserved users.
Back to self service.
So again, we have two options:
- A person an end-user can call
- An online self-service portal
My rough hypothesis:
the quality of a self service option is directly proportional to the agency's situational awareness of its shortcomings, failure modes
So again, we have two options:
- A person an end-user can call
- An online self-service portal
My rough hypothesis:
the quality of a self service option is directly proportional to the agency's situational awareness of its shortcomings, failure modes
The problem?
The vast majority of self service options are built
- With a spec based on "official rules" (how things are on paper, not the messy reality captured in the call center calls, where staff handle the edge cases)
- Without monitoring for failure modes
The vast majority of self service options are built
- With a spec based on "official rules" (how things are on paper, not the messy reality captured in the call center calls, where staff handle the edge cases)
- Without monitoring for failure modes
FURTHER, there are two phenomena that I've seen commonly that are almost just like financial leverage on the troubled "self service" bet:
1. Orgs will use dev of a self service portal to justify reducing staff (the humans who are HIGHLY receptive to edge cases)...
1. Orgs will use dev of a self service portal to justify reducing staff (the humans who are HIGHLY receptive to edge cases)...
...
2. Funding is often such that a public agency can get virtually unlimited pools of money to invest in IT like "self service portals" while being constantly underresourced on staffing
So rather than "humans for human parts" it can be "let's automate/reduce work maximally."
2. Funding is often such that a public agency can get virtually unlimited pools of money to invest in IT like "self service portals" while being constantly underresourced on staffing
So rather than "humans for human parts" it can be "let's automate/reduce work maximally."
The most effective services deal with the whole distribution of end-user needs, *including* the ones not easily served by the assumptions undergirding the primary channel (like a web site).
So, ideally, they're always some mix of humans and tech: you *need* humans in the loop.
So, ideally, they're always some mix of humans and tech: you *need* humans in the loop.
So, anyway: what is my prescription for "self service portals" done right?
A couple things:
1. Make it easy for people to say "things are not working for me"
like, skip this question
or, choose not to create an account
And *measure* how many people take up that "escape hatch"
A couple things:
1. Make it easy for people to say "things are not working for me"
like, skip this question
or, choose not to create an account
And *measure* how many people take up that "escape hatch"
"But Dave," I hear from my kind-hearted friends dealing with persistent resource scarcity while trying to serve the public, "won't that increase workload?"
Well, a little.
But the alternative is not users succeeding: it's just your service failing, without visibility into that.
Well, a little.
But the alternative is not users succeeding: it's just your service failing, without visibility into that.
And that's the problem.
When "workload" is the primary visible measure, it is *not possible* to distinguish between that being caused by:
- Self service options WORKING for people!
- Self service options being so burdensome that people cannot get their needs met
When "workload" is the primary visible measure, it is *not possible* to distinguish between that being caused by:
- Self service options WORKING for people!
- Self service options being so burdensome that people cannot get their needs met
So that's why I go back to the anchor in the pyramid:
You need a monitoring layer on the failure modes of your self service option.
This is a wicked problem I think a lot about. It can be really scary to be an agency with public oversight and say "we want to know our failures."
You need a monitoring layer on the failure modes of your self service option.
This is a wicked problem I think a lot about. It can be really scary to be an agency with public oversight and say "we want to know our failures."
2. Approach self service intentionally with a view that it will always be:
- A hybrid of staff service and technology
- Focused on creating success for the end-user (and let them tell you if that's happening) rather than focused on the goal of reducing workload
- A hybrid of staff service and technology
- Focused on creating success for the end-user (and let them tell you if that's happening) rather than focused on the goal of reducing workload
You can do A LOT right with self service and automation.
The ACA web sites ( http://healthcare.gov , CoveredCA) can do automatic eligibility ON THE SPOT that you know immediately. That's great.
BUT there will always be outliers—and being an outlier correlates with vulnerability
The ACA web sites ( http://healthcare.gov , CoveredCA) can do automatic eligibility ON THE SPOT that you know immediately. That's great.
BUT there will always be outliers—and being an outlier correlates with vulnerability
(To illustrate this "your outliers are also your most in need" you should look at how income questions are asked in safety net programs.
The "easy self service" options really only work for simple situations—and the lower your income, the more COMPLEX your income situation is.)
The "easy self service" options really only work for simple situations—and the lower your income, the more COMPLEX your income situation is.)
3. I really do firmly believe that at some point we need some institutional arms-length monitoring of "self service" in public services.
Showing, in detail, how things don't work for people is not adversarial.
It can support the internal folks who already know, but can't say.
Showing, in detail, how things don't work for people is not adversarial.
It can support the internal folks who already know, but can't say.
You can have monitoring internally, but many of the actual root problems require people higher up to:
- A. Understand the specifics failure modes
- B. Understand potential solutions—and the tradeoffs! (YES we need more staff AND we need a better web portal; NO it's not 1 of 2)
- A. Understand the specifics failure modes
- B. Understand potential solutions—and the tradeoffs! (YES we need more staff AND we need a better web portal; NO it's not 1 of 2)
Something tech is good at/fit for at a cost structure is handling "horizontal" situations.
I still think that while the long, hard work of advocacy and engagement on these issues require non-tech orgs, tech can provide massive value to such a need for monitoring.
I still think that while the long, hard work of advocacy and engagement on these issues require non-tech orgs, tech can provide massive value to such a need for monitoring.
Ideas I return to time and again is:
- Show, don't tell: just have damn screenshots of everything
- Look for where people go when things are failing them (Facebook, Reddit—users *have* the answers)
- "Friction Maps" of services to just say, sans judgment, this is what it is
- Show, don't tell: just have damn screenshots of everything
- Look for where people go when things are failing them (Facebook, Reddit—users *have* the answers)
- "Friction Maps" of services to just say, sans judgment, this is what it is
OKAY enough coffee-tweeting for today. Hope some of you found this useful. And if not, how did you make it this far??
(Kidding, but also genuinely appreciate constructive engagement with these ideas. Let's build the best shared understanding we can here.)
(Kidding, but also genuinely appreciate constructive engagement with these ideas. Let's build the best shared understanding we can here.)
This is a point worth expanding on:
Just because you don't provide an escape hatch doesn't mean people don't go SOMEWHERE!
People in need find a way. And, these days, you can often find the failure modes visibly. See: all the FB unemployment groups. https://twitter.com/rjsheperd/status/1263495404722651137
Just because you don't provide an escape hatch doesn't mean people don't go SOMEWHERE!
People in need find a way. And, these days, you can often find the failure modes visibly. See: all the FB unemployment groups. https://twitter.com/rjsheperd/status/1263495404722651137
