The way to think about the information on a card is that, while you do not list out all the details you have, you use the card to capture the basics, to act as a reminder and to provide information on where to find more details if required. One way to think about the level of information is to think about an old library system to find books - an index card would allow you to find the information you need. And don't forget, I User Story is a “reminder to have a conversation”.
The following sample information follows the expectations from established as a result of following the the INVEST criteria, assuming you are capturing the results in a work management system (e.g. Jira, VersionOne, Rally, etc.):
Title: 3-10 word descriptive title that clearly describes the outcome; make it meaningful. Experience shows that cards (and tools) get very “busy” if you use the user voice format of the story to reference it. After spending time with the story, people will naturally use short cuts to reference the information. This is the short cut and is used to reference the requirement in discussions and meetings. Titles work best when it completes the statement:
User Voice: Has a “user voice” form of the requirement (“As a <role> I want <capability> so that <I get this value>”)
Acceptance Criteria: Has an acceptance criteria that helps us understand when we are done. Where possible these should be defined with examples (i.e. mostly written in Gherkin “Given <system is in this state> when <I take this action> then <I expect to see this result>”)
Type: The issue type (story, defect, etc.) is correct for the work
Estimate: Has an estimate based on completing to Definition of Done, and used by the Team to understand how big the piece of work is so they can plan appropriately. For Stories that are about to be worked on the estimate small enough to fit into an Iteration (Sprint) (estimate is typically sized below some threshold that means something to the Team e.g. 8's and below will fit into an Iteration)
Dependencies: Have been identified and priority aligns with Iteration (Sprint) timing
Prioritized: Items “expected” for the upcoming Iteration (Sprint) are prioritized appropriately, including improvement items from the Retrospective. In other words they are at the top of the Team (Product) Backlog
If you are doing this with physical 5×3“ index cards, the back of the card will typically have the acceptance criteria and other notes that come up during the discussion, while the front will have the title, description, estimates, etc.