Digital lifecycle – Alpha

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.

During the Alpha phase you'll be drafting and testing prototypes of aspects of your site or service, to gather input from users and knowledge about ways in which the problem statement can be addressed.

Your objective is to develop a basic working model. Base your efforts on your research in the Discovery phase and shape it in response to what you hear from users and stakeholders. Try to whittle down the scope of your work as much as you can, so you can keep your focus on the problem statement.

Iterate through prototypes based on feedback. You might start with paper wireframes and create working prototypes later.

One prototype is not enough; you need to show users a number of options to collect meaningful feedback. The more prototypes you can test with users, the more knowledge you'll gather about addressing the problem statement. You can do your prototyping and user research with a closed audience, or on the public internet accessible to all.

As your concepts evolve, you'll need to be thinking in advance about how to address requirements of security, privacy management, accessibility and information management in relation to the nature of the service. Doing so later in the project can add risk, cost and complexity.

Through this phase you should learn what and who you will need to progress the service into a Beta phase and whether it's actually worth doing!

Questions to answer in the Alpha phase

  • Is your vision of the future state agreed by those involved?
    • Involve your stakeholders and users to agree what a successful future state might look like.
  • Can you show how potential solutions or components might work?
    • Basic prototypes can bring a concept to life and help bring people on the journey with you. What does the feedback about them reveal about the problem or opportunity? Are your assumptions about the problem or opportunity still valid? Trial as many prototypes as practical. This will provide valuable knowledge on the direction of the journey.
  • Have you had a look at what others in government are doing?
    • It pays to check that you're not re-inventing the wheel; it may save you time and money. You may find that work already under way in other agencies can help you reach your objectives, or you may benefit from what they've already learnt.
  • 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.
  • Are you exploring all your design options?
    • There are many tools and techniques you can use to test your assumptions and decisions. Now is a good time to review your approach.
  • Have you thought ahead?
    • What other factors will you need to think about as you head into a development phase? Accessibility for people with disabilities? How to secure the service? Managing users’ privacy? Meeting the requirements of the Public Records Act? Requirements to use common capabilities? How to measure the success and cost of ongoing operation of the service? Now is an excellent time to discuss your plans with your web teams and security advisors (at least).
  • Have you listed all the policies, standards and legislation that your initiative will be required to comply with?
    • You'll need to ensure that your team and/or vendors are aware of these in future stages, and you'll need to give thought to how you'll have assurance that they have been addressed.
  • Have you evaluated the risks that will need to be addressed in a public Beta deployment?
    • Assemble staff from business, web, security and architecture teams. Map out the risks that proceeding to Beta might pose, and how to mitigate them. Risks could relate to service delivery, reputation, legal exposure, security and integrity, customer confidentiality or other factors.
  • Is it still worth proceeding?

Questions to consider before moving to Beta

Prototyping, research and user testing have led you to formulate plans to develop a Beta, and you're ready to start developing it.

  • Have you considered using other people's work?
    • Other agencies may have developed components or modules that you can re-use to speed up development.

When you move to Beta, you'll need to be sure that you can measure how effectively the problem statement or opportunity is being addressed. And you'll need to be sure that you get the right skills in the team.

Remember that the work you do in the Beta phase may evolve into a live service, so it's essential to get the basics right from the start. Retrofitting them later is almost always difficult and expensive.

Analytics and data collection

  • What initial analytics framework will you need to capture the behaviour of your test users?
    • You'll need to observe trends and traffic flows on your working prototypes. This will identify what works and what needs tweaking or rework, and to inform future development. Think beyond visits and pageviews, though. How will you measure and show that users are actually getting value from the service as it evolves? Are they able to easily complete the tasks you want them to complete? Can you capture completion ratios? How will you measure user satisfaction?

Privacy

If your service is to store or process any personal information, you should answer these questions before starting on a Beta.

Security

It's easier, cheaper and safer to factor in security from the outset.

Accessibility

Making services accessible doesn't limit your scope if you address it from the outset. And conversely, retrofitting is expensive.

Output from the Alpha phase

At the end of this phase you should you should have a simple working prototype and be able to describe – either on paper or in working models:

  1. User interaction flows and an initial information architecture developed throughout the Alpha phase.
  2. Screen layouts (for sites, services or apps), request/response structures (for APIs etc).
  3. Functional components (form elements, touch responses, request variables etc).
  4. High level technical architecture, including interactions or integration with existing business systems.
  5. A list of policies, standards and legislation that the service will be required to meet.

You should also be able to present:

  1. Results and conclusions from your user research undertaken in Discovery and during Alpha.
  2. How your Beta plans address these results and conclusions.
  3. Evidence of why it's still worth proceeding.
  4. A list of identified risks to the project and system, and required mitigations.
  5. A high-level plan for deployment of the Beta phase.
  6. A high-level plan of how relevant policies, standards and legislation will be met.
  7. A description of the skills and knowledge required of the team you will assemble for the Beta phase.
  8. An overview or high-level plan for how you might run the live service.
  9. A initial plan for how you'll shutdown any legacy systems not needed once the new service is live.

With all this in place, getting approval and funding to proceed to the Beta phase should be a lot easier.

Navigate this guidance