Opinion: Can We Get The Public On Side With Digital Or Not?

Mar 09, 2016

In the drive to make services digital, there’s always the danger of losing sight of why we’re doing it. Much is made of “Digital Inclusion”, for instance, and the government is committed to ensuring that the 12.6 million adults identified by Go ON UK as without basic digital skills have access to the Internet through improved education, access and infrastructure.

But persuading those users to adopt digital is a feat in itself. And people rarely use a government service because they want to. And if they have to, how will users who are blind, deaf or for whom English is not their first language be accommodated? Additionally, for many, a social media application or online game accessed through a smartphone is the extent of their digital activity, making attempting to complete an official form online a cumbersome process. Others will be relying on the service to assist them in securing financial help or personal advice. All of these drivers can and should impact digital design.

While we have little influence over users’ physical access to the Internet, we can ensure that the number of people who could be disadvantaged by digital transformation is reduced. An approach is needed that seeks to combine user-centric technology with design and that recognises user preference for engagement and that places the user as the starting point in the design and development process, not the technology. And that’s precisely what is being advocated by the Draft Local Government Digital Service Standard proposed by LocalGovDigital (see more here).

For a digital service to succeed, it has to be easier for someone to do what they need online rather than via another channel. The process has to be quick and simple, removing the “hassle-factor” for the user. This creates a challenge for the developer who needs to create a service that is easy to use, convenient and appealing to overcome user reluctance.

Poor design

Poor digital design creates an electronic version of a paper process rather than a digital experience. To avoid this, existing processes have to be reviewed and redefined, which means accepting new and unfamiliar ways of completing tasks. Users’ behaviour, abilities, comfort level and device use – all determine the approach.

Using a collaborative (Agile) method, solutions can be responsive to change and focused on the user experience, stripping out unnecessary elements in order to encourage adoption. At the same time, be conscious of the IT environment in which the service is operating in order to minimise risk, contain budget and take into account any dependencies of working with other suppliers or internal teams and any integration challenges presented by existing technologies.

At the very start of the process, look at what the service is aiming to achieve. And then, challenge it!

How? Well, start by asking how you know each element is necessary... If it's removed, will we lose anything of real value? You can only answer these questions by testing your assumptions with real users, and that includes those with assisted digital requirements such as people who are visually impaired, deaf and those who suffer from conditions such as ADHD, all of which require different considerations.

Some to-dos here might be to remember that for each user, this is a new and possibly one-off exercise. Acknowledge that users will find a way around using a digital service if it is inconvenient, uncomfortable or confusing. Make provision for this to ensure the user doesn't take the wrong route to bypass the digital service which can result in them being passed from pillar to post, referred to another team or put on hold, ultimately ending up dissatisfied and frustrated. And don't forget to make it clear under what circumstances the provisions apply, so people don’t automatically opt for the bypassing route.

Data as a driver

Consider which teams are affected by the service and involve them throughout development. Historically, teams work in silos and approach a project from separate perspectives, leading to a disjointed result which is unlikely to meet the needs of users. Address privacy and trust upfront: what happens to the data provided by the user? How is it handled? Does it need to be stored? If so, how and where? And adopt a long-term view: can any elements of the service being developed be used elsewhere in the future?

From a technology point of view, seek out solutions which make it easier to scale and adapt as technology advances - be aware that new versions of operating systems, for example, need to be quickly catered for.

From a development perspective, meanwhile, the solution needs to be capable of being used seamlessly on different platforms and adaptable to different screen sizes. This is easier said than done using traditional, bespoke, hard-coding methods, which demand complex project scoping, the time (and cost) associated with highly-skilled developers and drawn-out testing processes. A COTS low code-based solution, in contrast, uses commercially available browser options automatically optimised for different operating systems and screen sizes.

So my conclusion is Digital by Default services should replace paper, telephone and face-to-face access with more efficient and accessible digital alternatives. We can’t mandate behavioural and cultural change, but by providing well thought out, simple to use digital services, we can encourage users – both public sector staff as well as citizens – to adopt new ways of getting things done.

The author is Strategy Director at Toplevel