How does thinking about interfaces as 'behaviours, not data' guide better design?

// Behaviour-based (Go idiomatic)
type Logger interface { Log(msg string) }         // what it does
type Notifier interface { Notify(event Event) }   // what it does
type Closer interface { Close() error }           // what it does

// Data/entity-based (anti-pattern in Go)
type IUserRepository interface {  // describes a whole entity
    FindByID(id int) (*User, error)
    FindByEmail(email string) (*User, error)
    Save(u *User) error
    Delete(id int) error
    Count() int
}
// Problem: every consumer is forced to implement or mock ALL 5 methods
// even if they only need FindByID

// Better: define the minimum interface in the consumer
// package email — only needs to look up users
type UserLookup interface { FindByEmail(string) (*User, error) }

// package reporting — only needs to count
type UserCounter interface { Count() int }

// The concrete *UserRepo satisfies all of the above
// without knowing about any of them

// Naming: prefer -er suffix for single-method interfaces
// io.Reader, io.Writer, io.Closer — the standard library gold standard
// fmt.Stringer, sort.Interface, http.Handler