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.
Most government departments use various forms of caseworking system for staff to process applications for licences, grant permission to do things and to record decisions.
Back on 10th October 2017, I ran a meet-up for people working on caseworking systems at Aviation House in London, so they could share what they’re doing and look for common patterns that we might be able to re-use across government.
Below is a write-up of the day.
HUGE thanks to both Alice Noakes and Joe Lanman for doing all of the actual hard work of taking notes.
Agenda
- 10:30–11:00: Arrival
- 11:00–12:30: Show and tells of case-working systems and a talk on service patterns and language in case-working
- 12:30–13:30: Lunch
- 13:30–16:00: Workshop on identifying common patterns and components
The morning speakers
Presentation on casework for registration of land boundaries
HM Land Registry, presented by Sam Brierley (Head of UR and Design)
Boundaries are a big issue for Land Registry — seen in volume of calls that’s high with queries.
Boundaries are emotive for people, and they are imprecise — lots of different interpretation eg physical boundary might not be in the place of the legal boundary.
Caseworkers use the term customer, not user.
Used a strategy to get caseworker buy-in by providing some quick wins to make short term improvements, a trade off for needing commitment in the long term.
Myths: Users expect Land Registry to be able to do things they can’t. Main reason of call is ‘who owns this wall’ but Land Registry can’t help.
An issue for call handlers and caseworkers was that they could help, but advisory policy says that’s not possible.
Pain points:
- Poor quality applications
- Applications that should never have been made
- Caseworking is hard!
- Case workers also have misunderstandings about the process
We looked for quick wins, encouraged self-service.
Content and guidance was improved, for users and case-workers.
A service map was not so useful in itself, but helped start conversations.
90% of calls are from users who think HMLR have made a mistake in location of boundary. 0.04% are actual errors made by HMLR.
We identified common service stages, means they can assemble from common components.
Questions for the speaker:
Q: Where did these myths come from?
A: The middle men (conveyancers) mean Land Registry is a black box to users. Also the paper work flow is complex.
Q: Do you see this as case-working design or service design?
A: Previously case-working, more recently service design. Steve Railton from Transformation Directorate at GDS is supporting this move.
Q: I recognise all this from our experiences at DWP. I see caseworkers as ‘detectives’ — they really want to know everything about the applicant, even if they don’t need all the pieces of info to make decisions.
A (Ben): Caseworking can move from a deductive process to a considerative process when caseworkers know what the limits of your decision making are — creating model offices — and able to do this by starting with apprentices, who don’t have 30 years of caseworking experience.
A (Chris): People worry we’re going to get rid of their jobs, (with new caseworking systems)
Ben: Telling people we’ll take away all the ‘cookie cutter easy work’ so you can just focus on the tricky, legally sensitive stuff is not a good message
Presentation on Licensing for International Trade and Enterprise (LITE)
DIT, presented by Jonathan Hirsch(UX architect)
This service can cover anything from a large corporation that has a department dedicated to submitting applications, to an individual who wants to take their rifle abroad for a competition.
‘Design like you’re right, test like you’re wrong’ — they needed something that works pretty good when they get started.
We started by making a service map.
The stages of activities across the user’s journey were split up across different internal depts. All located in different places.
We found that everyone loves the way they currently work — even though the UI is terrible and inaccessible, they love it.
The outcome is a ‘bunch of letters’ for the user — could be a refusal letter, could be granted, or a combo of these for different parts of the application.
A user quote on viewing the system they have designed: ‘Get rid of all the white space — put content in there’.
The team started with GDS patterns, but they don’t always work — so they’re taking the ‘spirit’ of the patterns.
The design currently uses the language of the existing case workers, things that make sense for them now, for example ‘work basket’. Acknowledges that this could cause problems for new users of the system.
Task screens are basically simple forms. But some are more non-linear.
The team think it’s better to show disabled options than not show — a prompt to caseworker that there’s stuff that needs to be done to proceed, eg to issue a license or bounce it back to someone else.
They researched the working environment of caseworkers— all caseworkers have big screens, so they’ve optimised for large screen (1200px) — ‘if someone doesn’t have a big screen — buy them a new one’ — it’s cheaper to buy monitors than do the design work for smaller screens.
The team have created a set of guidance and examples in a design library.
Caseworker users often had two screens — ‘they liked popups’.
They might need to work on single rows, or bulk edit.
Jon showed an interesting right-hand ‘side panel’ that slides in over the table to edit the rows. Tested really well with users, who can still scroll up and down the table while editing. They used this side panel on other screens too.
Research is hard — users are very used to old system. They told their users where things had moved to. They’re used to small text on wide screens, no white-space, not accessible.
Caseworkers keen to have as much on the screen as possible.
[Shows a pattern where table rows expand to show lots more info]. This allows people who need all that info to see it, and see it for multiple specific rows.
‘I think this is a deviation from the pattern — showing a sub form when you click a radio button’
It’s been a balancing act — ease of use, accessible, scalable, showing lots of information.
Questions for the speaker:
Q: Did you test with users with accessibility needs?
A: Had a user with low vision with a very large screen, it worked for him. We have a decision to use JS without a fallback.
Q: Did you have a content designer? Do you think it would benefit?
A: We did have access to a content designer at some times. We worked closely with caseworkers. The data is what it is, not much opportunity for different wording. There is a need to get a content designer involved. ‘Complete but not finished’ is the approach we’re trying to take, so something being missing is not an issue in testing.
Q. About ‘due dates’ — the ones in the prototype are relative — what research backs this up?
A: We’ve done a lot on this, days elapsed, days remaining, progress against SLA (two in some cases) days remaining is what matters (from research). On target, breaching target. If case is bounced back to applicant, the clock stops. We got to days remaining in a circle, colour coded for breaching SLA (red amber green)
Q: Caseworkers cherry-picking work — is that a problem you looked at?
A: Managers allocate work. There is some discretion, in theory working on most urgent, in practice maybe another one because I can get it done. There’s no requirement to force users to do the next one (priority) on the list.
Presentation on Booking travel within and out of the UK
Home Office, presented by Helena Du Toit( Interaction Designer)
This is a travel booking system where caseworker books travel for a person or a whole family — this info is collected and goes to the travel agent to find flights etc. Then the system takes info from the travel agent and displays it.
From research we found that caseworkers:
- rarely use computers outside of work, especially work of this complexity.
- are told to ‘be digital’ — but what does this mean? Paperless?
- act on what they are measured on (you get what you measure)
- work on a desktop machine, and generate the same no. of docs in Doc Gen then print all the files off any way for records
- don’t seem to be trusted, eg ‘cherry-picking’ ‘they’re not doing X’ ‘need to make sure they are checking Y’
- are fearful of making a mistake and being blamed. For example, if they see an empty text box they fill it with everything possibly relevant in case it’s ever looked back over and their work is called into question.
They’re resilient — they have worked with terrible systems. They create workarounds and are proud of it.
Presentation on service design and internal systems
Home Office — Ayesha Moarif — Service Design Lead
Instead of thinking ‘case working’ — think how do we make decisions about an application more effectively and efficiently?
Find big stages in services that are not likely to change.
Caseworking = Make a decision, fulfil a decision stages.
Think of the things that are unlikely to change in 10 years. How it happens might change but it still happens.
Set measures for outcomes so when you try new stuff you know how it performs.
It’s great that we have patterns, check before you start.
- Break down
- Whats the input?
- Decisions to be made
- Decision outcomes
- Data required
- Activities undertaken
- Artefacts or proof
What are similarities and differences across services in the above?
Kate Tarling has written well about this already:
The afternoon workshop
The intention of the afternoon was to run two workshops, one to look at what common components and design patterns we could identify and one one the common stages of caseworking. But in the end we only had time for the first.
We’d asked the attendees to bring along printed screenshots of their caseworking systems with them for our exercise.
We then split everyone up into smaller mixed groups and pinned up the screenshots on the walls.
Each team then reviewed and discussed each others designs to look for common patterns and components, which they then wrote on post-its and presented back to the rest of the room for discussion.
I’ve written up the notes from the group session.
We generally found a lot of commonalities around the need for things like case lists, case view pages and the need to record and perfrom actions on cases.
The outputs from this workshop form the basis for the a caseworking resource that I’ve published which contains screenshots of examples of work categorised by type: https://cross-gov-caseworking.herokuapp.com
I’m always looking for examples to include on the site — so please let me know if you have some that you’d like to add.
Contact me via a gov email address at chris.taylor@digital.homeoffice.gov.uk for the username and password.
