Launching your service in beta

You must launch your service in private beta before you launch it in public beta.

Restricted private beta

A restricted private beta is a beta that isn’t open to everyone. You must restrict access. Typically, invites are sent to people in the user research pool and staff who are part of the project team.

A restricted private beta allows you to:

  • Have more control over the type of user that gets to use the beta.
  • Start small and get quick feedback from users before rolling your service out to a wider audience.

What to do in restricted private beta

  1. Move your service to a test server. Avoid development or production servers and servers solely controlled by external vendors. If your service includes different components, for example a back-end system or API move those components to test environments. Do not mix test and production data and connections.
  2. Protect the service to ensure limited access. Do this with a network filter or a username and password. With a username and password, you should have a version for the project team and another that you can share with more people. Doing this will allow you to more easily manage access to the service. Contact eservices@gov.yk.ca for assistance.
  3. Ask the service owner for an email address from which service messages to users can be sent and received. Once set up, test to ensure the email address can send and receive messages.
  4. Ensure that the feedback form or email link on your service is working. Have different members of your project team submit feedback and confirm that you can reliably receive their submissions.
  5. Email your project team and others involved in testing that the service is ready for their review. Your message should include:
    • An URL to the service.
    • The username and password they can use to access the service.
    • A reminder that this is a restricted private beta. Ask them to not share the URL with anyone else without your permission.
    • How long access will be open. Depending on the service, access should last between 1 to 3 weeks. A limited period encourages people to get involved rather than wait.
    • Instructions for how they can submit feedback. Mention that their feedback will be reviewed, organized and prioritized.
  6. During the restricted private beta, monitor user feedback. As you receive it, add each submission to the backlog and label it as a bug, improvement or new feature. Prioritize items by their value and complexity.
  7. After the feedback period is over, make critical improvements to the private beta. Inform users that if their feedback was received but not acted upon, what will happen to their input. Figure out how to tell users that here’s the new version and here’s what we changed based upon your feedback.

Unrestricted private beta

After you have run your service as a restricted private beta, open it up to more people.

An unrestricted private beta is typically used to share the service with all government staff. In some cases, you limit access to only 2-3 departments.

What to do in unrestricted private beta

  1. Move your service to a production server. Related components should also move to production. The goal is to replicate the final user experience as much as possible.
  2. Add the analytics tracking code to your service so you can measure and report on its performance. Email eservices@gov.yk.ca to request the tracking code and after it’s sent to you, add it to all pages in your service. Contact eServices to tell them the code is there and they will confirm data is being collected.
  3. The service owner will coordinate test transactions through the service and ensure submissions safely make it through. Records should appear in the back-end system and get displayed in any merchant account reports. Verify that Department of Finance's reports show the payment transaction in their General Ledger account.
  4. Verify with the service owner that they can view related audit logs and will have a plan in place to review these once a month.
  5. Remove the network filter or username and password protection you put in place during the restricted private beta. The goal is to make getting to and using your service simple and easy. Email eservices@gov.yk.ca to request the change.
  6. After the access restrictions are removed, ask your project team to check if it’s working. Test by opening a web browser tab in private or incognito mode. You shouldn’t have to enter a username and password to access the service.
  7. Decide how many people you want to invite to test the service. Sometimes a service is of such importance to government that as many internal people as possible need to test it before going live. In these cases, use a global note to email all staff at once. Global notes are organized by the Public Service Commission. Before contacting them, ask your Director for permission.
  8. During the unrestricted private beta, monitor user feedback. As you receive it, add each submission to the backlog and label it as a bug, improvement or new feature. Prioritize items by their value and complexity.
  9. After the feedback period is over, make critical improvements to the private beta. Inform users that if their feedback was received but not acted upon, what will happen to their input. Figure out how to tell users that here’s the new version and here’s what we changed based upon your feedback.

Write a global note

Much like the email sent to your project team for the restricted private beta, your message should include:

  • An URL to the service.
  • A reminder that this is a private, staff-only beta. Ask them to not share the URL with anyone else without your permission.
  • How long access will be open. Depending on the service, access should last between 1-2 weeks. A limited period encourages people to get involved rather than wait.
  • Instructions for how they can submit feedback. Mention that their feedback will be reviewed, organized and prioritized.

Send a draft copy of your message to the Public Service Commission and your department’s Communications person so they can review its contents.

Don’t write a global note

If you choose to only invite staff from 2 or 3 departments, the details of your message will use this format:

  • An URL to the service.
  • A reminder that this is a private, departments-only beta. Ask them to not share the URL with anyone else without your permission.
  • How long access will be open. Depending on the service, access should last between 1-2 weeks. A limited period encourages people to get involved rather than wait.
  • Instructions for how they can submit feedback. Mention that their feedback will be reviewed, organized and prioritized.

Send a draft copy of your message to department Communications people so they can review its contents. Do not send the final message until it has been approved by Communications.

 

Next: What to do in public beta →

Last update:
Jun 3, 2019