Recently, a federal agency shared a beta version of its new website for public feedback. I quickly reviewed the site, easily added a few comments (please, no more carousels) with the help of a very accessible feedback tab. Feeling satisfied I’d participated in some form of civic collaboration and engagement with my government, I moved on.
Curious as to its progress, I re-visited the test URL last week only to find the site had been taken offline with a message indicating the beta period had ended:
“We appreciate the time and effort put forth by our users to help ensure that our final launch is a success.”
Since my initial, and subsequent, visit, I’ve been thinking about how government can build a better beta, because I’m unconvinced this process is relevant in today’s development environment, especially when you take into account the increasing role digital government has on civic engagement and collaboration.
While I was able to comment on the beta, as a citizen, I’m not completely satisfied with the process, especially the idea that there’s a “final launch,” typical for .gov beta launches, for two reasons. First, I’m not able to see feedback from others, comment on and vote up or down (and vice versa). Second, the idea that there’s a final launch is outdated and overlooks an opportunity for deeper, continual feedback.
After thinking about this more, here are some ideas to change the way government builds web products and thinks about the .gov beta.
Publicize your user stories
Identifying your user stories is an important aspect to getting external feedback, because each demographic is able to come into the process knowing which lens to wear when doing so. Having these identified also allows you to ask the user which story they associate with (“I am a patient/doctor/insurance provider, ..”) which lets you better put into context that feedback.
Push your code to the public
There are two solid reasons for doing this. First, others can contribute back and help build the site. If you’re a small government IT shop, and you want to expand your development team, opening the code to outside developers and sharing your roadmap (see below) will do this, especially if you’re actively pushing their work back into your project.
Second, you’re giving back to the community which can have huge economic, entrepreneurial and innovation impact. NASA Spinoff, while not just code, is a great example of how government is bringing IP to the commons. Every development agency working for or with government should be doing this.
Publicize feedback and development response
No one does this better than Data.gov. With a public repository on GitHub, anyone can follow development activities and submit issues. Data.gov lead Jeanne Holm and her team are active in posting comments. You’re also able to open comments and ask questions to the public, such as “Should we have a carousel?”.
Share the roadmap
Building an iterative approach into your development and responding to public feedback suggestions doesn’t mean you don’t need a long-term plan, even if it’s just 3-6 months out (and it shouldn’t be much longer). Giving insight into what features you’re thinking about integrating into your product allows others to understand what you’re working on and planning for. Visibility into both progress and future development expands opportunity for collaboration and even offers you a chance to solicit open requests for information on best practices ahead of time.
The product is never done
As government technology projects see more public scrutiny, we’re becoming more exposed to the benefits of agile (as opposed to waterfall) methodologies and the benefits of shipping early and often. All too often a government website is launched to much fanfare, only to see little changes occur in the proceeding years. We need to get out of the habit of thinking a government website can’t be improved immediately, but should be done so on a daily basis.
The new .gov beta is more than just how government should launch a new website.
Beta isn’t a product. It’s a mindset.