Disclaimer: As I work for the Washington State Administrative Office of the Courts, this posting does not reflect the opinions of that office or the Washington State judiciary. I speak here as a private citizen interested in improving the way government functions. Nothing here implies or otherwise suggests the support of my employer or of the Washington State judicial branch.

This is the second in a series of blog posts expanding on the four ideas I consider central to government experience design: transparency, listening, adaptability, and open-source. In all four posts, I aim to provide concrete ideas for how governments can use each of these items to respond to and engage citizens.

Listening
As someone who wears hearing aids, this is one of those topics near and dear to my heart. Unfortunately, it’s also one of the hardest to get right. Something I frequently tell people when I talk to them about my hearing is that i can hear what you say without understanding what you say; I register the sound and I know something was said, but the sound, for whatever reason, did not translate into something I could understand. More often than not, this results in frequent "huh?" or "excuse me?" comments in the hope of trying to figure out what was said.

Government can run into the same issue – the people they represent can ask for something and whomever handles the request does, indeed, succeed in giving them something, just not what the requestor actually wanted or needed. This is something very common in library science, and is frequently referred to as the identification of user needs. This is hard to get right without being willing to ask questions and drill down to the difference between what was asked for and what was really meant by the request.

So, really, when I talk about listening, I talk about two parts: hearing what was said, then translating from request to action. When government engages citizens, the process should look something like this:

1. A citizen makes a request through some medium. This can be electronic, physical, whatever. The point is, this person has a need and believes that the person or office they have contacted can resolve that need. They have stated what they believe they want.
2. The recipient of the request works to identify the true nature of the request. They talk to the citizen to try to determine what they really want based on the initial request. Sometimes, this really will be what was contained within their first statement; others, because the first statement was vague, requires some repeated questioning to figure out what should be provided in response.
3. The citizen confirms that what the recipient of the request heard is really what they want. This should be a straight "yes" or "no". This is basically putting a stamp of approval on the request that verifies that what they are told they will get is actually what they want.

   This is actually a key step, since it validates for both parties exactly what will be delivered, and provides a measure of protection so that, if the results of the request are contested, both parties can refer back to this validation step to determine what happened.

4. At this point, two things can happen: either the information or data requested is provided by the recipient to the requestor, which closes the transaction, or the request is denied and reasons why are clearly explained. If the request is denied, it must be made clear why the request is denied in such a way that the person requesting the data or information feels as if their needs have been respected and that government is still working to represent them.

At no point in this process is the citizen’s need for this information questioned, assuming that the request is made for something reasonable that does not put either the requestor or the recipient of the request at undue risk.

In both the original blog post and here, I have hopefully made it clear that the denial of any request should make the requestor feel as if they are still being well-represented and respected by the government agency the request was made of. Agencies cannot alienate citizens by not providing them clear and well-documented reasons for why their request is denied. Citizens must feel as if they have ways of appealing whatever decision is made. The initial denial of the request cannot be the "last say" in whether they can access what they asked for. This is to provide checks and balances; if the request was incorrectly denied, there needs to be a method of correcting the situation to everyone’s satisfaction.

In the original post, I also called this "civility", because it is – the art of listening is about honoring the person that you are listening to. Under no circumstances does this mean that the person is right, merely that they should be respected. This applies even if the requestor becomes rude or begins to cause problems because they believe they are treated unfairly.

Can listening be translated to software design? Absolutely, but it takes a different form in some ways, because when designing software, we need to be somewhat more circumspect and cannot simply throw the user into an endless loop of trying to define what they’re looking for. Software should be written in such a way that users should be able to try one or two methods of finding what they need before being directed to a human. Solely providing the software as an interface to find what they need is not acceptable, both because software cannot perfectly define a query if the person making the request cannot do so for themselves and because not everyone has easy access to that software (because of disabilities or for other reasons).