By GovFresh · February 4, 2014
[caption id=”attachment_17086” align=”alignnone” width=”1004”] beta.govt.nz[/caption]
Perhaps the biggest civic open source story of 2013 was the government of New Zealand’s copying of the United Kingdom’s gov.uk code to begin building a new version of its own website, now located at beta.govt.nz.
New Zealand Principal Advisor for Digital Engagement Jared Gulian shares how they did it, why, what they’ve learned and what plans they have for the future.
What inspired New Zealand to take advantage of the gov.uk code for its own website
It just makes sense. As a government agency, we’ve taken a new approach to design and development which borrows from the user-centered, agile, iterative development techniques implemented successfully in the private sector to deliver useful online products.
As part of our initial research we talked with teams in governments around the world running national portals and digital services. We were particularly inspired by the work of the Government Digital Service team in the UK. Their commitment to user-centred design, site iteration based on feedback and transparency is very compelling. And we were smitten with their design principles.
Through our research, we also found that the challenges we were facing were global: working with less money and fewer resources while still trying to meet the growing expectation for government to move online.
While Govt.nz didn’t use gov.uk code or design in our alpha phase (February 2013), we realized back then that GDS was already solving the same problem we were facing. By building on what they’ve done and adapting their basic design elements, we were able to save time and money plus deliver a better quality beta website in August 2013.
Adding to that, we are a small jurisdiction with smaller resources so it made sense to leverage their work any way we could, with acknowledgment and permission.
We have done a lot to adapt their work to the New Zealand environment, and we’ve continued to do specific user testing to make sure that our website meets the needs of people wanting to access government information and services here.</p>
Since one of our principles is making evidence-based decisions and our research was corroborating theirs (our users had the same difficulties online), it was a pretty easy decision.
Did you or how did you collaborate with UK's GDS team?
This relationship has been mostly informal and ad hoc. We like their work; we’re watching how things develop. They like what we’ve done; they’re watching how we’re doing. And it's been about sharing when the learning is relevant. We’ve been having conference calls with various people at GDS since way back when we started our initial research. Last year, GDS Director Kathy Settle spoke to our team about engagement by conference call. In 2012, GDS Quantitative User Researcher Lana Gibson visited with the Govt.nz team when she was in New Zealand visiting family. Lana is an expat Kiwi who is the user data-analysis expert behind gov.uk's award-winning content. Our own expat Brit Bene Anderson (product manager for the existing newzealand.govt.nz) stopped by GDS while in the UK for a family wedding. And, thanks to social media, people on both teams follow each other on Twitter and subscribe to each other’s blogs to keep up to date on the work. GDS has also indicated to the team that they consider the gov.uk-govt.nz connection as one of the key developments from gov.uk’s first year. We’ve even provided some feedback to their Cabinet Office around this. So it’s all very human and mutually supportive. Recently the Guardian ran an article about our projects in their Global Public Leaders series. The piece was delivered jointly by UK Minister for Cabinet Office Francis Maude and New Zealand Minister of Internal Affairs Chris Tremain. So there’s collaboration at all levels. But we haven’t limited our outreach to the UK. From the US, we’ve also had great conversations with Gwynne Kostin from the Digital Services Innovation Center, Sheila Campbell from the Center for Excellence in Digital Government and Sarah Crane of USA.gov. And I was interviewed by Chris Dorobek for the ‘Dorobek Insider’ podcast which appears on the Govloop.comwebsite. Closer to home, we had a visit from the super Rita McPhail from South Australia who has been instrumental in the adoption of the franchise model for collaborative content development on the government’s sa.gov.au. We’ve also talked to Tom Canning from New South Wales about their plans for Service NSW, a one-stop-shop for government services replicated across all the channels to improve service delivery and reduce costs.How is it evolving into something different based on the needs of your own citizens?
We’ve done major research on local problems, local needs, local ways of thinking about government, and local priorities. While we’ve adopted what other countries are doing to meet their users online needs, we needed to make sure that the solution we came up with meets the needs of our users.Problem definition
After our initial research, we talked with people around New Zealand to understand the issues they face when dealing with government online and how they think about government information. We did focus groups, online card sort tests, and face-to-face facilitated testing with early wireframes. All of that problem definition research is publicly available. It shaped our understanding of the local problems we are trying to solve. In addition, the results of the online card sort tests formed the basis of our current information architecture.Content
When it came to pulling together our early ‘thin content’ for the website, we once again turned to evidence from our users: analytics from the current newzealand.govt.nz and key government websites plus stats from Google’s keyword tracker tool. We wanted to know what tasks people were going online for so that we could start there. That evidence helped us prioritize our content and decide where to focus on first. There are blog posts on our Web Toolkit about the ups and downs of developing content.Alpha prototype
We then put that carefully prioritized content into an alpha prototype, which was a limited release website used to test our assumptions. We used the alpha in face-to-face facilitated testing with real, live New Zealanders. That taught us a lot about what Kiwis needed to move around an ‘all of government’ website.Visual design
As our front end templates have evolved, the actual code has developed beyond recognition from the UK code. Plus our technical platforms are very different. We’re using SilverStripe on the NZ government Common Web Platform and the UK is on Ruby on Rails. However, the GOV.UK front end visual design has remained a cornerstone for us because our user research tells us that the straightforward design makes it easy to use. All of our research has fed into our solution: a truly user-centered, customized product designed to meet the needs of New Zealanders.What plans do you or how are you contributing code back?
Our project developers are working to open source key modules developed for beta.govt.nz that will be of use to others. In New Zealand, other government agencies have already expressed strong interest in re-using several of the modules that were developed for the Common Web Platform. This platform is the SilverStripe open source content management system based on a common infrastructure. As always, our mantra is that we will start small and iterate — at first releasing key modules and then eventually open sourcing the entire code base. We're open sourcing our code starting with our ‘replicant’ module, which allow us to ‘grab’ the content from a live site and add it to the test environment. Because CWP is an all-of-government platform-as-a-service option, this module can be used by anyone using the same platform. We’ve also started work on an API based on an existing CWP module. Once it’s completed, it’ll be open sourced as well.What have you learned about the process that you'd recommend to other agencies/governments?
There are four key lessons:- Don’t start from scratch. Build on what others have already done.
- Start small and iterate. Adapt as needed (see #4 below).
- Share what you do even if it doesn’t work like you expected.
- Base your decisions on evidence: user testing, feedback and more user testing.