Information about how our website is designed and structured to meet users needs.
How the website is structured
To say that no-one wants to visit a council website is an over-simplification. But it’s certainly true that the compulsion is significantly different from what drives people to a destination website like BBC News or Facebook, or from something customer-facing like Amazon. Therefore treating the RBKC website as a destination in its own right, or assuming some kind of traditional customer relationship is a trap you should avoid.
Anecdotal evidence, confirmed by analysis of website traffic, shows the reality is that:
- People visit the RBKC website almost solely to accomplish a task, and usually just one task at that, be it submitting a form, paying for something or finding out information
- Many people want to do one of a relatively small number of tasks
- Google is the starting point for the significant proportion (80%) of journeys
This insight means three things, all of which are reflected in the Design Principles:
- The vast majority of people arrive not at the home page, but somewhere deep-linked within the website
- Pages should be focussed on helping people accomplish tasks and find specific information
- We can scan logs to identify and pre-empt the tasks people are likely to be wanting to do
The website was designed around the core premise that people come to the site to do one thing, then they leave.
The resulting structure of the website is very flat. It relies on a concept of related content rather than a fixed, deep and sprawling hierarchy. This means the website has following simple structure:
Home page rbkc.gov.uk
Service Hub eg. Planning & Building Control
Service Sub-Hub eg. Planning Applications
Content eg. "How to Appeal Planning Decision"
Topic Tags eg. Planning Advice
The really important thing to remember is that all service and content pages are siblings. The parent to every piece of content is either service hub or a sub-hub - the heirarchy never goes deeper than than.
Rather than forcing content into a single position within a deep heirarchy, each piece of content belongs to a Service Sub-Hub (or Service Hub) and is tagged with one or more Topics. Crucially, Topic Tags are not associated directly with Service Hubs, they are used to pull together related information and services regardless of which Service Hub that content belongs to.
Service Hubs, Service Sub-Hubs and Topic Tags are all solely navigational pages containing clear signposts to the tasks people want to do. These pages provide useful entry points for users coming directly from Google or other search engines (especially our own).
Overall, we have a spoke and hub architecture rather than a top-down hierarchical structure. You can look at the web site as a bicycle wheel, with service hubs, content rims and topic tyres.