User expectations for government content

The Content Marketing Institute has just published helpful article on content development for government entities. If you are a inhouse content developer with a governmental organisation, or if you have a government client, you will find many useful tips inside the article.

This reminds me that I ought talk a bit about my current project: alpha.ecitizen.sg.

We launched the eCitizen Alpha website at the start of the year with skeletal content, mainly to test the information architecture and functionalities with users. Content development is going on, and my colleagues are working hard to launch the website later in 2012.

(In the meantime, please visit and give us your feedback!)

The research phase of the project has so far been very enlightening. Although I've worked on several other government web content projects in the past, this is the first opportunity I've had to test many assumptions I held about government content and end-user expectations. In many cases, I was surprised to be proven right, given how our findings ran contrary to many best practices in the content marketing.

Here are some user feedback based on our early prototypes.

(These interpretations of user feedback are my own, not that of my employer or my colleagues. Please take note!)

Finding #1: Content should be both clear AND visually compelling

Governments tend to have a bias towards content development in text. This is because the written word is the lifeblood of bureaucracy, and much of their information assets--policy papers, press releases, etc, already exist as text. Publishing as text rather than video or graphics simplifies the process of content repurposing.

For the eCitizen project, we found that users demanded both clarity and visual interest. Graphics were not just good to have--they were absolutely essential. Despite my best effort at clear and catchy titles, some pages were skipped over and missed by users, for one simple reason: they lacked graphics above the fold.

Finding #2: Content should be comprehensive

Our users gave feedback that they wanted their content to be comprehensive. Although there were complaints when there was too much content (e.g. too much focus on exceptional cases), users preferred to complete their research on the Internet, and not have to deal with call centres and emails.

One interesting side effect of this expectation is that they didn't like aggregated content, which is a common practice in content marketing. They wanted their answers to be found on our website, so that they needn't visit other websites, or to verify the authenticity of content on disparate sources.

Another artefact of this need for comprehensiveness was users didn't like titles that started with "Top 5 tips" or "10 best resources resources". "Why only 5 tips?" one test user asked. "I want to know everything the government can do to help me deal with my situation!"

Finding #3: Users hate silos

A common challenge that governments face is ownership of content. When policies and services span multiple organisations, content writers are reluctant to publish about processes that their organisations do not administer. The approval process becomes more complex. Keeping such information up-to-date is much more challenging.

The result? Content that describe processes halfway, using hyperlinks to hand off to another agency's website.

Our test users often did not make distinctions between government agencies, particularly for less-known policies and online services it wasn't clear which agency was in charge. They preferred to think of such content as coming from a single monolithic entity called "The Government". Content that directed them from website to website created a frustrating user experience.

Organisational silos are a common problem for any web project involving large organisations. Information architecture and content development are major tasks. If you are working on content that spans multiple government agencies, make sure you (or your client) has a clear idea about who owns the content, who approves the content, and a strategy for engaging stakeholders. If not, the content strategy should include activities for stakeholder engagement and change management.

The biggest takeaway from this ongoing project is a truism: no two content architecture projects are alike. We should always keep our assumptions in check, and find out as much we can about our client's business as well as user expectations.