What this post does for me is that it encourages me to view products and services not as physical facts of our world, as things that happen to exist, but as the outcomes of an active creative process that is still ongoing and open to our participation. It reminds us that everything we might want to do is hard, and that the work of making that task less hard is valuable. Otherwise, we are liable to make the mistake of taking functionality and expertise for granted.
What is not an interface? That’s the slipperiest aspect of this post. A programming language is an interface to machine code, a programmer to the language, a company to the programmer, a liaison to the company, a department to the liaison, a chain of command to the department, a stock to the chain of command, an index fund to the stock, an app to the index fund. Matter itself is an interface. An iron bar is an interface to iron. An aliquot is an interface to a chemical. A fruit is an interface, translating between the structure of a chloroplast and the structure of things-animals-can-eat. A janitor is an interface to brooms and buckets, the layout of the building, and other considerations bearing on the task of cleaning. We have lots of words in this concept-cluster: tools, products, goods and services, control systems, and now “interfaces.”
“As a scarce resource,” suggests that there are resources that are not interfaces. After all, the implied value prop of this post is that it’s suggesting a high-value area for economic activity. But if all economic activity is interface design, then a more accurate title is “Scarce Resources as Interfaces,” or “Goods Are Hard To Make And Services Are Hard To Do.”
The value I get out of this post is that it shifts my thinking about a tool or service away from the mechanism, and toward the value prop. It’s also a useful reminder for an early-career professional that their value prop is making a complex system easier to use for somebody else, rather than ticking the boxes of their course of schooling or acquiring line items on their resume. There are lots of ways to lose one’s purpose, especially if it’s not crystal clear. This post does a good job of framing jobs not as a series of tasks you do, or an identity you have, but as an attempt to make a certain outcome easier to achieve for your client. It’s fundamentally empathic in a way I find appealing.
What this post does for me is that it encourages me to view products and services not as physical facts of our world, as things that happen to exist, but as the outcomes of an active creative process that is still ongoing and open to our participation. It reminds us that everything we might want to do is hard, and that the work of making that task less hard is valuable. Otherwise, we are liable to make the mistake of taking functionality and expertise for granted.
What is not an interface? That’s the slipperiest aspect of this post. A programming language is an interface to machine code, a programmer to the language, a company to the programmer, a liaison to the company, a department to the liaison, a chain of command to the department, a stock to the chain of command, an index fund to the stock, an app to the index fund. Matter itself is an interface. An iron bar is an interface to iron. An aliquot is an interface to a chemical. A fruit is an interface, translating between the structure of a chloroplast and the structure of things-animals-can-eat. A janitor is an interface to brooms and buckets, the layout of the building, and other considerations bearing on the task of cleaning. We have lots of words in this concept-cluster: tools, products, goods and services, control systems, and now “interfaces.”
“As a scarce resource,” suggests that there are resources that are not interfaces. After all, the implied value prop of this post is that it’s suggesting a high-value area for economic activity. But if all economic activity is interface design, then a more accurate title is “Scarce Resources as Interfaces,” or “Goods Are Hard To Make And Services Are Hard To Do.”
The value I get out of this post is that it shifts my thinking about a tool or service away from the mechanism, and toward the value prop. It’s also a useful reminder for an early-career professional that their value prop is making a complex system easier to use for somebody else, rather than ticking the boxes of their course of schooling or acquiring line items on their resume. There are lots of ways to lose one’s purpose, especially if it’s not crystal clear. This post does a good job of framing jobs not as a series of tasks you do, or an identity you have, but as an attempt to make a certain outcome easier to achieve for your client. It’s fundamentally empathic in a way I find appealing.