The site has never really lived up to its potential, but hopefully this will begin to change now that it has moved beyond past issues and could get support from 18F and U.S. Digital Services.
NextGov has a short historical overview of the vendor issues related to its storied past, FierceGovernmentIT’s Molly Bernhart Walker has a great post with respect to the release’s impact on businesses who rely on the service as part of their core offerings, as does Washington Free Beacon’s Elizabeth Harrington related to the impact on transparency.
Regardless of the vendor drama and complexity around delivering data specific to USAspending, here is a simple formula for any government working on the release of a new public-facing website:
- Data first, design second. Regardless of what the site looks like, the data should be publicly accessible via an application programming interface or bulk download. Every government website that launches from here on out should have a data strategy and execution plan before a web design and development one, and this includes a legal understanding that no vendor can ever claim ownership of government data.
- Open the analytics. It’s important for everyone (internal and external stakeholders) to have access to the same information to understand how well a site is performing and have visibility into current user behavior. This aids in the next point.
- Get public feedback. Getting feedback based on expert opinion, whether it’s on the particular subject matter of the website or general digital strategy, a public request for information is essential. Per the above point, it’s important for everyone to have access to the analytics to help drive feedback, as well as realize when that feedback is right or wrong.
- Go into beta. It’s unclear to me why this is rarely done, but having a beta version of the website allows for a softer launch that takes into account early feedback and is a foundation for the next two points. You’re not going to deal with a major public outcry if it took four weeks to build something and are constantly iterating over the days, weeks and months after the initial launch.
- Get public feedback on the beta. Most government agencies launch public betas but fail to publicly display or respond to feedback so that others can see and comment. Using GitHub issues is a great way to do this, because those comments can be easily baked into the next point.
- Make changes based on analytics and public feedback. This eliminates internal decisions to include unnecessary features, like homepage sliders or photos of the mayor in the header, and instead focus on real user needs.
- Make the source code publicly-available at all times. I can’t believe we’re still having this conversation, but code developed for government purposes should be accessible, commentable and contributable at all times.
- Provide a public roadmap. A roadmap allows the public to have insight into what is currently being developed or considered for development. This shouldn’t be overthought, but more of insight into the focus for the next four weeks. This lets those not directly involved understand what they can expect in the next release without being surprised by a radically new design.
- Regularly and publicly document updates. Blogging what’s been done and why is important in effectively communicating new changes. GOV.UK does a great job of this. Currently, we see this in the form of nothing or an obscure accepted pull request or code push on GitHub. Never underestimate the importance of the narrative.
The history behind USAspending.gov is an interesting anecdote on building a complex, data-focused website. The previous vendor-related drama and data complexity make it somewhat unique, but by no means should it or any other government website be hindered by a simple, iterative approach for introducing a new citizen-focused, public-facing digital service.