Designing caseworking systems meetup #2

Update Mar 2019: I’m organising another meet-up soon, sign up to the mailing list here to be notified of when tickets are available: http://eepurl.com/gkO2JL

Over the last year I organised two meet-ups for people designing caseworking systems in government. Previously I’d hosted write-ups of the events on a dedicated site (https://cross-gov-caseworking.herokuapp.com) but as that site is password protected (because reasons) I thought it would be better to move over the write-ups of the events to Medium for better visibility.

See the write up of the first meet-up here. Also Andrew Travers did a nice complementary blog post about this meetup.

In March 2018 I ran the second designing caseworking systems meet-up at Newspeak House, London.

Below are some notes from the day.

Big thanks to Caroline Trimm, Rosie Cowling and Lynne Roberts for the hard work taking notes.

Agenda

• 11:00–12:45: Talks
• 12:45–13:45: Lunch
• 13:45–16:00: Unconference

Morning — Talks

Welcome by me

We should talk more about designing and building internal systems. About half of our work at Home Office seems to be on case-working systems.

But there’s a reluctance to speak about internal systems — some I think from a fear of exposing our decision-making processes.

But if we don’t talk about these things, we’ll lose them. We can save more time and money by talking about these things more.

There’s a tendency to outsource internal systems. Why can’t we get to the point where we have a starter kit where anyone working on a caseworking system can use — one stop shop with guidance and code in there to help people get started?

People might think ‘we’ll wait for GDS to do something about this’ — but we don’t need to wait for them to do it, we in departments are the ones who are doing it, so we need to surface that as much as possible.

I made a website after the last meetup that catalogues screenshots of different caseworking tools for designers to reference: https://cross-gov-caseworking.herokuapp.com (contact me via chris.taylor@digital.homeoffice.gov.uk from your government email address for the username and password).

Chris & Joe from DWP, talking about their work in Universal Credit to make case management easier

There’s two main user needs for Universal Credit

1. making sure people have enough money
2. getting people into work/more stable work

There are around:

• 400,000 claimants
• 9,000 agents
• 30 service centres
• 268 job centres

There are different user roles of the caseworking system

• Work coach
• Case managers — do all the stuff to make sure people get paid, answer questions people have about getting a job
• Decision makers — person that decides whether someone is eligible for a benefit or not

Goals for work coaches

1. Making sure they understand someone’s situation, where they are at with their claim
2. Knowing about something critical that might change how you support someone

Problems with caseworking system

• Content is poorly organised
• Actions are poorly labelled
• Analytics on case working dashboard — 2 of the 20-odd sections were used 66% of the time (Internal case history, looking at claimants account).
• There’s a tendency for dashboards to have poor information hierarchy.
• No persistent navigation — adds seconds to each action, which all adds up.
• Some things in the system are rarely used, if ever

Consequences

• Agents miss important things that has a negative effect on claimants
• It just takes longer to do things, takes a long time to learn how to navigate the system, they’ve seen agents creating their own glossary of terms
• It’s hard to add new functionality (like accessing a payment statement to see what claimants are getting paid)

We did three rounds of card sorting, and five rounds of usability testing

We designed a prototype:

• There was no categorisation of recent history — new design divides a claimant’s history into blocks.
• We added labels for users to quickly glance at what an entry into the history is about
• Issue of misinformation as different users are using different parts of the system
• Able to filter history as well
• Agent can ‘pin’ important notes — they appear on the claim overview
• About surfacing vulnerability — important that caseworkers can see this information
• Notes were becoming less relevant over time because markers were getting lost, making a case difficult to keep up to date over time
• Work Coach and Case Manager have different needs most of the time, with occasional overlap
• Notify upcoming things
• Preview content
• Need to surface important information
• Provide single source of truth by giving contextual guidance
• We found that there is poor internet connectivity in job centres — it’s important to have a light page load.
• Their changes resulted in 20% reduction in pageviews (less jumping around pages).

Research findings

• Don’t assume staff have better digital skills
• Users didn’t understand what a browser was, or that they were actually online

Assumptions from previous system

• Lots of people not looking at top quarter of the page because in previous designs, that part of the page didn’t have useful information
• For meaningful insight recreate as accurately as possible what the release experience — the act of being involved gives them a natural predisposition that the thing is better

It’s important to consider onboarding, rather than just releasing the new thing to hundreds of people.

Need to manage expectations — prepare people for the release of the new thing.

Q&A

Q. Was it a success?

A. Released an update few weeks ago, analytics so far show massive reduction in page loads, increased communication. Reaction from agents — initially quite upset, but they are getting used to it.

Catherine from Citizens Advice talking about ‘The Story of Casebook’

Citizens Advice recently built their own case management system and rolled it out to their network of 23,000 volunteers.

Dual role of Citizens Advice

• Advice — help people solve the problem in their life
• Advocacy — log the cause and try to fix the cause of the problem in society

Last year they helped 2.7 million people, and advised on 6.3 million problems

When people have a problem, they come to see Citizens Advice. They share their information with Citizens Advice and that information needs to be stored in a case management system — needs to hold millions of pieces of data, be secure, be usable. It’s not just a design problem.

Case management is a lot wider than ‘how do you make it useful’

Casebook

Very different to the old system, which had been bought off the shelf.

They asked everyone what features they wanted — and they got loads and loads of features.

When they launched the old system it was a massive change and caused large upheaval across the network

Most case management systems do everything for everyone but nothing very well.

They wanted to change the focus onto staff and volunteers.

What they learnt

• Designing with people to make the technology useful is very important
• People volunteer because they want to make a difference and help people, not to spend time using an IT system
• Saving just a few seconds per task can add up to a huge amount of time that can be spent serving users. Their case write-up time has been halved, saving over 24 yrs of time.

They shared a demo site so users could see changes and watch them work — this allowed users to see the changes that were being made, so the newness of if didn’t happen on day one because the users were already familiar with it.

Need to design and build in multidisciplinary teams. Sit together, plan together, problem solve and argue together

“It’s not just about building a caseworking system, it’s about integrating it into our organisation”

Think wider than just the product. Well designed products can change behaviour.

They did get some things wrong — they tried to strip away some things that they thought were unimportant and users complained — but because they were working in an agile way, when they found that something was an important feature they were able to put back in.

Q&A

Q. Were volunteers able to use the caseworking system while out helping people at Grenfell Tower?

A. Yes, he was able to set up a remote station there and help people at their location.

Q. How did you deal with challenging feedback?

A. Overwhelmingly positive feedback, but there is the change management side, preparing users for change. They took a train the trainer approach as they wouldn’t be able to train everyone.

Q. Some reluctance to provide training within Govt (because it should be easy to use by default), how did you address that?

A. Train the trainer approach worked well, training for previous system took 5 days, new training took half a day.

Q. Was the full team available from the outset?

A. Project grew, at the beginning wasn’t appropriate to have a support team. The idea was there but they flexed according to their needs.

Elle Tweedy from Futuregov talking about ‘Designing world class children’s services’

Futuregov provide services in local government and beyond.

Westminster, Kensington & Chelsea and Hammersmith & Fulham are three top boroughs for delivering children’s services across the country. Staff there are doing their jobs in spite of the technology they’ve been given. They are held back by the technology. Three different boroughs, three different case management systems, this is extremely costly.

Following 18 months of scoping they realised there was nothing suitable on the market. Following that, FutureGov ran a 6 month discovery.

When you talk to a social worker, they can’t help but talk about the tech — they wanted to try to stop them talking about the jargon and get them talking about the social work they are doing.

There is a high turnover of social workers, technology is exacerbating the issue.

There’s a lack of transparency, people can’t see the notes that have been written about them, which leads to difficulties building relationships with families, lack of trust.

The technology people are using in their personal life is so different to the tech they are using in their work life.

Re-designing the experience

They created an end to end experience for social workers — but there’s a huge org design/service design piece of work underneath that experience

Key principles

• Spend more time with families, less time in front of computers
• Tech should support social care practice
• Decisions should be collaborative and tech should enable this
• Decisions should be visible to families, let them see what the record says

What now?

They have 10 months to test whether they are going in the right direction.

Aim to develop an alpha service across child protection to improve the lives of social workers, families and young people.

Testing three concepts to see if these are the things that will help improve the experience:

1. Recording with families — accessing and recording information on the go, improving transparency, sharing that information with families
2. Family view — what can we provide families to give them an idea of what the process is and where they are in that process. Everything in one place, allowing families to keep track of what’s going on
3. Single view — single record capturing all activity, creating a clear narrative that informs decision making, allowing workers to coordinate, leading to better decision making

Organisation design sits closely alongside the technology — how to enable behaviour change?

Q&A

Q. If I turn up with my mobile in someone’s home, has there been any feedback that that may come across as trivialising someone’s experience?

A. Social workers are starting to use iPads — different barriers between computer, phone and tablet — tablets seem to encourage a more ‘shared’ approach between agent and user

Q. Working with three different councils, how will you coordinate organisational change across all three councils?

A. Hugely complex, but fundamentally their outcomes are the same, to help families. It’s the way they go about doing it that’s different.

Q. Logistics question, you talk about a discovery being six months and alpha being 10 months, how do you keep interest and motivation high with those people you are working with?

A. Huge fatigue around new systems, the more we can do in the open. Roadshows every two weeks, going and presenting and showing the work. Thinking of creating a blog, then it’s out there and people can see it. They did a similar thing in Australia and it helped to create a community.

Afternoon — unconference

We experimented with running an unconference session in the afternoon which seemed to go really well and generated lots of interesting discussions.

We ran a pitching session first and then planned out the rest of the afternoon on a whiteboard running 4 group discussions.

#1: Discussion around using one-thing-per page on internal systems, by Alice Noakes, GDS

Notes

HMCTS — caseworker system for caseworkers and solicitors. Both like different approaches (solicitors like one thing per page). Solicitors are digital users. Caseworkers are more used to forms.

Need to define what ‘thing’ means, ie what is the question? A process? Sometimes a dashboard is necessary. It depends on the process, ie a ‘thing’ could be a person, including their name, date of birth and address.

DWP — agents got frustrated with one thing per page. Now we group things like ‘claimant details’ and ‘partner details’ (each one thing), to remove some stress.

Defra — “feedback on one question per page is not something I can repeat!” Brevity counts. Simplifying things isn’t necessarily correct if you’re doing it all day every day.

DWP — we’re replacing a Word doc to ask for digital staff. Criteria: there may be up to 30 jobs available at a time.

Home Office — trying to explore patterns since started (new to govt from commercial world). Do we explore examples from the commercial worlds, eg claims practices that exist like insurance? Customer relationship management systems? (DWP — found that insurance claims services are prehistoric) These are common tasks. Personal experience working with banks. Internal systems aren’t invested in, but have we got examples about the end to end approach? We have spoken about the importance of managing [stakeholder and customer] expectations.

People have to understand what the whole service is about, or they only learn their particular workflow, but they don’t always understand why they’re doing it, so they can’t understand how to improve or iterate the service. We get paper scanning, so people are checking if it’s been scanned right. If it was one thing per page, it would take them so long.

Examples of when their idea didn’t work? Ie one question per page didn’t work, it was about types of information?

Home Office — have we explored other channels, like chat rooms instead of online systems

Citizens Advice — we have to integrate all our interactions into one place, new web chat platform to integrate chat into case mgmt system. Or an API. Go with a tech solution.

— seeing what has happened takes longer than it should because loads of people are inputting case notes. How do you filter the important thing?

— in NHS we had to put roadblocks in place to stop clinicians going through scans too fast to ensure quality and prevent missing key information.

DWP — we tried chucking everything on one page and tagged every error message to see which validation errors were coming up (on a dashboard). Went back to observe how agents were behaving and they were hitting page down on a keyboard and what they needed was going off the page, so they were missing it.

GDS failed an internal system because it went through external assessment. You have to make sure you’re telling your story in the assessment because assessors are human. You need to show that you’ve done research and testing and ‘one thing per page’ doesn’t work for your users.

GDS patterns are very much citizen facing. GDS needs to recognise that internal users are different.

It would be useful to have user research from these projects collated internally so we’re not repeating the same things.

DWP — has a github repo with screenshots of designs to see patterns: https://github.com/dwp/design-examples/issues

Local govt — would be good to see a design pattern for allocating work in systems (eg IT support hub).

DWP — It’s usually better to change the content as you can control that easier than the interaction.

Local govt — at what point do you ignore users? Sometimes people who do not use digital at all in personal life navigate extremely complex systems. They are used to very complicated systems and it is muscle memory.

HMPO — examiners say they want “holistic approach” to examining (ie seeing everything related to an application), but need to do specific tasks. There is a timeline available to them so they can see everything if they want but generally they don’t need to, to do a task.

Summary

• Sometimes one thing per page works, sometimes it doesn’t (depends on context)
• It depends how you define a ‘thing’
• Different between what caseworker needs and says they want
• Maybe a ‘thing’ is a task, or group of information

#2 Discussion around designing for expert users, do they need to be trained? by Andrew Travers, HO

Emma, IPO:
Main focus is on external services and users, senior management doesn’t want to put user researchers on internal services. Lone voice at the minute.

Lynne, HO:
How much caseworkers are thinking about when progressing through a case, do they really need training to use the tools?

Andrew, HO:
Would like to think about how we switch the context from designing services for people who have never encountered a service before and might only use it once in their life, to expert users who may use a system for 8 hours a day.

Jewell, HO:
Observation from research: People are nervous to say they struggle to do something because it’s their job, people felt intimidated to ask for help, nervous to click on things and see what happens (afraid of the consequences), because they are working to targets they are nervous to try anything new in case th

Robert, Passports
Principle within passports is no training because senior managers have said they don’t have the budget for training.

Important principle: have the same terminology for things helps to make things clearer

Do you design explicitly for novices, or new users?

If it’s a new thing, you won’t know what the expert behaviours are for a few years

Common problem: people become so institutionalised with how a process works, their whole life is focussed around a process that we’re trying to get rid of

Bill, HMCTS:
Working on caseworking system for judges

Currently all paper based, judges want to be trained on whatever they are going to be given. Trying to deliver something that will work across civil law, family law and tribunals. Trying to design something that allows certain flexibility with how they work.

When tasks are so boring and monotonous, you introduce risk into the system

Kate Tarling is trying to move the place where design happens to earlier in the service lifecycle at the HO

“A lot of these systems are just given to users and they don’t have an explanation as to why something is they way it is…they want to know why things have been done in a particular way”

“Every time you’re releasing an update to the application, you’re having to release an update to the supporting materials too”

Do we need to teach people how to use a service?

Looking beyond what users say they need — might result in a different process to existing. Where is the learning and development, is it in the process or in the tool?

People should be trained in their roles — their jobs are complicated enough — shouldn’t need training to use an interface

Establishing common language — people end up writing their own guidance if different users are using different terminology.

Some users want to be trained — classroom type training (eg judges and analysts). May be afraid to admit they don’t understand something — but if service is intuitive enough this shouldn’t happen.

New users/experts

How we switch context from designing for people who haven’t used a service before or may use it only once, to internal users who use it repeatedly daily.

They will develop hacks/workarounds to do things as quickly as possible & they become muscle memory/take them for granted.

People become institutionalised to the way a process works, and any deviation causes problems — people’s lives work around a process which we then get rid of.

Users get attached to workarounds because:

• they are seen to be the experts
• they may not be the best way of doing things but it’s what they know
• they may be under pressure to do something quickly, so may be reluctant to try something new

If it’s new software you may not yet know what the expert behaviours are going to be.

If there’s a high turnover of staff you may be designing for novice users. But step by step would be frustrating and hamper productivity.

Wizard style approach — help/hints which appear the first time you use something?

How far we automate

We don’t want to design a ‘digital battery farm.’ Eg, user-written emails can be riddled with errors but if you remove that autonomy people’s tasks are boring (which may introduce risk into the system). If there’s anything we can do to make the task more interesting, we should.

#3 How might we build a cross gov caseworking system? by Chris Taylor, HO

Can we get to a place where we have a starter kit for caseworking systems with standards, guidance and code in it?

It should be possible to define a list of common tasks.

What is a caseworking system?

A thing that helps an internal staff member record the decision making process for a thang and be able to manage a complex case of an individual so other people working on it can understand the status of the case.

There’s a difference between case working (backlog of applications) and case management (ongoing relationship with the thing)

Collecting the things that everyone is doing will help us to understand what others are doing — lots of building blocks

“I imagine something the GDS design elements page, something like that, a place where you can lift bits from others and use them in your own service”

“Or at least, there’s somewhere you can have a discussion”

Want to know what design patterns have worked well, in what context, and why — and the why is really important to know — something that says “I designed this, it tested well in this context with these users”

The format of how things are described is really important to people

Chris Taylor
New GDS design system will tell people why to use certain things — but do our needs differ as users building internal caseworking systems?

Craig Abbot — DWP
We are using github to track issues, applying a template to an issue, so that people can add information on why something is/isn’t working

Q. How do you define what the thing is (pattern, component)? Is it up to the designer to make that call?

A. Workshop helped them to identify what things were. Everyone throw their designs out there, then we can see how many people are working on things and have a workshop to talk about them.

Q. How can a cross gov community work together on patterns?

A. Ahead of a meet up — just chuck stuff up, be open — anything. The use a meet up to hone ideas down — face-to-face reduces the technical barriers

If HO and DWP and others solve search, we’ll have five different solutions to the same thing

Chris

“We need to just stop the assumption that we can buy off the shelves and that will solve all our problems”

What’s the cost of this — we intuitively know that off-the-shelf systems don’t work — can we prove this over time by working together.

Lenny Martin HO
Focus on casework (workflow), took the same approach as HMCTS

Define workflow, that’s the bare bones of your caseworking system, take the UI out of the question, define the tech flow, then think about UI once that’s clearly defined.

Make sure the workflow is configurable enough first (HO example where every task has to be shown on every screen because that’s how it was built)

Share research on a slack channel or trello, make sure its anonymous enough to be shareable

2 people in group of 17 don’t know how to use github

“It’s not intuitive, its very much for design patterns, trello might be better for sharing research”

Summary

We had a really good discussion. People seemed to agree that there would never be a one size fits all kit.

But maybe we could have a combination of:

• a modular, configurable workflow engine
• a set of robust guidance and example coded components
• making user research finding more open

We could make a trello board for research findings.

Maybe use a future meetup to discuss and refine the collection of various design patterns (for example, bringing all search examples from different systems and choose the best one that works)

Could we get some principles together? For example:

• Design caseworking systems assuming they need to be consumed and integrated by other gov teams
• Modular, loosely coupled

Lynne suggested the idea of making a big list of needs and tasks that people need to complete.

One interesting discussion was around the different between caseworking and case management.

Caseworking could be defined as a very linear process with a specific outcome (a yes/no decision for example, like processing a visa application)

Case management is more fuzzy, with no obvious outcome (like benefits). Typically one worker may stay with the user for a while.

Its easier to design and build rules etc around caseworking and can be more automated.