The answer to the question of why your users would want to use your code could be long and varied. If it is, you might want to go back and re-read the SRP section. Beyond being able to split the code into smaller, more concise chunks, we need to make a list. We will apply the 80/20 rule to this list. Typically, 80% of usage comes from 20% of the use cases. Let me put this into perspective with an example.
Consider an automated teller machine (ATM). A list of its use cases might look like the following:
Withdraw money
Deposit money
Check balance
Change PIN code
Transfer money
Deposit check
I reckon that on at least 80% of the occasions that a person uses an ATM, their purpose is to withdraw money. So what can we do with this information? We can optimize the interface to make the most common use cases as convenient as possible. In the case of the ATM, it could be as simple as putting the withdraw function on the first screen at the top so that users don't have to search for it. Now that we understand what our users are trying to achieve, we can build on this and consider how they expect to use it.