If you want to make big improvements to content, you have to understand how that content works as part of a service. After all, we know that services are made of both content and transactions and most of government is mostly service design most of the time.
Some ways to think about services when designing content
You can’t separate content design from service design. So we tried to think about both when creating the import and export alpha.
1. Understand what the process looks like from the user’s point of view
We weren’t starting from scratch. The service designers on the ‘one government at the border’ programme created a helpful map of the import and export processes - based on how users think about it rather than breaking it down by departmental responsibility.
We used this map to guide us when writing up the user needs for the project.
For example, it’s important to recognise that exporting isn’t a single, linear process. It’s more like a collection of related processes which typically involve different people, and can be spread over a period of years.
And if you’re a managing director deciding whether exporting is right for your business, your information needs are very different from - say - a logistics manager who’s making sure the paperwork is correct for a consignment of goods.
2. Start with user needs rather than government processes (not an original idea, but worth re-stating)
People want to know about government processes in a specific context – the thing they're trying to do – rather than in the abstract. Usually a verb, rather than a noun.
So, rather than starting with abstract explanations of government processes, we organised the content around tasks the user is trying to complete.
3. Turn publications into transactions
It’s useful to think about forms as transactions rather than publications. No one wants to read a form: it’s a way of providing information to the government so you can do something specific (eg apply, register, or pay for something).
With importing and exporting, a lot of the complexity comes from working out whether you need to complete a form - and if you do, which one.
So we brought together forms that relate to the same or similar tasks. That way we can explain which form to use in which circumstances. And we’re creating one thing per user need, rather than one thing per variant of a government process.
And transactional things belong inside transactions. I might need very detailed guidance to help me give the right information when I’m completing a transaction - but I probably don’t need the same level of detail outside the context of that transaction.
4. Turn schemes into services
Having too much detail about government schemes for traders can be counterproductive: it delays the point at which the user knows what action to take (and may stop them taking any action at all).
So we brought together information on government schemes that are designed to solve the same problem in different ways, and thought about what decision the user needed to make at this stage in their journey.
With schemes for exporters, the first step is often to talk to an adviser about what scheme is right for you. This meant we could strip away much of the complexity, providing a clear call to action with just enough information to let the user make an informed decision about whether to pick up the phone.
Think about content as part of a service
The vision for GOV.UK is to provide coherent services by bringing content, transactions, and support together. We can only achieve that by working with service designers to design content within a whole service.
Join the conversation on Twitter, and don't forget to sign up for email alerts.
