As an administrator I wish to be able to edit a user so that I can change their details when required.
Your story is missing a meaningful value proposition. Specifically, your "I want" and "so that" section are largely duplicates of each other, and don't really explain the why of anything.
All stories contain organizational and team assumptions, are built on an organizational lexicon, and implicitly include the team's Definition of Done. These stories are placeholders for a larger conversation about a feature. However, getting the story right adds a lot of clarity and places some scope around that larger conversation.
A Worked Example
As an example, let's imagine that your current application doesn't let anyone but the database administrator (DBA) change user data. Currently, the application administrator is getting lots of support calls that have to be tossed over the wall to the DBA, because there's no interface in the application for changing a user's mailing address.
Your story now has some additional context that we might want to capture like so:
As the Foo Application Administrator
I want to be able to change a user's mailing address
so that support tickets can be closed without escalating to the database administrator.
With this story, we now have a concrete problem to solve, and the value proposition of the feature is much more clearly defined. This is progress!
Re-Working the Example
Then again, perhaps the real problem is that customers have to call in for support in the first place. Maybe the "feature" above is exposing the real problem. For example, consider this restatement of the original problem:
As a Foo Application User
I want to be able to change my own profile data
so that I don't have to call technical support to update my account.
Assuming that this is the root cause that was feeding the original story, this new story might provide even more bang for the buck. Remember, at the planning level it's important to look at the whole process, and not just the story in front of you.
Even if the examples above don't really apply to your specific example, hopefully they show how a more contextual and tightly-scoped story can be written. Agile practices rely on transparency and visibility, so it's very important to avoid "invisible work" while still ensuring that the stories are written at a level that communicates level-of-effort without dictating implementation details.