The reframe : It was never a form problem

The brief arrived in typical manner- the SAP access request takes 30+ minutes, so build a shorter, smarter form. When I conducted my own research and where the time actually went, filling in the form only ever took about five minutes.

The other 30+ went in finding the correct information to fill it in - employees pinging Slack, chasing email threads, and asking colleagues across time zones to work out which system, role, or company code they were even supposed to select. The actual target was the information hunt, and that changed what we were building. The ticket data showed the same problem from the IT side. When someone asks for access, their ticket usually goes to the wrong team first. That happens because people don't know what to ask for. So they guess, and IT spends time sorting out the mess.

The ticket data showed the same problem from the IT side. When someone asks for access, their ticket usually goes to the wrong team first. That happens because people don't know what to ask for, and IT spends time sorting out the mess.

Making the form shorter would have saved five minutes out of thirty. The real problem was everything that happened before the form - finding out what to ask for in the first place.

What shipped first, and what it taught us

The first release was a pure conversational agent - ask in plain language, the assistant handles the rest. I'd argued against that approach from the start and I lost that round. It shipped, and user frustration was high.

I built the alternative as a working prototype in parallel while the conversational version went out. The reason turned out to be structural - access requests are consequential and auditable, and a chat transcript gives you no way to check at a glance what you're about to input. People couldn't verify what they were approving. That was information no amount of argument in a meeting would have produced — the release settled a question we couldn't settle in the abstract, and it settled it against the approach the team had backed.

The Form Panel pattern

I built the alternative as a working prototype in parallel while the conversational version went out, and this became the second release.

The Form Panel pairs the conversational surface with a structured, editable form beside it: chat does the information-hunting, the panel holds the truth the human signs off on.

What I'm currently working on

I'm designing the approval experience that lets line managers handle their approval queues directly inside Loryn, without switching between systems. The idea is that Loryn analyses each request before the manager even opens the ticket / request, which means checking compliance, verifying budgets, cross-referencing status, and shows a recommendation alongside each item. Managers can approve an individual item, or multiple in one clean action. Escalated items are flagged by Loryn beforehand and suggest the manager the next action. Every action Loryn takes on a manager's behalf is logged with a reasoning trail, which can be checked anytime, and is reversible within a 12h window.

The broader vision is to shift the approval experience from passive notification / email inbox into an intelligent system, where routine decisions are handled automatically under delegation rules, and human judgement is kept for the cases that genuinely need it.

Impact, and what I'd measure next

The clearest outcome was my design influence - the pattern replaced the shipped approach: the product team changed its interaction architecture on the strength of a prototype and the user response to the first release.

Loryn now reaches around 11k employees across Europe, North America, AMEA and LATAM. On the operational side, monthly IT ticket volume in the six months after the March 2026 release averaged around 23% lower than in the 5 months before, with the categories we designed for.

What's not working is that about one in six people still give up and ask a human agent instead. I think better error messages and clearer confidence signals on the form panel fields would fix that. The thing I'd measure next is how often people change what the AI filled in. If nobody edits anything, it could mean the AI is always right (which is not going to be the case) or it could mean nobody is bothering to check and I would look at the rejection rate of the requests. If people aren't editing and nothing gets rejected, the AI is doing well. If people aren't editing and things are getting rejected, they're just clicking approve without reading.