You can't invent meaningful targets out of whole cloth. Pragmatically speaking, both business analysis and user experience requirements all require forming a hypothesis, testing the hypothesis, and then drawing an actionable conclusion (e.g. your specifications) from the results.
Your team (and particularly your Product Owner) don't appear to have the right processes in place to gather meaningful specifications about non-functional requirements related to the user experience.
Gathering Requirements is a Real Job
My question is precisely about how to make good stories. Say you're making a game, and starting a level takes two minutes, which frustrates playtesters. The user need is concrete ("goddamit I want it to load faster!") but vague.
Good requirements gathering often entails experience in performing multiple drill-downs until you get to actionable specifications. "The load time is too slow" is not an actionable statement. However, a management target based on industry research (e.g. "load times must be less than 8.3 seconds to maintain engagement") or actual experimental data can certainly be turned into user stories.
A Product Owner should be working with Business Analysts (BAs) and User Experience (UX) designers to construct tests. For example, the UX team might develop a minimum viable product with load times of 5 seconds, 10 seconds, and 20 seconds. A good UX team would then gather data in the form of opinions or testable human behaviors to determine how "sticky" the product is at different load times to see what level of load time leads to actual disengagement or lack of interest in the product.
User Stories Are Not a Substitute for Understanding the Knowledge Domain
User stories are conversational placeholders between the development team and the Product Owner or end users. They are not specification documents, nor are they a substitute for essential business skills. A great cross-functional team may include UX expertise within the team, but most often requirements-management of this kind is really external to the team, and proxied by the Product Owner.
In other words, your problem isn't that you are having trouble crafting the user stories. The real problem is that your team (and particularly your Product Owner) doesn't have the right processes in place to gather meaningful specifications about non-functional requirements related to the user experience. Whether internal or external to the team, the organization needs to ensure that those processes exist and are properly hooked into the product development process.