I'm afraid that I must respectfully disagree with the false dichotomy you present between [bad!] writing detailed user stories and [good!] conversations that build shared understanding.
User stories have a life cycle (or ought to), often starting as just a headline (e.g. Manage Location Information), captured in the heat of conversation or the quiet of reflection, then growing into a summary of the need or business value to be delivered (e.g. As a [Role Name], I want to [Business Capability], so that [Business Value to Be Delivered]), and ultimately adding business and technical detail.
Detailed user stories that include objectively verifiable acceptance criteria can be started by product owners/managers, and these in-process stories can act as the basis for team discussion, framing the basic problem and providing context. This can save significant time compared with starting the conversation with only a skeletal headline or summary.
The problem with most "conversations to build shared understanding" is that they take place over days or weeks, take place in person, in instant messages, in email, in threaded Jira comments, etc, but are rarely consolidated into an authoritative, declarative description of the job to be done or the definition of done. What results from most "conversations" is a sort of tribal knowledge or oral tradition about the solution that is remembered differently by almost every member of the team.
This inevitably results (where's my shocked face?) in confusion, re-work, and the erosion of the business's trust in the team to deliver what they need.
And whether you're comfortable with it or not, user stories do exist to capture requirements -- what the system must do, i.e. a single interaction between a user and the system. That's actually the definition of "user story". This isn't at all at odds with understanding needs or walking a mile in the end-user's shoes. In fact, this is the reason the user stories should always be written from the end-user's perspective, rather than being expressed as what I call "engineering directives", as is all too often the case.
