There's a qualitative difference when you wire up feedback before you up front.
Avoid toy examples, use meaningful use cases to direct your design.
Design for concrete use cases, and drive changes through feedback from concrete use cases. Legal standing. Better to do it right than to do it right now Evan's concept from the Elm philosophy. If you don't have a motivating use case, then wait. Extract APIs from real world code. It's okay for there to be duplication. Premature abstraction is the root of all evil. sSmplicity is the best thing you can do to anticipate future API design needs.
Come up with an API with the most benefits and the least pain points.
If there's something that you want to make really good, invest in giving it a good feedback mechanism.