The best way of investigating the ways of reducing interface complexity, is to look at the evolution of competitive products in the consumer electronics industry.

For example, my LCD TV, has all the usual options for adjusting color/contrast/brightness etc. of the picture. It also has all the usual setting for sound: base/treble/brightness etc. And all of these options can be accessed and adjusted individually via on screen menus. However, there are also individual buttons for 'sound' & 'picture' which cycle through 4 presets. ('movie','music','speech' & 'user') and ('statndard', 'movie', 'vivid' & 'user') respectively. A dozen or more individual options with their up & down settings reduced to a couple of buttons that are easy to access and quick to change. It works.

There is a similar mechanism in some of the better designed CPAN modules. The whole ':xxx' option mechanism that pre-selects a whole set of imports. Of course, that mechanism can itself be abused because all of the individual elements are also individually exportable, which makes these 'convenience bundles' add to the interface complexity, rather than reducing it.

One of the possibilities to simplify interfaces, especially of OO modules, is to simply not expose all the internal fields. One of the problems with some of the myriad "OO foundation classes" on CPAN, is that they automatically generate setters and getters for every internal field. In most cases, this is the very last thing an OO module needs.

Far too often OO module authors encapsulate their internals, only to substitute 2 interface elements (getter + setter), for each individual element and so increase complexity rather than reducing it.

Alternatively, they will use some real-world metaphore for the underlaying representation as an abstraction that is actually more complex and less inutative than the underlying abstraction. For example, (sorry to pick on the author, but its an example that is fresh in my mind), the whole Thread::Conveyor::* hierarchy wrapped over a simple shared array renders an interface that is far more complex and less intuative than the underlying representation.