The question exposes some fundamental misunderstandings in what a user story is.
The first misconception is about what a user story is.
Stories originate from Extreme Programming. A core practice of XP is to, as Kent Beck puts it in Extreme Programming Explained 2nd Edition, "plan using units of customer-visible functionality". User stories are those units of customer-visible functionality. He gives several examples in the book: "handle five times the traffic with the same response time" and "provide a two-click way for users to dial frequently used numbers".
The earliest XP teams wrote these stories on physical cards, often index cards. These cards would have a brief description or title and enough information to help the team create acceptance tests, design a solution, then implement and verify it using the acceptance tests. Any key constraints would also be added. In the end, though, it all fit onto an index card.
The "as an X, I want Y so that Z" structure is known as the Connextra format, named after the company where it was popularized. This format is designed to give some additional structure to the user story so the team can capture the critical information about the user(s) being served by implementing the story.
In today's world, with teams that are no longer colocated (and even widely geographically distributed), electronic tooling has replaced physical cards for many teams. Teams, embracing a fundamental tenant of Agile Software Development to "uncover better ways of developing software by doing it and helping others do it", have developed other structures for stories.
The second misconception is about collecting requirements.
The earliest XP team was building software for internal business use. Another principle of XP was that the customer is always available. This was realized by having the onsite customer embedded alongside the developers on the team. However, since the team was working on an internal business application, they had ready access to business sponsors or users by walking down the hall.
Although teams are using agile methods for building internal business applications, producing software for sale in the marketplace is also common. When producing commercially available software for various customers and users, the variations in their needs and expectations grow. Product managers, business analysts, and other people gathering requirements from stakeholders have to talk to many more people and often deal with a lot more conflicting demands.
Domain-driven design, especially the concepts of domains, bounded contexts, and ubiquitous language, has given developers practices to improve system modeling. However, human language is still messy. Even business users within a single company may not share a common language, and as the scope of prospective users and customers grows, the language expands. Trying to get a user to express an unstructured idea using a common language is a challenge, much less trying to force a structured answer that users will likely be unfamiliar with.
Customer research, user research, and competitive intelligence will drive the product vision, strategy, roadmap, and requirements. You most likely cannot walk away from one, or even several, interviews with requirements. You'll get ideas that need to fit into a much broader picture.
