Testing times? Trade unions should be natural partners in digital co-design


User involvement in digital product design is fundamental to success. Human-centric and design thinking approaches make a huge difference to a digital project’s chances of achieving product/market fit. Testing and refining every interaction in a system improves its performance, and ability to solve an identifiable user need. Taken together those small improvements really add up.

(BTW unions should do way more user testing than we currently do on our own systems, with some honourable exceptions, like UNISON’s great recent work on organising tools, but that’s not the point of this particular piece.)

Modern companies love user testing, and are often willing to pay external consultants or employ in house digital teams with experience of running codesign programmes. It lets them improve customer service in very measurable ways.

How much better would things be if systems that affected work were genuinely designed in partnership with workers, involving them every bit as much as customers? I’m not just talking about whether workers are able to use a company’s new systems effectively to meet the employer’s goals, but also whether feature ideas that workers need can get incorporated too.

Take shift rostering for example. When a company is looking at designing a new rostering system, how about researching the variables that workers would like it to use, on top of the company’s needs?

Whitbread are the parent company for Premier Inn. They’ve become a hugely lean and computerised operation, reducing staffing at their headquarters to a bare minimum and shifting the national and regional management load onto IT systems and (a very under-rewarded) local management in each branch.

If you’ve ever stayed at one of their hotels, you often find reception staff running the late shift and the morning shift straight after, getting a really pinched break to get home and sleep before work again. I’ve never yet met a receptionist who didn’t sigh and shrug when I mentioned it. For a company that’s so efficiently managed, it seems to be one that’s very badly managed.

Here’s a thought. Rather than just getting the shifts you’ve been assigned to make things easy for the company, such a system could also let you tailor your own preferences to a hugely personal degree. How much notice do you need to arrange childcare? What days do other commitments mean you are less likely to be able to take another shift? What’s the furthest you’d be willing to travel to cover a shift at a different branch? What are the longest hours you’d want to work during the month of Ramadan? How do you mark a temporary change to your availability – like doing a short course at the union learning centre?

The insights you could gain from talking to workers about their own aims & situations would make that system so much more useful to the workers themselves. But these things that wouldn’t normally occur to the business to build in would lead to happier workers, and ultimately improve productivity.

It’d help deal with the favouritism and discrimination you often get in shift management, in locally and informally squaring the problems of a system that doesn’t fit its workforce. That’s something that came out as a big concern in the research for our young workers’ project.

Now, companies are already pretty handy at conducting user testing for their interactions with their customers. Nobody wants to spend a year building a new service that people won’t buy. Even a tricky form, or missing some key customer concern, could result in an increase in dropped carts – something that’s easy for the company to quantify.

And that’s where unions could come in. Who else is good at getting to the bottom of issues at work, helping workers name and discuss them in a supportive atmosphere, and devising solutions that can win widespread worker acceptance? We’re great at tackling problems when they arise, but here’s a way we could tackle them beforehand too.

Unions are good on the power analysis of the systems that make work work. But whether it’s ride-hailing, stock control, or business intelligence systems, too often we’re seeing basic decisions made by a bunch of white guys in California, with all the privilege implications that brings with it. AI is going to take over more and more employment decisions, but what’s the effect of design privilege that we need to challenge before it gets baked into the systems that will govern our lives?

Union branches could be an ideal channel to recruit user testers from amongst the workforce and conduct meaningful codesign work on our employment systems. They’ve already got mechanisms for convening workers in a trusted and independent space, and collating and representing their views to management. Let’s just update their methods to fit, and view member input into systems design the same way we currently view a process of negotiation with the employer on how those new systems are introduced.

Union learning centres could make great workplace test environments. Bigger unions could run their own, with facilitators provided by the union, or even shared between smaller unions. Training reps as facilitators could be really valuable to the employer (and the union), helping to mainstream digital transformation efforts in the company.

And where systems are bad but management unresponsive or hostile, unions could find their own independently conducted worker user research a useful way to pinpoint the workforce’s problems and run a clear campaign around workers’ own user needs in work. It could give clear evidence of a problem, that comes packaged with a validated pathway to a solution.

There’s obviously a heavy investment needed here for this to be done properly, training reps and staff in service design methodologies. But there’s a win there for improving the systems that impact so heavily on our members’ working lives. And the new ways of working could rub off in unions too, improving our own systems for a current and future generation of users.

A right to co-design, anyone? I can see the slogans already. “What are our user needs? When do we want them?”


PS – Thanks to John Chadfield and Sam Jeffers for sensible pointers & inspiration in this.

Pls to share (thanks!):