design the interface first

Bravo!

I take that one step further. Design the code that will use the class first, and the interface will, for the most part(*), fall out of the use case provided by that design.

(*) Once the interface has been implemented for the specific, real-world use case, it is often possible to see small changes that can be applied to generalise it for a wider set of use cases, without compromising its effectiveness and efficiency for the one real use case. These are then a no-brainer to adopt.

From my observations, the problem is that far to often people set out to define a class without having some real-world use case to satisfy. The result is that they end up trying to write a generic interface to satisfy all (their) conceived use cases, with the result that they become overburdened with configurability and flexibility and end up being over-engineered and heavy. Carrying the weight of generality that is never exercised. Non-optimal for all use cases.

I don't lay this designer problem at the door of tool-sets like Moose, but it certainly does not discourage it.