The digital lifecycle

We cannot solve a problem by using the same kind of thinking we used when we created them.

Albert Einstein

The digital lifecycle

Stemming from what we learned in Govt.nz’s agile journey before its launch in 2014, the digital lifecycle is a draft guide to balancing the need to deliver to truly user-centred needs with the requirements of operating safely on the government domain.

The digital lifecycle can guide agencies to:

  • ask the right questions at the right points
  • meet user needs
  • ‘bake in’ the basics like security, privacy, accessibility, and information and data management.

It’s a Beta and we intend to evolve it in response to feedback from agencies willing to try it. To be honest, it was triggered by our frustration at having to catch issues such as accessibility barriers late in the development cycle. This led to the realisation that there was something flawed in how we were working so we thought a lifecycle approach might help us get things right.

Since others may find themselves in similar circumstances, we want to share the tool that changed how we viewed our work. If you think it helps you — or gets in your way — to build better services or products, please tell us how to improve this lifecycle approach.

The public sector context

In the wake of Web Standards Self-Assessments of public sector websites, most of us know that repairing websites can take time and effort. Time and effort that could be spent on delivering well-written content, undertaking user research or improving the user experience, is instead taken up with fixing problems that shouldn’t be there the first place.

The same can be said about security, or the user experience: identifying and fixing vulnerabilities or usability issues on a live site can be costly and difficult.

Let’s be clear, we should constantly be monitoring live sites to identify issues that degrade accessibility, security or usability. But it's better to plan for these activities from the beginning of development rather than trying to fit in fixes in some imaginary future when you have time. Better planning results in a sounder foundation for a website.

When developing a new site it’s easy to focus on the functions and features that an agency wants to deliver online. It’s better for everybody when those functions and features are delivered on a solid foundation that won't need fixing late in the development cycle — or after launch.

Hint: You don’t want to be the folks we heard of recently who planned to ‘add in the accessibility features’ (!) after the site was built. You want to be the organisation that plans such things upfront, builds them into its development cycle as business-as-usual and avoids unpleasant budget surprises before launch.

The origin story or how the digital lifecycle happened

Govt.nz was created in phases. (You’ll find plenty of experiences that the Govt.nz team shared on this blog.) From early on, a great deal of effort went into research and exploration to understand the landscape, modelling user personas and the issues they faced, experimenting to imagine a desired state, and so on. This was the discovery phase. It preceded an Alpha phase in which various scenarios were drafted and thoroughly tested with real users in a host of ways. It led to a Minimum Viable Product — in effect a working model from which to build a Beta version of Govt.nz.

In the Beta phase, the site was fleshed out as a replacement for the old newzealand.govt.nz. Increasing functionality and content were based on input from real users as the site matured. In mid-2014, it became the government’s flagship web presence and its predecessor was decommissioned. At that time the site went into production as the ‘live’ Govt.nz.

The process — a somewhat innovative one for government — is a great way of delivering around the needs of users, but it posed some challenges too. Such as how to balance the level of assurance around meeting our various obligations (accessibility, security, information and data management and the like) against the practical requirements of the various stages of iteration. That’s not easy with a continuously evolving model; you don’t get the opportunity to check everything before hitting the big Launch button — but it helps if you can build it in as you go.

Comments are closed.

Navigate Posts