I’ve heard a few presentations, podcasts and the like recently that have referenced Assisted Digital and Service Design. This hasn’t felt right. And I think the reason for this is that I don’t believe that the two concepts can co-exist.
Service Design assumes that you consider the entire service from the outset, regardless of delivery channel (hence the renaming of the Digital Service Standard to the Government Service Standard). Assisted Digital assumes that you deliver a digital channel first, and then think of ways to get people who have problems using that channel to their goal.
This means that Service Design is predicated on the fact that Assisted Digital is a bad approach. At best, it feels illogical talking about both as approaches that stand alongside each other as equally valid. At worst, it feels contradictory.
I think the reason for the mix-up lies in how we’ve got here. To explain, I’m going to give a summary of the approach to service design in UK government over the past ten years. Don’t worry, I’m going to use pictures. 
Phase 1: many channels
Pre-2014, digital services were often designed to work alongside existing offline, and often paper-based, processes. Approaches were often determined up-front, with minimal flexibility for change or response to feedback or problems. These channels were designed as “extras” to complement, rather than take over from, existing channels.
Any issues that users experienced accessing the service were often ignored or referred back to existing paper or telephone options. If and when digital services didn’t work for users, the default was to go back to how everything had previously worked. 
[I’ve specified “paper form” and “contact centre” alongside “website” in the diagram, because they’re the most generic channels, but there were others – physical channels like the Post Office or local government offices for HMRC or the DVLA, for example.]
Phase 2: one channel, with tributaries
These introduced two concepts. The first was “digital by default” – that services should be digital unless there existed a strong reason for them not to be. The second was “assisted digital”, a route of providing assistance to people who couldn’t otherwise use digital services. This approach was summed up in the graphic above .
Phase 3: one channel
The need to consider assisted digital is still part of the service standard. Others have started to move away from this language. The author of the 2012 strategy has publicly concluded that the use of the phrase “assisted digital” was a mistake. Others have criticised the way that this approach leads to a narrow definition of a “one size fits all” online service, accompanied by a minority route to accommodate any other users. This is not the reality for some services. 
This has taken place alongside the emergence of service design, and the increasing stress on this approach in government (seen, for example, by the Scottish Government’s recent publication on their approach to Service Design). Service design concentrates on the design of a holistic service, and the users of the service, independent of channel or delivery method.
In their book “Good Services,” Lou Downe defines a list of 15 principles of good service design. Principle 11 is “a good service is usable by everyone, equally.” A service design approach prioritises on- and off-line journeys equally from the beginning and acknowledges that “there is no such thing as an ‘assisted digital user’ – just users who need support and services (online and offline) that must meet those needs”.
In his post on why he was wrong to use “Assisted Digital,” Tom Loosemore says:
The service design should be flexible enough to grant them [i.e. the users] the assistance they need, and adapt itself when necessary… If we’re going to take our commitment to service design seriously, the design of the whole service should reflect that reality and meet all the relevant user needs. We shouldn’t try to force a small subset of users – often more vulnerable individuals who could do without the hassle, frankly – to go out of their way to simplify our lives as service providers… No-one should have to tick a box that says ‘I need help with this entire service.’ Rather, the service should provide help when necessary.”
If we take on this point on board, then the diagram in phase 2 risks us designing a digital service, and then treating – or triaging – all other users into a zone where we commit to doing things that allow them to use the digital service that we’ve already designed. In a world where we too easily assume skills and access levels to be the same as our own, this is dangerous. Service Design forces us to unify the way in which a user outside the organisation interacts with the organisation, and looks like the diagram above.
What difference does this make?
If we are to learn from the last decade of providing government services online, then we should be considering users and their needs from the outset. This means moving away from an approach that selects a single delivery mechanism, or evaluates by a channel-shift/reduction cost metric in isolation, and towards an inclusive approach that considers what channels are most able to meet user need at the point of delivery. Not only should we avoid deciding up-front what piece of software we should be using to deliver a service; we should also avoid making assumptions about whether the service will be online.
This means that talking about “assisted digital” needs at any point should be a red flag, because it’s a false divide. There is not a generic average user who uses our service most of the time, and a small group of users who have some specific issues that we need to give them extra assistance with. Users are never that easily classifiable.
Rather, there is a broad range of users with needs that may relate to digital skills, access to connectivity or devices, disabilities, language use, and a whole range of other factors that impact their ability to use services. Some of these needs may be temporary, some may be permanent. Addressing some user needs may result in an improvement of the service for other users .
I don’t think that talking about “Assisted Digital” is massively helpful. I do think that checking that we’ve considered all the potential users of our products and services, and not just the users with loud voices or even the users that we currently have, is helpful. This assurance will take place daily in teams, at different levels in organisations and also at service standard assessments.
I was given plenty of chance to comment on the most recent service standard revision, and I didn’t pick up the contradiction I’ve outlined in this post. So I hope I’m not pointing the finger at anyone aside from myself in saying this. If keeping “assisted digital” in point 5 of the standard makes sure that assessments still ask teams questions about how they are sure that their services meet the needs of all their users, then I’m fine with that.
In the long-term, I think we need to come up with some new language. Questions like “what support are we providing different users?” or “what have you done to ensure that no users are excluded from using this service?” are more helpful. (The reference in point 5 of the current standard makes perfect sense if you lose the final clauses, and keep “make sure that people aren’t excluded from being able to use the service”.)
Outside of assurance, I think it’s simple. People used to get confused about the definitions between digital inclusion (people having access to the internet), assisted digital (helping users access specific digital services) and accessibility (ensuring that services are usable by all). And perhaps that confusion was fair, and not something that could be solved by constantly finding better ways to define Assisted Digital. How about we say instead that all users are assisted digital users and we should design for them from the start?
 I prepared these diagrams when I was thinking (and writing) about creating inclusive services in lockdown a few months ago. They weren’t intended for publication, so apologies about the horrible gradients.
 We’d gone through exactly the same journey with flat websites a few years previously. These started out as a nice to have, and then became essential at some point later. If you were unlucky, you ended up working at an organisation that had set up hosting and disaster recovery on the “nice to have” basis and then had a major problem that caused it to realise that their website was now essential. Fun times.
(For example, most people in the UK got news about 9/11 from teletext or rolling TV news because websites and internet connections in 2001 weren’t robust enough to take the strain of everyone trying to use them at the same time. If I recall correctly, www.bbc.co.uk fell over fairly quickly. The first time I knew anything had happened was when I tried to test some code online, got a series of timeouts, and wandered out of my office to see if someone had pulled the lead out of the back of the patch cabinet when changing the security camera tapes again.)
 This is no longer part of the Service Standard. The link here is to the internet archive because this image has now been removed from all of the pages that originally featured it. As someone who had to run training sessions for departments on Assisted Digital in 2014 and 2015, you’ll have to take my word for it that not only was this fair statement of the approach taken at the time but it was useful in explaining it to departments.
 This is not a great example, but is a personal one. I am not classed as visually impaired, but I do require strong glasses, and I run my Internet Browser zoom settings at more than 100% for sites that have small text sizes. I therefore massively benefit from site design that is tested on visually impaired users.