I think this can apply not just to UI design, but also API design: identify the forces between your and a client's infrastructure (or between different components of your own stuff), and boil it down to the simplest API (endpoints or functions, etc.) to facilitate those (real-world) forces / needs. And reevaluate for fit-ness. The main difference between UI and API is mechanism; it's still the interaction boundary, and should be the thing you get right first for the right reasons governed by the outer context; and then everything else is just the stuff that makes that interface actually work.