Skip to main content

Making an IT service: design phases

Posted by: , Posted on: - Categories: Delivery


Much like any project at GDS or on the digital transformation programme the Cabinet Office Technology programme, which will deliver modern, flexible technology services that are at least as good as those people use at home, is following the service design pattern of: discovery, alpha, beta and live.

Although the programme is not delivering a digital service, the design phases remain the same. Focussing on user needs means that we want to get services in the hands of users as quickly as possible so that we can test how they work in real situations.


We are currently at the alpha stage, and are just about to start running some user trials. From next week we will be giving a small range of different devices, applications and connectivity to a few small groups of people to use in their day to day work for at least two months. For the trials we are focusing on light, cloud applications for email and document collaboration, we’ll give more details on the trials in a future blog post. Throughout the trials  we will be providing support and training to assist participants.

Understanding our users’ experience during the trials is crucial, we have already spent time with those users to understand how they work right now and throughout the next couple of months we will provide plenty of opportunities for them to provide feedback to our user research team to help inform future decisions that we make. We expect users will find what we give them intuitive and easy to use, but providing chances for feedback will help test these assumptions.


Our beta stage will start when we start rolling out new services to users. We aim to create a minimum viable set of services, which we will roll out to users whose needs it largely meets, we will then add services on top of it as well as scaling to meet the needs of more users and rolling out iteratively.

All the way through the beta we will be capturing user feedback and improving services based on it. For example, we may give a team of 30 a set of applications and discover that they aren’t working for them. Because of short contracts, iterative roll-out and loosely coupled services we can change out those parts and learn for the next team.


Live is an operational service and starts the day we will have taken all the existing laptops away. The live service should meet the needs of current and new users at the Cabinet Office as well as meet security and performance standards. Live is never the end, once the service is operational it will move into a new stage of service management and continual improvement to meet new needs and demands.


Sharing and comments

Share this page