This article was originally posted here and has been adapted and reformatted for readability.

This is the final article expanding on the four ideas central to government experience design: transparency, listening, adaptability, and open source. In all four posts, this site aims to provide concrete ideas for how governments can deliberately think about the experience that citizens have when interacting with them.

Open source is a subset of transparency; it is called out separately because it warrants a bit further explanation. The open source software movement is the idea that, by publishing the source code of a particular piece of software, that software will become stronger because many eyeballs are reading that source code and thinking of improvements and finding security flaws. This philosophy is easily extensible into the government domain; what would it be like if we could crack open the source code of government programs (once again, within reason) and help to find flaws in logic and computation? What if citizens could save governments money because they fixed bugs?

The idea extends beyond software as well, to being able to see how legislation evolves over time - imagine being able to see the original draft of a piece of legislation, then how that legislation was changed, with each legislator's change listed clearly for all to see. Watching how a key law changes over time to reflect the current state of affairs can be a valuable tool in the citizens' toolbox. Think of it as "Track Changes" in a word processor; auditability becomes a key component of determining how government is working in the interests of the people.

That's not to say that open source ideals will always make sense or should always be used. Does it always make sense to allow for the "many eyeballs" philosophy to strengthen government operations? The most straightforward example I can provide here is the judiciary; it doesn't make sense to pry open the books on parenting proceedings, for instance. There are some facets of what the judiciary decides that do not warrant visibility for the level of impact they provide. There are other examples of when applying this ideal may not make sense. The point here, though, is that those examples are necessarily limited and well-justified.

Government should:

Government experience design is less about nitpicking over the details of whether or not a certain government agency should or should not release information and whether it needs to focus on the needs of the people it serves; instead, it focuses on mileposts. There are varying degrees of implementation of government experience design principles, and it is a fairly easy argument that there are deeper and more varied facets than what this series outlines. Part of why this series was written was to "open source" this idea and begin a conversation: what does it mean to engage with government? What does it mean for government agencies to serve the people? Which people? With what services? Do those agencies have any rights to withhold even when they operate within the public realm?

Is it enough to throw information management and user experience design philosophies at government and call it done? No. Government tends to be slower to evolve than other companies; to a degree, they can afford this. This is a funding problem, a person problem, an information problem, a philosophical problem, an environmental problem, and a cultural problem. What tools, then, can government begin to use to better itself? Government experience design proposes that the first step to that is a basic set of tenets, upon which agencies can build. It is not at all a panacea, nor is it intended as one. It does, however, start a conversation; one that, in this author's opinion, sorely needs starting.