BDD Steps: Be specifically unspecific

I just participated in an interesting sprint retrospective meeting where the problem came up that step definitions are sometimes very ambiguous as well as for the human reader as for the JBehave parser.
Here is one typical though virtual example:

Problems of the steps above:

• The Given statement contains information with no value for the customer. The customer is not interested about the username and the password. Thus even with this start it will be hard to understand the complete scenario.
• The first When statement misses important information. Is this a valid or invalid login? When implementing this step developers might as side effect create a new user with these credentials. The next one re-using this step in a story might not know about this side effect.
• The second When statement collides with the first one if you parse parameters. If you are unlucky you even might have two step definitions in your code:
  
  with the effect that it is up to JBehave if the user logs in as "named qwert" or "qwert" depending on which step it has chosen to take.

What we can learn from it is to be specifically unspecific... or to be more precise, apply these rules to your stories:

1. Give every step a value (if not even every single phrase).
   In the first statement it might be better to state either that I logged in as normal user or that I logged in as a specific user I want to reference later in the test.
2. Never specify field values explicitly.
   Actually this refers to the first rule as most of the time the real content of a field is not important. It might be important of what type the input is (alphabetical, numeric, valid login) but most of the time the real input is not important.
3. Be as specific as needed and as unspecific as possible.
   Perhaps the rule with the most problems to decide what is the best approach. It means that you should not be too specific for example by stating "When I fill the username field with username qwert" as perhaps some day your username field disappears and is replaced by a fingerprint scanner. But you should state if the login is valid or invalid and if it is invalid: if it is because the user doesn't exist or because the password is wrong.
   

So the following steps will be easier to understand... even without the context of prior or subsequent steps. And they never state any field value: