It’s easy to spot when a service isn’t working, it’s not always easy to spot why it isn’t working. That said, we’re gradually finding common issues which lead to problems in services across government. Many of them hinge on two important criteria for service design success: how easy they are to find and how easy they are to use.
As I’ve written before, some of the work of a service designer is a bit like being an archaeologist. Almost everything is ‘legacy’ - including the policy and process by which we meet a user need. The designed-on-a-blank-slate service is the anomaly: mostly services are put together using different components of different ages, conceived with different logics. And to a large extent that’s ok - after all, we want services that are composed of small pieces loosely joined.
However, it’s when those pieces bear the legacy of the technology they were designed in that we encounter problems. Here are some commonly-arising problems, usually linked to the way those pieces have (or usually - haven’t) been designed:
Isolated transactions
In the pre-computer era, a commonly used efficiency tactic was to separate interactions with government into small tasks for easier pre-sorting and faster human processing. The upshot of this is that these interactions that need to be completed together to reach a user’s goal, are now isolated and unconnected from one another, separated by departmental or organisational boundaries.
Large aggregated transactions
Once the computer was beginning to be commonly used, approaches to optimising efficiency changed. An early computerised efficiency tactic was to group interactions with government into one, large transaction for simpler machine processing. eg. issuing environmental permitting.
Where those transactions have been translated into a digital service, they remain as one large (and ever increasing) physical location or ‘portal. Bundling them together means the transactions contained within it aren’t findable by a user, nor are they reconfigurable into a sequence of transactions and activities a user needs in order to complete their goal.
Paper logic
Sometimes digital services directly replicate transactions in the way that a paper form works. The logic may work for the people building a service, but not for building one which makes sense for users.
Duplicated transactions
Transactions that do the same thing, in slightly different ways. Like delegating responsibility, or changing your name.
Noun-based naming conventions
Usually caused by the service being called by the policy it was created for eg. SORN (rather than take your vehicle off the road) or immigration health surcharge (rather than pay towards the NHS when you come to the UK) rendering a service unfindable by anyone who hasn’t already used it.
Follow #ServiceDesign this week
We’re talking about #ServiceDesign on social media for the week, sharing lots of new videos, case studies, images and blog posts.
