On Self-Service and Support-Driven Development in Government Technology

The catastrophic fires in Northern California have displaced thousands and have put many people in our state suddenly in need of immediate assistance. Over the past two weeks, our GetCalFresh team has been supporting the efforts around the recently announced availability of Disaster CalFresh. D-CalFresh is a special version of the food assistance program that gets activated in the event of a disaster to help those suddenly without sufficient food resources. About half of our team went to Sonoma County for two days and worked with a coalition of CalFresh outreach organizations coordinated by the California Association of Food Banks. The team put up posters about D-CalFresh and helped people apply.

Meanwhile, back at Code for America HQ, the other half of our team has focused on digital outreach, primarily through a dedicated info page on GetCalFresh that uses clear, friendly language and design to communicate the key things folks need to know about D-CalFresh.

One of the first decisions we made was to put a live chat pop-up on our D-CalFresh page. We offer live chat throughout all of GetCalFresh, but in this case when someone comes to the page they get a message asking if they have questions.

We added this for two reasons. First, we want to go above and beyond to support D-CalFresh eligible people since it is only available in a seven-day window. But the bigger reason is that we have significantly more uncertainty about D-CalFresh users’ needs. We needed to learn, quickly.

• Does our page answer the most common questions most people have?
• Does the page give information that is actionable enough to get people to go ahead and apply?

If self-service doesn’t work for users, it doesn’t work

This got me thinking about the notion of “self-service” in public service technology. It may seem contradictory, but one of the best ways we’ve found to reduce the need to manually help people is to manually help people more — just at the right time and place.

A lot of public sector technology projects tend to be framed as “self-service” options — an easy way for people to get their problems solved themselves without the having to talk to staff, whether that’s calling a call center or going in-person to an office. And this is a good goal! When people have a need, they want it met, and the easier the better. Usually waiting on hold on the phone or waiting in line at an office is a big hassle, and so if they can get their need met with an easy visit to a website that’s often the best experience. And it frees up staff time to be able to focus on people who may have a deeper need for person-to-person assistance.

But the problem arises when users get stuck at a point in the self-service option, and there aren’t easy ways to get themselves unstuck, the self-service option backfires against its own goal: either sending more people to the office out in frustration, or submitting duplicate and triplicate transactions hoping they got it right or the form finally went through.

To riff on a common saying from UX: if a self-service option doesn’t work for users, it doesn’t work. Self-service options can end up being self-defeating if they don’t meet users’ needs as they exist here and now.

With GetCalFresh, we try avoid this quite intentionally: if a user has problems, we want to know, and we probably want to talk to them. We offer live chat, text message, and email help to everyone. These are critical to knowing how well we’re meeting user needs, and how we can improve.

One example: very early on, the most common live chat question we got was “what’s my household?” That’s because one of our first questions is about household size, and lots of people have complex living situations in a high-cost state like California. We would frequently hear from people living in San Francisco with lots of others, crammed into a small apartment. Are their roommates part of the household? The answer, for the purposes of CalFresh, was no, so we told people that! The answer: a household is who you buy and prepare food with. (Of course there are exceptions to this, but a core part of this work is distilling significant policy complexity into a simplification that is net-beneficial to the user.)

Today, the application itself clarifies right up front: How many people live in your household, including yourself? Only include spouses, children, parents, and people who you regularly buy food and make meals with.

How did we know to do this? We made it easy for users to tell us when they were confused (live chat) and then answered the question 10 or 15 times there. Then, we adapted the technology itself, and built it in pretty quickly thereafter.

This is an example of Support-Driven Development [1]. What that really means is intentionally and proactively providing an extra-normal level of support and manual help to users in order to learn about the barriers people are hitting. From the start, we’ve offered live chat, text message, and email support with the explicit goal of figuring out where people were getting stuck in the process of applying for CalFresh. We can address some barriers with technology alone; others require collaboration with the county offices in California that administer GetCalFresh: for example, giving clients the best way to reschedule interviews in their county, or figuring out ways to get high-quality verification documents from clients to counties in a way that works well for their business processes.

All of our work on GetCalFresh has been driven by a relatively simple principle: find client barriers, remove client barriers. Helping people manually, in ways that intentionally don’t scale, is a key part of that.

But the important thing here is we don’t necessarily do aggressive, proactive support for everybody or for every part of our service. We give outsized support on the parts of the service where we have lower certainty: whether it’s the right solution; for how many of our users is it right; and for whom exactly it’s not.

Put another way: if you could only manually help 20 people each day, which problems would you choose to learn enough about to make them non-problems tomorrow?

Again, it all comes back to uncertainty and closing the loop. One of the best ways to increase the percentage of users that who can self-serve is providing proactive, above-and-beyond support to real, live users who are trying to solve their problem on your site and changing the service based on what you learn from those users.

Even given a fixed amount of support time, if you can learn and make changes to the service at a reasonable enough pace, then the number of people able to self-serve should go up and the amount of time spent manually helping people (whether through proactive support or those who go out the escape hatch to your lobby) should go down.

The unstable equilibrium that those overseeing government digital services should fear is false confidence in self-service options. Just being able to say “a customer can do X online” doesn’t tell you how many do do X successfully online. If self-service doesn’t work for end-users, it also doesn’t work for staff — because they’re the escape hatch.

Code for America by no means invented this approach, but it’s not very common in public sector technology projects — we think it should be more common.

Here are some tactical things to consider when thinking about redesigning or improving a government website or online transaction:

• Consider starting by adding a live chat box to the existing site (we like Intercom). Figure out where people are getting lost now. If the site gets lots of traffic and you worry about capacity, you can usually do a little bit of configuration to show it to only some % of visitors. And it’s completely okay to turn it on for a day and turn it off (people have no expectation of it now and offering it briefly doesn’t radically change people’s expectations.)
• Look for what the current site’s “escape hatch” is.
• Does it have an e-mail or web form for users to report problems to? Where does that go and what have people said?
• Identify the other (offline) channels people may use when the online option doesn’t work for them. Ask your call center if they get people calling after having problems with the web site, and what they are. Ask your front line staff in the lobby or elsewhere what feedback they hear about the online options.
• Does it have some measurement of a funnel or conversion, like Google Analytics or a way to see how many people started a transaction vs. how many actually finished the transaction?
• If you offer smartphone apps, look at users’ reviews and comments in the iPhone App Store or Google Play Store. I do this occasionally for different government native apps. There are two instances I remember vividly:

The first was a litany of complaints about how choosing your birthday involved scrolling down from today’s date over and over again until it went years back in the past to when you were born. This kind of interaction design feedback is great and also often easy to address if you actually get it!

The second was someone saying that front line staff was advising the user against using the app because they couldn’t guarantee that documents uploaded via the app would get to them. This is likely either an opportunity for staff education or a symptom of a bug that can be tracked down/tested with this kind of concrete detail.

[1] I’m certain others have said this before me. In fact, a Google search suggests Wufuu co-founder Kevin Hale coined it.