Law has legal engineers. Will UX have experience engineers?

Your train is delayed. You ask a travel app to get you home as soon as possible. It rebooks you on an earlier service and releases your original reservation. Only then do you discover that the new train has no wheelchair space available. The app has found a faster journey. You are still on the platform.

Who designed that decision? When you book for yourself, you can inspect the options before you commit. In this imagined service, software has acted on the passenger’s behalf. Someone had to decide what “as soon as possible” authorised. I think the person who can turn that question into a service that passengers can trust will become a familiar figure in user experience design. We might call them an experience engineer.

What law can tell us

When Daniel Himmel left legal practice in 2018, he worried about where the move would take him. Eight years later, he told Sarah Kessler at The New York Times that he had hired about 70 people in a year at Legora, a legal technology company. Its legal engineers help clients work out where AI fits into legal practice, trial it on real tasks and teach colleagues to use it. Law firms and in-house legal departments have also recruited people to do this work. [1]

The distinction is easiest to see in a contract review. Using software to flag an unusual clause is one skill. Designing a review process means deciding which clauses warrant scrutiny, what evidence the reviewer needs and when a second lawyer should intervene. The second task draws on experience of what can go wrong after a contract is signed. That is why a practising lawyer brings something distinctive to it.

Two design jobs show where the analogy might lead. Stripe has sought a research operations manager who can build AI tools alongside researchers and help colleagues adopt them. At monday.com, a lead product designer has a different brief. Here the designer shapes how an agent acts for customers and when it hands work back to them. One role changes how a design team works. The other changes what a person can entrust to a service. It is this second responsibility that I expect to grow. [2] [3]

What may the service decide?

Return to the passenger on the platform. An experience engineer might work with wheelchair users, station staff and software engineers to agree that the service should keep the existing booking until the operator confirms an accessible alternative and the passenger accepts it. They could then prototype a case in which the booking system shows a space, but nobody can confirm boarding assistance. Testing that case with passengers would reveal whether they can reach someone with the authority to help before the train leaves.

This question has a history in human–computer interaction. In 1999, Eric Horvitz examined how software should decide whether to act, wait or ask when a person’s intention is uncertain. What gives the question fresh urgency is the reach of the action. Once an agent can release a reservation, an organisation needs someone who can trace the consequences beyond the screen. [4]

Why the role is likely to travel

Healthcare offers a telling precedent. NHS England describes two ways to use software that flags possible cancers on images. It can take the place of a human reader at one stage of screening, or it can flag cases for a further look after clinicians have read them. The same technical capability creates two different clinical services. Deciding between them requires people who understand screening, can anticipate the consequences of a missed case and know which outcomes to measure. [5]

I expect versions of this role to spread across many disciplines over the coming years, particularly where a system can commit an organisation to a decision that someone else must live with. An educator might help design a tutoring system that recognises when to leave a student to wrestle with a problem. An insurance claims specialist might specify when conflicting evidence should bring a claimant into conversation with a person. In a large organisation this work may justify a dedicated post. In a smaller one it may become part of an experienced practitioner’s remit.

For those of us teaching UX, that suggests a sharper brief. Give students the delayed train. Ask them to build a service that can rebook it, then let a passenger challenge the decision. Can the passenger see what the system assumed, correct it in time and change their journey? The answer tells us more about the quality of the design than a successful demonstration ever could.