It is no secret that until now I have spent a great deal of my web development career working for public sector organisations such as the NHS and local government.
During this time I have learned a lot, and I figured I would share my knowledge with those of you that may be in the process of making sense of a big website, and who may be trying to make it more customer focused.
In this post I have referred to tools and practices that I have used within both the NHS and local government. Do not let this put you off if you do not work in the public sector, as these tools can be useful as a reference for the management of any big website.
Large organisations that deliver multiple products and services to varying audiences have historically always had large and complex web presence. For example a hospital may deliver services from podiatry to neurology and everything in-between.
The historic presence of the website will have been driven by governing factors (in the case of local authority websites, a statutory need to deliver information online) and will have grown organically over time.
As a result of this it is likely that the website will be more reflective of the organisation’s internal directorial structure, rather than the needs of its customers.
The customer need
Customers will visit a complex websites for a variety of reasons, and each customers need may be different.
For example they may be seeking advice, or they may need to book an appointment, or they are coming into the premises and need to find the location of the department.
The reasons for a customer visiting a website could be endless, however one thing remains common regardless of the customer need, which is that all customers will visit the website to perform a task.
These tasks can be as simple as seeking information, or as complex as making an online transaction (for example filling in a booking form).
The key point is that every product or service that a large organisation provides exists to aid a customer with the completion of a task.
Tasks are aimed at fulfilling a customer need, but you may find it hard to identify the tasks that an organisation delivers until you have identified its customers.
A large organisation, such as a local authority, will have many customers, both internal and external to the organisation.
If you were to list all of an organisation’s customers in one go, it could prove quite problematic, as you may find that the individual products and services have several types of customers each.
A method that I found useful was to group customers into categories, and then explore these further on a task by task basis.
Just some of the categories of customer that may have an interest in an organisation’s products and services are as follows (customers may sit within multiple categories):
- Self-service customers
- Mediators (e.g. carers)
- Age range (e.g. young people, adults, older people)
- Health and/or social care issues (may need assistance, may be vulnerable)
- Peers (e.g. other local authorities)
- Governing bodies (e.g. Ofsted)
In order to identify tasks, we must first define what we consider to be a task. For the purpose of the exercises in this article, we will define a task as follows:
‘A task enables a customer to perform an interaction against a product or service.’
Getting a handle on products and services
As odd as this may sound, a large organisation may not actually have a handle on all of its products and services. This can be especially true in the world of the public sector, where departments may be operating in silos.
As somebody who is trying to redevelop the website to meet the customers need, you may need to conduct several workshops with key stakeholders to discover the extent of what an organisation delivers.
Local authorities are given help identifying the services they deliver in the guise of the LGSL (Local Government Service List) (http://standards.esd.org.uk/?uri=list%2Fservices).
Granted it may take some interpretation, and I suggest you edit the list to your organisational needs, however for every service that the LGSL recommends should be provided as a council, it also recommends the interactions that should be performed against each service.
The task definition uses the word ‘interactions’, and as an organisation you may have many.
Local authority’s are fortunate in that they are given a starting point with regards to tasks with the LGIL (Local Government Interaction List), provided by the ESD (Electronic Service Delivery) toolkit (http://www.esd.org.uk/standards/lgil/1.01/).
It is worth noting that not every organisation is the same, and the interaction list will be unique to the organisation.
In the case of the LGIL a local authority will certainly find that it does not deliver all the interactions on that list, and they may very well have additional interactions which are not mentioned.
You should define your own interaction list, but the LGIL may be a good starting point.
Writing a task
Tasks should be written in such a way that they fully define their purpose. To do this I recommend taking into consideration three elements:
- The customer (or stakeholder)
- The interaction
- The product or service
Lets say that we are writing about a service that a local authority would deliver, such as foster care.
An example of a written task using the elements above would be:
‘As a potential foster carer, I wish to find out about foster care’
Considering the example I gave about the LGIL interaction list, the part of the above sentence; ‘find out about’, implies an ‘Information Provision’ interaction (of course the interactions you have defined may differ from this list, but the principle remains the same).
Another example, this time using the adoption service could be:
‘As a potential adopter, I wish to apply to adopt a child’
Here the ‘apply’ part of the sentence implies an ‘Applications for service’ interaction.
You may recognise that the way the tasks have been written, as they take the format of a ‘user story’ (you may recognise this from agile project management).
The fact that we write our stories like this is no coincidence as this is the management method that I recommend for the development of each task.
As you write tasks you may realise that many customers may wish to perform the same task, and your tasks list could grow out of control. For example, consider the following tasks:
- As a potential foster carer, I wish to find out about foster care
- As a current foster carer, I wish to find out about foster care
- As a child in foster care, I wish to find out about foster care
You may decide that you are going to deliver the same information to the potential foster carer, and the current foster carer, but deliver a different set of information for someone who is in foster care (as they will likely have different questions).
To do this, tasks can be written so that they assume the needs of the majority of customers first (generic), and where we could not fulfil the needs of a certain group of customers, we wrote additional tasks to meet these exceptions.
This means you can simplify our list so that the fist two become one task written as:
‘I wish to find out about foster care’
With that being a generic task aimed at all customers (the potential and current foster carers).
For cases where you may wish to change the process or style of delivery for an interaction (such as the information aimed at people in foster care) you would create a separate task:
‘As a child in foster care, I wish to find out about foster care’
By doing this, we are managing special cases by exception, still considering all customer types, and meeting the needs of those that may need an additional or alternative interaction. This method helps to keep the task list concise.
Because we now have two tasks based around the delivery of one service (with the same interaction), these exceptions can be referred to as subtasks.
Building a task list
The best way to deliver a customer focused website is to assess exactly what it is an organisation offers, the people it offers it to, and the tasks involved in the delivery of those offerings to those people.
A list of tasks will help with this, however just listing them in alphabetical order would be pretty useless.
The simplest thing to do would create a spreadsheet that can be used for cross reference. Here are the methods I used when identifying tasks on a spreadsheet:
Give each task a unique ID
We need a way of assigning a task ID to each task, in such a way that at a glance we instantly know what service (or product) it applies to, what interaction it covers and a way to uniquely identify it. A suggestion is the following method:
[Product / Service ID]-[Interaction ID]-[Subtask ID]
This breaks down as follows:
Product / Service ID
The ID of the product or service you are referring to (if you don’t have product or service ID’s now would be a good time to start assigning them).
For each interaction you have defined, create an identifier for it (the LGIL gives you some numbers by default as a starting place), this will let you view the interaction type at a glance.
As we mentioned, exceptions to the general task are called subtasks. This lets us know that this is a subtask, and which subtask it is.
Task ID example
An example of this in practice (in a local authority setting) would be for the task
‘As an adopted child, find out about your birth parents’
This may have an ID of 160-8-2 which can be broken down as follows:
160, because this task has a service ID of ‘Adoption’ in the LGSL.
8, because this task has an interaction ID of ‘Providing information’ in the LGIL.
2, because this a subtask of this particular service and interaction type (it just so happens that this is the second subtask that was identified in this area.
Obviously you would use the relevant ID’s for your organisation.
Defining other spreadsheet fields
Now you have got your tasks defined (in the form of a user stories), and you have given each one a unique identifier, you can now start to populate the rest of the spreadsheet. Before you can do this you need to start thinking about Information Architecture (IA).
For a first pass at the IA an approach you could take would be first fit card sorting exercise. To do this you would need to sort through the entire list of tasks and group them into logical groups of related content (don’t worry this will not represent your final IA structure).
You should then ask a group of other people to do the same thing (you will have differing results). This group of people should be representative of your customer base, try and do this as a workshop led where possible, and make sure the group is manageable (no more then say 10 people).
During the card sorting process you will find that certain tasks could fit into more than one group.
Because polyhierarchical navigation can often be confusing to a customer journey, it is recommended that rather than including tasks in multiple groups it would be better to have a mono-hierarchical Information Architecture and identify a primary group for each task.
You should also let your customers have a different ‘view’ of the tasks depending on their need, so to allow customers to view all tasks that relate to a given task, or all tasks that are associated with a customer type, you should identify secondary groups that each task belongs to (where appropriate).
Building a related task list
We now have all of our tasks written as user stories, a unique ID, a list of customer groups and a list of related groups of information.
Now we need to plot the primary and secondary locations on this task list. You may do this the following way:
|Task||ID||Group 1||Group 2||Group 3||Customer 1||Customer 2||Customer 3|
You will note that the customer groupings are always secondary. This is because your customers will not always know what type of customer they are, but they will know what they are looking for, so the group (or topic) would be the primary area that they will look to complete their task.
Here is an example of what a typical local authority task list may look like:
Congratulations, once you have completed this stage, you will now have a development roadmap.
This ‘first fit’ IA architecture forms the basis of a development roadmap. The roadmap identifies all of the ‘content groups’ that need developing, along with any initial form developments.
Forms and applications
Form and application developments have been identified by the tasks that were created that have an interaction which is something other than information provision (eg applications, reporting functionality etc…).
This roadmap has several purposes:
- To identify groups of work, so that work can be scheduled appropriately
- To monitor the progress of work that has commenced (including any additional tasks that have been created as part of the development process)
- To identify form/application developments, and keep track of their progress
- To act as a single point of reference for all the tasks (and their mappings) within the website
Now we can divide up our content groups and take them to our stakeholder groups. You will find that multiple stakeholders have an interest in each content group, so it is best to run these sessions as a workshop.
For example for the fostering section that we have been using as an example, there may be several stakeholders that you wish to invite to a workshop. Such as:
- An subject matter expert from the children’s services team
- A foster carer
- A customer interested in becoming a foster carer
- Someone who is in foster care
- Someone who has left foster care
- Someone from social services (who may have some cross over services, identified in the roadmap)
The goal of the workshop should be to refine the tasks that have been identified, and put some structure into the tasks. Goals you should have are to:
- Give the tasks a meaningful title
- Identify any stakeholders that may have been missed (and to create tasks for these stakeholders)
- Identify tasks that are not delivered
- Identify tasks that have been missed
- Identify subtasks that may have been missed
- Find out the order that tasks are most likely to be completed (eg you would read how to become a foster carer, before applying to become a foster carer) by simulating customer journeys
- Find the starting points (the first task selected) for each journey (the common starting points, assuming we have no previous analytics, will become the top tasks).
After the workshop (you may need more then one depending on the amount of changes identified) you should have a good idea of how that section can be built up.
Tasks for everything
You have built a powerful tool in the form of the development roadmap. At a glance you can identify everything on the website, and you know its status.
When you are building the web sections, you may identify that you need things such as a landing page for a section, or a page for signposting. Do not be tempted to just create a page with no task ID when creating these pages.
Every page fulfils a task, even if that task is ‘As a customer I need signposting to the product that is most fitting for my needs‘.
Without a task, and way to track the task (your development roadmap) your big large and complex website will quickly fall back into disarray.
Would you like to know more?
If you would like to know more about the above article, or if you are interested in the concepts discussed, why not get in touch, or leave a comment below?