Agent interfaces

Information vs data: workshop

In March 2024 we ran a workshop with interaction designers from different services across DWP.

Problem statement

Citizen facing services follow the 'one thing per page' format resulting in a journey for focussed tasks. This doesn't always suit agent facing services, where users need to review complex data to make decisions and take specific actions.

This can lead to the interfaces of agent facing services to become stylised representation of data, instead of data driven journeys and tasks.

The problems that this can create are:

• Overuse of unsuitable design system components to represent data structure and relationships e.g. details component, accordions

• Data not being surfaced and represented when required for a task i.e. users have to navigate pages or progressive reveals to collate the information they need

• Users may inconsistently or incorrectly interpret the data to determine the next steps and actions to take - which can lead to inconsistencies in the service provided

• As more journeys and tasks are added to a service the representation of the structure and relationship of data tables in the interface can become complex and harder to interpret as the data displayed has multiple purposes

• Can lead to users breaking GDPR as they can see information that is not relevant or essential to an enquiry or task

Workshop challenge

The designers were spit into small groups and challenged to design alternative solutions for 5 common tasks for a telephony agent system at a fictitious insurance company. The teams all had the same agent tasks to redesign:

• Security check

• Answer to common query of what are the total monthly payments

• Get new monthly payment when adding a new policy

• Chase progress of a claim

• Change of address

The teams were also provided sample screens from the current fake system for reference and some user needs and pain points that have been gathered from DWP agent services.

Ensuring the solutions were presenting information that is actionable and task based, the teams were asked to focus on:

• Turning data into useful information for agents

• Consider what job each UI element is doing

• Consider new components if existing ones don't do the job

• Develop journeys for tasks that surface layers/fidelities of details relevant to that task - starting simple and taking the agent to more detail as the task gets more complex

Outcomes

The outputs of the workshop surfaced some common themes in the solutions from different teams working on the same tasks.

Safeguarding and not presenting data that is not needed for a task

Teams ideated solutions that kept information safe and avoiding any unnecessary exposure in line with GDPR. For example, the current fake scenario showed a personal details page where agents would navigate to and ask callers security questions. The problems highlighted by teams was that the agents may ask different questions than their colleagues and would be viewing personal details that is not required for security. Teams also identified there could be potential security risks by showing details not relevant to the task, entering the wrong record to see details of another customer, ineffective trace logs as there is no way of knowing when an agent has viewed a particular piece of information and for which purpose.

Teams suggested a journey for security checks where the system would present questions which agents would ask and enter the caller’s response. The system would then validate the response against the data held and surface if it was correct or incorrect. This means agents are not viewing personal details and still able to validate the caller, without compromising the customer private details. This solution also means all agents would be asking the same questions as the system determines what the security questions should be.

Summarise data into simple information

Groups ideated abstracting relevant data into summaries to tackle simple queries and give agents some understanding of the caller and their situation. These summaries tended to be placed on some form of dashboard or landing page. The intent was users would not need to navigate through pages with lots of data and come up with the summary. And agents would not need to do any calculations or multiple look ups across pages and different data to communicate basic information to the customer.

Teams also ideated the ability to link from the summaries to more detailed information and the data behind or launch tasks that are contextual and relevant to that information.

This is an example showing how a team would take the payments data and summarise it into information that agents could use to answer a common query: what are the total monthly payments. Some examples gave agents the ability to start a task from the summary linking agents to a higher fidelity of information. These solutions gave context and direction to the agent's journey and surfaces navigation relevant to that context.

Only request information that is required, and confirm the information already held

In response to adding a new policy task, teams ideated journeys where only the details that were missing requested. Any data that has already been provided for existing policies was surfaced for confirmation. This ensured the addition of a new policy journey had only as many steps as were necessary to collate the data required.

Teams agreed that not all journeys needed to be a standard set of steps and a better experience was to make the journey dynamic based only on what additional data collection was required to complete the task as efficiently as possible. Teams also highlighted the need to ensure that any existing information that is required but already held should be presented to the agent to confirm with the option to update it if required.

Only surface information relevant to the context of the task

Teams concluded that there was no need for a specific personal details page as these details were surfaced as part of the tasks. There was no need for an agent to view a customer’s personal details on a page. For example, for the security checks only required agents to enter in answers to specific questions which the system returned a correct or incorrect response. Another example was for the change of address task, the agent didn’t need to go to a page to see the current address, they just need to start the change address task and enter the new address.

Help users understand the information they are processing

A common finding led to enabling agents to understand the information they are viewing. In services it is common that agents are presented with a lot of data that they need to interpret to get an understanding of the person or case behind the data.

By guiding agents through information initially through summaries leading to more detail, the belief is that agents would have a better understanding of the person or case.

The opposing argument raised was that the interaction cost of reaching detailed data would be increased. However the retort was that the interaction cost may increase but with each step the agent has a better understanding as they move forward i.e. one click to a data table might have a lower interaction cost but the cognitive load would increase to find and understand the details for the task. This would be disproportionate effort for quick or less complex queries.

The opposite scenario is to increase the interaction cost but the smaller steps help agents to get aa better understanding of what they are looking for and what has happened. The intent is that the majority of simple queries would be answered earlier in the process, and for more complex enquires agents should be taking time to understand the information and situation, scaling the interaction and need for more detailed data as the complexity of the query goes up, whilst minimising the cognitive load to complete the task.

The other advantage discussed is that there is lower risk of making mistakes, misinterpreting data and by limiting options and tasks to only those that the data allows agents could provide a more consistent service provided by different agents.

The aspiration is that time on the phone live with callers would be more communicative and efficient instead of silences where agents are searching and trying to understand the data especially when dealing with callers in distress.

Next steps

We'll continue to build on this workshop to develop our understanding of agent interfaces and see if there is useful guidance to be written and published.

---

Could we improve this page?

Send questions, comments or suggestions to the DWP Design System team.