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 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 disabled people? 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 need to comply with?
  • You need to ensure that your team and/or vendors are aware of these in future stages, and you need to think about 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 need to be sure that you can measure how effectively the problem statement or opportunity is being addressed. And you 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.

• Do you understand your obligations under the Privacy Act?
  • You should review all the information you might collect from users, and review the Information Privacy Principles.
• Will you need to undertake a Privacy Impact Assessment?
  Privacy Impact Assessment Toolkit
  
  • If you collect information that identifies a person you may need a formal Privacy Impact Assessment. It depends on the type of information you collect and how and why you collect it.

Security

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

• Do you know who is responsible for security and privacy management within your organisation?
  • Your Chief Executive is accountable for your organisation’s security. Do you understand who to consult to seek assurance about the security of your service?
• Have you considered the risk profile of your service?
  • Even in beta, you must know how to adequately secure the service. You should review the nature of the information that your service deals with, the nature of the threat landscape on the internet, and the impact of the risks that your service is exposed to.
• Have you developed a clear statement of security requirements that the service must meet?
  • Your team must be aware of your security requirements and should be able to describe how they will be embedded in the development process. Are statements of security requirements written into project plans or contracts? How will you know that they are being met?

Accessibility

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

• Are you familiar with the basic principles of web accessibility and the Government Web Accessibility Standard? How will you be sure that you meet them?
  Web Content Accessibility Guidelines at a glance
  Web Accessibility Standard
  • Even if your agency isn't required by mandate to meet the Standard, doing so is good practice and may save you from difficulty in the future. Your organisation has an obligation not to discriminate on the grounds of disability, and you should take steps to ensure that your service will meet the levels of accessibility expected of the government domain.
• How will you know that the development team have adequate knowledge and experience of the Government Web Accessibility Standard and the Web Content Accessibility Guidelines?
  Web Content Accessibility Guidelines at a glance
  Web Accessibility Standard
  • Can the development and content teams demonstrate to you how individual aspects of the Accessibility Standard benefit people with certain needs? How will the developers prove – not just assert – to you how their product meets the Web Standards? How do you plan to test it?
  • Are accessibility requirements identified in statements of work and contracts?
  • Consider bringing in accessibility testers early in development, to minimise the cost and effort of rework later.
• Do your content authors and editors understand accessible content?
  • Can the team explain to you how poorly structured content adversely affects the ability of some people to understand it? Can they describe which aspects of the Web Accessibility and Usability Standards are relevant to their work?
  • Do they have a commitment to using plain English and good semantic structure?

Output from the alpha phase

At the end of this phase 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 example, for APIs)
3. functional components (for example, form elements, touch responses, request variables)
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 need 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. an initial plan for how you'll shut down 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.