User stories can get a bad rap as part of Agile dogma. Dogma, that as loosely coupled ideas that worked for some people, is best to be avoided.
Complaints against user stories allege superfluous fluff, reminiscent of a curmudgeon in their mandated "Anger Management" therapy session being forced to talk about our feelings.
However, user stories help us generate the metadata we need to implement features with limited data. User stories help us to intuit and infer what we need with limited data.
Consider the requirement of "ability to change passwords". Ignoring the straw man of this shitty requirement, a user story can help drive requirements with simple language.
For "as an sysadmin, I'd like the ability to change passwords", as a sysadmin I may not need a fancy UI, or a UI at all, and the passwords I change are likely not my own.
"As a customer service rep, ..." has similar requirements to an admin, but they'll be changing passwords a lot more frequently, on behalf of the customer. They still don't need a fancy UI, but they'll be better off with a UI that has focus on UX for someone working as a customer service representative.
"As a customer, ..." turns the design principles we just used on their heads. The customer may change their password a handful of times, and yet we want to provide a great experience.
In defense of user stories, they're a tool that takes advantage of our natural language skills that guides us in design, requirements gathering, and acceptance testing without having specific the specific knowledge, experience, and vocabulary in those respective fields.