A well-designed visual interface has lots of the same features as a well-designed programming interface. Just like an API, a visual interface is designed to serve the user. They both strive to provide the user with the simplest solution that solves their problem. They both benefit from frequent refactoring to clean up debt. They're both made by combining many smaller components that do a single thing well into a larger product.
Lots of interface designers already think about their interfaces like programmers think about APIs, they just might not realize it. If you remember only one thing, remember that "interface design" principles aren't limited to visual interfaces.
Brad Frost informs us of a new way of approaching interface design, thinking of in terms of components, instead of the page-based model we've always used. It maps directly to the same idea of components, packagings, modules, or gems in programming.
Ryan Singer's article about component styling is a perfect example of how you need to think about frontend components as more than just pixel-perfect layouts. Just like designing an API, you need to think through the primary use cases and apply sensible defaults to your design, so that the user has less work to do on their end.
In case it wasn't already obvious, the beginning of this excellent article by Matt Gemmell outlines why API design and interface design share so many similarities. An API is an application programming interface after all! And conversely, your visual interfaces can gain a lot from borrowing concepts from API design and programming.
A good example of programming-thinking applied to design is the idea of refactoring, which designers are constantly doing while iterating on an interface. Just like in programming, your goal is to maintain functionality while rejigging the way you achieve that functionality. In programming, your public methods signatures stay the same, but their internals change. In visual design, the functionality of the product stays the same, but the visuals might change slightly to simplify the mental model for the user.
If you take a second to think about refactoring your own interfaces, I'll bet a few optimizations spring to mind. The beautiful thing about thinking in terms of individual, reusable components while designing the visual parts of an interface is that it translates perfectly to the code you'll be writing to build it. When you find the right abstraction everything will just fall into place.
Thinking in terms of small components starts really paying dividends when you re-use their simple APIs across all of your different projects. That's where component(1) comes in, and I implore you to try it out. It makes it absolutely trivial to use components that others have written.