what is an alternative way to use instead of id in gherkin?

I am writing some user stories. I know I can use pesona instead of an Id which is not undrestandable for nontechnical persons. Consider following example:

    Given I want to add "Alex" as user with Password "123" and description "blahblahblah"
    When I register "Alex"
    Then I should see "Alex" in the list of users with password "123 and with description "blahblahblah"

It is understandable but how Can I find "Alex" without a specific Id during acceptance tests?

If I use following scenario, It might not be understandable in one go and also for nontechnical people?

Given I have "Alex" data as following:
  | Name | Password | Description  |
  | Alex | 123      | blahblahblah |
When I register "Alex" as user
Then users must be as following:
  | Id | Name | Password | Description  |
  | 1  | Alex | 123      | blahblahblah |

What is the best way to be used instead of Id to be understandable for nontechnical and also be testable?

Solution

Consider the following, which may be a little more effective, though more verbose.

Given I am at registration
When I provide a name of Alex
   And I provide a password of 123
   And I provide a description of blahblahblah
   And I register the user
Then the registered user should have a username of Alex
   And the registered user should have a password of 123
   And the registered user should have a description of blahblahblah

Some notes on reasons for my suggestion:

I grouped the when statements together as a logical action. I'm less concerned with having all of that in the given, especially if it's not as clear.
Behind the scenes, this should make your objects easy to set up - you can map the steps to setting values on local fields or a context.
I use "the registered user" because it strikes me as a "behind the scenes" detail for your users, especially if you're trying to avoid showing ID. In your step files, you can be looking for an ID of 1, but it doesn't seem like being the first/only user is specifically a part of this test.

If you prefer a table for the example data to show people, you could still parameterize the test:

Scenario Outline: My Scenario
    Given I am at registration
    When I provide a name of <usersName>
       And I provide a password of <password>
       And I provide a description of <description>
       And I register the user
    Then the registered user should have a username of <usersName>
       And the registered user should have a password of <password>
       And the registered user should have a description of <description>

Examples:

| <usersName> | <password> | <description> |
| Alex        | 123        | blahblahblah  |

Though I'm not sure I'd recommend it in this specific case, as to me it seems less explicitly readable in that format.

⚠ Side note: I think this is likely just an example, but please ensure you are not storing passwords in plaintext.