Digital lifecycle – Beta

BETA. This draft guidance is provided as a ready-reference for business owners and project teams in government agencies planning online delivery. It draws on the approach of the UK government's Digital by Default Service Standard, released under the Open Government Licence v2.0. We invite feedback from agencies.
  • Build services around the needs of users.
  • Think about the lifecycle of digital delivery.

In this phase you’ll be developing and refining your service based on feedback, and preparing it to become a live and fully functional system. Your focus now is working with users to move from a prototype towards a viable, sustainable service. Depending on your product, there may be a lot to consider to lay a proper foundation for a production service. Don't underestimate the amount of effort you'll need to invest in this phase.

Even though you're in Beta, it's essential to have assurance from the outset that the service you're building meets the standards and policies required on the .govt.nz domain – privacy, security, accessibility, good practice in information management and strategic alignment with government priorities.

Questions to answer in the Beta phase

As your Beta progresses and is refined, you should consider and answer these questions.

User feedback and ongoing research

  • What can you learn from the evolution of Govt.NZ?
    • Govt.NZ set an example for some of the issues you'll face in moving from a prototype to a sustainable service. You should review how user feedback shaped its evolution.
  • Does your organisation have a service design team who can provide advice?
    • If not, can you partner with another agency that can provide advice?
  • How can service design methods help shape your service?
    • User experience design is complicated. Review the methods and tools you have available to decide what can best inform your design decisions.
  • How are you testing your design choices?
    • By now you should be undertaking a rigorous analysis of how users experience your service, and you should have a method for dealing with feedback that can inform design decisions and project priorities.
  • How is your content performing?
    • Do you have an ongoing program of user testing in place? Does it test users' comprehension of your content? Does it offer any insights to the effectiveness of your Information Architecture and labelling?
  • Is your analytics solution giving you enough evidence?
    • By now your analytics should be well tuned to provide detailed insights into how the service is used, and its performance against business requirements.
    • Are there ways in which it could be better tuned before you move into production? If you're just tracking visits and page views you may want to consider additional metrics. Can you track completion rates for your service? How are you measuring bounce rates, pathways through the service and user satisfaction?

Privacy

Security

  • Have you documented your security testing and assurance plans?
    • Security testing must be an integral part of your project planning. You need to ensure that enough time, budget and resource is available to provide adequate levels of assurance during development. At some time your system will need to go through a security accreditation process.
    • Is it in accordance with the requirements of the NZISM?
  • Does your development team have expertise and process in place to assure you that your security requirements will be met?
    • Can they articulate the OWASP Top Ten, for example, and how they are relevant to your project? Your developers and project team must be aware of your security requirements and be able to demonstrate how they are embedded in the development process.
    • Is there a security champion on the team?
    • Are they reviewing their approach with your security advisers from time to time?
  • Have you developed policies and processes in place to preserve the ongoing security of the service?
    • While a service may be adequately secured when it’s launched, its security profile can be eroded over time without adequate management. All services can be expected to meet a minimum baseline; services dealing with more sensitive information will require more extensive measures to safeguard their security.
    • What would be the consequences if the confidentiality, integrity or availability of the service were compromised?

Accessibility

  • Have you put in place appropriate tools and quality assurance processes to ensure your content can be understood?
    • What specific design research has been done around issues like literacy levels and the readability of your content? Can your team help content owners write in plain English?
  • Are you planning an accessibility audit, and checking the basics during each sprint or phase of development?
    • In the desire to build the latest best features into your service, sometimes things slip through the design process. Simple tests like ensuring your design meets the minimum colour contrast required, that your service can be navigated using only a keyboard, how forms handle erroneous input and testing using different sized screens and devices are easy things to do. Errors on simple things like these can be indicators of deeper issues.
  • How are accessibility issues being handled?
    • How do your developers and content authors go about testing for and identifying accessibility issues? What are they doing to deal with them? Are fixes being prioritised?
    • Are accessibility checks part of each sprint?
    • Does your user testing include people with disabilities?

Information and data management

  • How will the service meet basic Information Management principles?
    • You need to be sure your users know who they're dealing with, that the information they're being given is reliable, trustworthy, timely and accurate, and that it's being actively managed.
  • How will content versioning or archiving be handled as the service evolves?
    • If required, how will you recreate a point-in-time record of the service?
    • Are versioning and archive facilities adequate to recreate a previous snapshot? Are logging and record-keeping facilities adequate to provide a reliable history of user interaction with the service? Would they be sufficiently robust to withstand a potential legal challenge?
  • How do you plan to make sure that users can continue to have confidence and trust in the service you'll provide?
    • What measures will you take to ensure the ongoing integrity, authority and reliability of your service?
  • Is it clear to users what they can and cannot do with your service?
    • Does your service carry clear licensing and/or terms of use statements? Does it describe how it can be used or re-used, and what to do if they want to suggest improvements (or discover a flaw)? Do users have a safe and reliable way to provide feedback?
    • Web content should generally be licensed for reuse under a NZGOAL license.

Governance

Output from the Beta phase

At the end of this phase your service should either be approved to move into a production environment, or closed down with lessons learned. Approval to proceed should be straight-forward if you have of the following:

  1. A functional service ready to move into a production environment.
  2. Operating budget including allocation for periodic testing and ongoing enhancement, including a backlog of further enhancements to be developed.
  3. Service roadmap outlining the technical direction the service will evolve in.
  4. A detailed content roadmap or content strategy, including a style guide for the service (language and visual style).
  5. An updated user research plan that reflects learnings from the Discovery, Alpha, and Beta phases.
  6. Documented support processes, change management process, operating guide or operator training materials.
  7. Security documentation and system security plan as required by the Protective Security Requirements.
  8. Analytics data collection mechanism to allow measurement of service uptake and KPIs, and ideally a plan for making that data open and publicly available.
  9. Documented governance structure and responsibilities.
  10. Formal signoff by your CE that the service meets required government standards and policies, and acceptance of residual risks, prior to going into Live phase.

Navigate this guidance