I have the idea that when we are redesigning internal systems, although we go out like good UCD professionals and talk to the users of those systems, there's an extra dimension of challenge. Because in some ways, those users are not actually best placed to help with that redesign.

The people closest to a system often understand its flaws better than anyone. They know the workarounds, duplicated effort, clunky approvals, unreliable data, and frustrating handoffs. In that sense, they should be perfect design partners. But they are also being asked to critique the very arrangements that may protect them, give them informal control, or make their expertise indispensable.

A spreadsheet only one person understands, a process that depends on local knowledge, or a workaround that keeps a team functioning can all become sources of identity and security. This means there can be a emotional dimension too, the thought of change can feel like a rejection of all that built up knowledge and expertise.

This is particularly true for staff who are overworked or stressed. If you have learned a system, and have to a certain extent mastered it, and you have a lot to get through, then the system you want is the one you have. No matter how much you might see how clunky it is, all it's parts make sense to you, and from your perspective all of them are necessary. You understand it so you can make it work, which right now is your top priority. The idea of losing that control is unthinkable.

This makes doing UCD with these people extra hard. But it's a challenge we must overcome if we're actually ever going to transform legacy systems and more the public-facing services they facilitate.

What's required is a more nuanced approach. It's not enough to ask people how they work, or what they do, or even to ask them what they need to get the job done. Of course those questions are vital, but we must be careful not to take the answers at face value. We have to see through the surface to the real needs that lie underneath. What is the purpose of this tool? What are the essential parts, the bits of process without which the whole thing couldn't work? How far can we simplify our picture of these things, until we're left with only those essential parts. Can we create an MVP of just those things?

If we can see those needs, and design to meet them, we can get closer to creating tools which might actually bring transformation, because it is only by doing this that we can bring to bear the full weight of digital capabilities to solve those problems.

But that's not the end, because if we prototype these tools and bring them to those people to test, they are almost certainly going to be met with rejection. People will not recognise them, and as mentioned, the combination of self-worth, and worry at the amount of work they have to get through, will make the thought of these changes unacceptable.

So again, it's absolutely vital to ensure we do things properly. Not asking what people think, are whether they prefer the new over the old, but quietly watching them to doing the job, observing carefully, not for perhaps superficial evidence of confusion or frustration, but just for the real blockers, the places where they would have been unable to complete a task or produce the right outcome.

There is a fine balance to be struck here. It's very hard to determine whether a reaction to something is based just on inertia or on a real need, but it's vital that we do this. If we don't, we are destined to simply build an rebuild the same systems over and over again, guided by a totally understandable need for predictability and ease, from people who's jobs are hard enough already, but whom might not actually be best placed to tell us what they need.