Gherkin becomes a maintenance burden when scenarios describe clicks and selectors instead of behavior. Write steps declaratively, in the language of the business, and keep the "how" in code:

• Imperative (brittle): When I type "user@test.com" into "#email" and click "#submit-btn"
• Declarative (stable): When the user signs in with valid credentials

Cucumber's own guidance is that a scenario should still read correctly if the UI were replaced, and that each scenario should describe one behavior. The step definition then delegates to page or component objects, or to an API helper:

When('the user signs in with valid credentials', async function () {
  await this.loginPage.signIn(this.users.standard);
});

A few habits keep the step library small: reuse steps through parameters ({string}, {int}) rather than near-duplicate sentences, keep assertions in Then steps only, and delete steps no scenario uses. If nobody outside the engineering team reads the feature files, weigh whether plain test code would be simpler.

Sources: Cucumber: writing better Gherkin, Cucumber: Example Mapping