When we talk about "interfaces", two things may pop on your head:
Either it is a definition of some methods/attributes your classes must implement or it's about the way some application looks. Both define the same thing: a surface of contact -- how other classes will contact our class or how the users will do actions on the application.
But besides these two aspects, there are more, which people mostly ignore.
Let's start with the most obvious interface we know: UIs. You know, the button the user clicks. It says "Do the thing" and when the user clicks, the application... do the thing.
That's what interfaces are good for: They hide the complexity of "the thing" and abstract the "do". When you click the "Do the thing" button, you don't wonder how that thing works, you just have to wonder about the abstract thing of "the thing that must do".
But UIs are good for another thing: There is a long time saying that UIs are like jokes: If you have to explain, you're doing it wrong.
Another thing about UIs is that they must be clear in their purposes: Some people may still remember when Apple decided that iOS buttons would have no border, just text. What happened is that most people didn't know what could and what could not be tapped, 'cause normal text and buttons didn't look too much apart.
The whole problem is that Apple decided to go full against skeumorphism, the idea that things in computers must look exactly the same as their real counterparts, like a note application having lines and the binding, although none of those are actually necessary in a computer environment.
There is a middle ground for those two: It shouldn't look exactly like whatever abstraction the interface is going for (the binds in a note app, for example), but it mustn't look so far away that one would not recognize after a short time.