The kinds of details to include (and not to include) in a user story:

• Pretend you know nothing about Wagn.  What we want in our user stories is an enduring record of the kinds of information users want to see, and the flow in which they want to see it.  We try to avoid words like "card" and "cardtypes" and "queries," because these are all implementation details that can change.  Wagn we can overhaul; users we can't.  These user stories are meant to be somewhat more permanent than most any given Wagn solution.
• Only say "page" if page is important.  A corollary of the last one.  You don't have to know anything about Wagn to know about webpages, obviously.  But what we're angling at here is that in many cases it doesn't matter whether you click to a new page or open up more information on the same page or whatever other solution.  The key thing is that you start at point A and get to point B.  So, rather than saying a user "clicks from the address to the map page," say that the user clicks on an address and sees a map."  Sometimes the page is important, so we try to reserve the word for those cases.
• Be specific about the data.  Whereas we're asking you to be very general about the layout and the specific organization of the page, the data itself can be very specific -- this makes it a much more realistic story and is a more precise test.  So, rather than "user clicks on a geographic area and sees a list of locations within that area," say Harry Peach, the Captain of the League of Hirsute Plant Ovaries, clicks on his native Georgia and sees a complete list of Georgia's counties.
• Break the story into lots of little stories.  The idea is to make the test very granular.  Instead of Princess Margaret reads a page about feeding ducks and then gets an infographic on white bread ingestion and then goes to provide feedback about the infographic, etc., try to offer the stories in bite-sized pieces.  Because, like so many nonprofits, we deal with small bills.