How do you write a user story that engineers actually find useful?

Useful stories carry the why and the boundary, not just the what. Keep the user and the outcome in the sentence, then spend most of your effort on acceptance criteria that name the edge cases: empty state, permission denied, offline, and what happens on failure. Engineers do not need poetry, they need to know when they are done and which cases they can safely ignore.

The part engineers actually use is the acceptance criteria, so that is where I spend my time. The story sentence carries the why in one line, but then I list the cases: what happens with an empty state, what a user without permission sees, what happens if the request fails halfway, what we do on a slow connection. Those are the questions I would otherwise get pinged about on Slack three days in, and every one of them is a decision I should make rather than an engineer guessing at eleven at night. I also write down what is explicitly out, because that stops well meaning gold plating. And I run the criteria past the engineer before the ticket is estimated. It takes ten minutes and it usually surfaces one requirement that is technically expensive for almost no user benefit, which I can then drop. A story that gets estimated without that conversation is basically a wish.