When designing a product of any kind essentially it boils down to a certain set of scenario problems and the logic involved in fixes them. 

This is called Business logic.

Sometimes the people fixing the problem as vastly removed from the users with the problem. This is where Gherkin syntax comes in. 

Ignore the stupid name if you can. This way of writing out scenarios really is beneficial. You explain where the problem happens, then what happens and then explain the solution you want to happen. This simple breakdown means that it can then be passed to your team and they'll have a clearly defined spec to work with.

If that doesn't quite make sense, read some of the clear examples in the following article. It makes the difficult to understand really simple.