Creating meaningful user stories

We are trying to use BDD to create a web service to supply data to a web page and then save the user's changes.

The story I have so far goes

Given I want the data for order number  1234
When I load the data
Then I have the data for order number 1234

What am I missing in my approach? Are user stories not appropriate for this kind of task? How do I go about formulating meaningful user stories?

[Update]

As a customer
I want to see my order
So that I can check it is what I expect

Given I have entered the order number
When I Click GO
Then I should see my order displayed on the screen

Solution

Here's how I'd write what you have so far:

Feature:
  As a customer
  I want to be able to view and change my orders
  So that I can check that they're being processed as I expect and deal with them if they're not

  Scenario:
    Given I am a customer
    And I have an order
    When I go to the order
    Then I should see the order

(I indented the way my tools seem to want me indent Cucumber, which is what I use, but that's not important.)

Here are at least some of the reasons why I'd rewrite it that way:

It is usual for several Scenarios that have to do with the same product feature (order management in this case) to be in the same Feature file, so the Feature section should have a broader scope than a single Scenario. Maybe this Feature should even include placing orders in the first place.
Givens are things that are true before the time period that the scenario is about, like the existence of the customer and the order. Actions during the scenario belong in Whens.
It's good to avoid UI detail like "click" and specific button names and "displayed on the screen". The scenario should focus on behavior. The When I go to the order step can encapsulate the details of going to the screen where you enter the number, entering the number, and clicking the button.
Likewise, all of the checks for different fields of the order that should be visible can be encapsulated in Then I should see the order.
I said "the order" rather than "my order" because And I have an order establishes that there's a single order with a special relationship with the scenario, and it's good to establish a language across all your scenarios that makes that relationship clear -- I always use "the" in that case. (This is a very small point.)

With those stylistic points taken care of, this is an OK scenario and I've certainly written many similar ones. To get to your real question, however:

Where Specflow-type tools really shine is when you use them to describe as complete a use case/user story as you can. For example:

  Scenario:
    Given I am a customer
    And there is a product

    When I go to the product page
    Then I should see the product

    When I add the product to my cart
    And I check out
    Then I should see that the order has been placed
    And I should receive an order confirmation email

    When I go to my orders
    Then I should see the order listed

    When I go to the order
    Then I should see the order

    When I cancel the order
    Then I should see that the order has been cancelled
    And I should receive an order cancellation email

    When I go to my orders
    Then I should not see the order listed

This is more valuable as an acceptance test, because it captures more requirements, and it's more powerful as an integration test, because it exercises more of the system, and fakes less of it. (In the short scenario we had to create an order artificially. Here we're doing it through the system.)