Every class has an interface : 

* Interfaces may be explicit, like when classes implement some `interface` or conforms to some `protocol`; 
* Interfaces may be implicit: it's what a class defines top be visible from the outside and to be used by other class, hiding the internals.   

You might for example read a lot of advices about the use of interfaces in patterns in the [GoF][1], but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to `interface`), often, just referring to an implicit class. 

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. At least their  implicit interface. The key is to see it as a black-box, i.e. think of it as if someone else could rewrite it and you wouldn't know its internals.   This is not overenginering. It's just OOP. 

You would go for explicit interfaces in the following situations:  

* You find out that a class in your design should be replaceable with equivalent classes. 
* You want to reuse implicit interfaces, or  part of them, potentially with a family of potentially unrelated classes.  
* You want to force yourself to think in terms of abstraction, and use language support for this purpose.   

If you start to get stuck about the granularity of such an explicit interface, wondering if and how and why you might need to segregate it further, then you should take a deep breath, and just go on with a first version of your new interface, and if needed refactor later.    

  [1]: https://en.wikipedia.org/wiki/Design_Patterns