What to do at every stage of your digital project

If you're working on a large digital project, there are a set of tasks you should complete to make sure your service:

Large services or projects are typically those who serve a large number of the Scottish public. Your service will likely have a budget of at least £250k. Smaller services, with less budget, should follow a simpler set of tasks.

Getting set up

You must:

Discovery phase

You should:

Planning for your alpha phase

You should focus planning for your alpha on what you’ll need to do to deliver a Minimum Viable Service (MVS). Your MVS should be a balance of what:

  • your users need
  • the technology is able to do, given potential constraints around time and affordability
  • objectives need to be achieved by your organisation

Typically, some level of compromise between these areas will be needed.

Alpha phase

In alpha, you should build your MVS. This includes:

  • building the key parts of your service and testing they work with users
  • refining and iterating prototypes of your service - your MVS should already have been tested and iterated with users in your discovery, so alpha prototypes should focus on continuous improvement or testing non-MVS parts of your service
  • have been through the procurement process and started drafting your user acceptance testing strategy

Common issues to avoid at this stage are:

  • waiting until alpha to set up key discovery elements, such as prototyping or testing your prototype
  • if you've identified a procurement need, not opening up your procurement process early enough to get the most cost-effective solution

Beta phase

By the start of beta, a lot of the major parts of your service should be ready to be rolled out to users.

You should start this roll out in a ‘private beta’. A private beta means launching your service to a limited number of users, analysing data and using user feedback to validate what works and iterate what does not.

From your private beta, you should move into a ‘public beta’ when you're confident your service is ready. Having a service in public beta means that anybody can access your service.

If you're replacing an existing service

Keep the previous service running until your new service moves into its live phase. This will give you time to make sure your service is working correctly before making your service the only option for your users.

Planning for live during beta

Your plan for live should include an estimate of the staff and budget needed not just for basic maintenance but continuous improvement of your service. Your plan should also include a prioritised backlog of improvements to work from.

Live

In live, you should continuously refine and improve your service.

To do this, you'll need access to the right staff, such as user researchers, content designers, developers etc.

You should know by the end of beta what initial improvements are needed over the first 6-12 months of live.

Ongoing improvements can include things like:

  • adapting to changes in user behaviour
  • responding to technical problems
  • making your service simpler to use

Ongoing improvement is necessary to stop your service accumulating technical and design debt. If this debt becomes too high, your service will become outdated and a major project will soon be needed to update or replace your service.

To help keep your service up-to-date, you should continuously get user feedback through activities such as asking for feedback on your service's web pages and through usability testing.

You should also regular monitor your service's key metrics for any signs of user issues.

Back to top