Interfaces as a Scarce Resource


  • The first three sec­tions (Don Nor­man’s Fridge, In­ter­face De­sign, and When And Why Is It Hard?) cover what we mean by “in­ter­face”, what it looks like for in­ter­faces to be scarce, and the kinds of ar­eas where they tend to be scarce.

  • The next four sec­tions ap­ply these ideas to var­i­ous top­ics:

    • Why AR is much more difficult than VR

    • AI al­ign­ment from an in­ter­face-de­sign perspective

    • Good in­ter­faces as a key bot­tle­neck to cre­ation of markets

    • Cross-de­part­ment in­ter­faces in organizations

Don Nor­man’s Fridge

Don Nor­man (known for pop­u­lariz­ing the term “af­for­dance” in The De­sign of Every­day Things) offers a story about the tem­per­a­ture con­trols on his old fridge:

I used to own an or­di­nary, two-com­part­ment re­friger­a­tor—noth­ing very fancy about it. The prob­lem was that I couldn’t set the tem­per­a­ture prop­erly. There were only two things to do: ad­just the tem­per­a­ture of the freezer com­part­ment and ad­just the tem­per­a­ture of the fresh food com­part­ment. And there were two con­trols, one la­beled “freezer”, the other “re­friger­a­tor”. What’s the prob­lem?
Oh, per­haps I’d bet­ter warn you. The two con­trols are not in­de­pen­dent. The freezer con­trol also af­fects the fresh food tem­per­a­ture, and the fresh food con­trol also af­fects the freezer.

The nat­u­ral hu­man model of the re­friger­a­tor is: there’s two com­part­ments, and we want to con­trol their tem­per­a­tures in­de­pen­dently. Yet the fridge, ap­par­ently, does not work like that. Why not? Nor­man:

In fact, there is only one ther­mo­stat and only one cool­ing mechanism. One con­trol ad­justs the ther­mo­stat set­ting, the other the rel­a­tive pro­por­tion of cold air sent to each of the two com­part­ments of the re­friger­a­tor.

It’s not hard to imag­ine why this would be a good de­sign for a cheap fridge: it re­quires only one cool­ing mechanism and only one ther­mo­stat. Re­sources are saved by not du­pli­cat­ing com­po­nents—at the cost of con­fused cus­tomers.

The root prob­lem in this sce­nario is a mis­match be­tween the struc­ture of the ma­chine (one ther­mo­stat, ad­justable al­lo­ca­tion of cool­ing power) and the struc­ture of what-hu­mans-want (in­de­pen­dent tem­per­a­ture con­trol of two com­part­ments). In or­der to al­ign the be­hav­ior of the fridge with the be­hav­ior hu­mans want, some­body, at some point, needs to do the work of trans­lat­ing be­tween the two struc­tures. In Nor­man’s fridge ex­am­ple, the trans­la­tion is botched, and con­fu­sion re­sults.

We’ll call what­ever method/​tool is used for trans­lat­ing be­tween struc­tures an in­ter­face. Creat­ing good meth­ods/​tools for trans­lat­ing be­tween struc­tures, then, is in­ter­face de­sign.

In­ter­face Design

In pro­gram­ming, the analo­gous prob­lem is API de­sign: tak­ing what­ever data struc­tures are used by a soft­ware tool in­ter­nally, and figur­ing out how to pre­sent them to ex­ter­nal pro­gram­mers in a use­ful, in­tel­ligible way. If there’s a mis­match be­tween the in­ter­nal struc­ture of the sys­tem and the struc­ture of what-users-want, then it’s the API de­signer’s job to trans­late. A “good” API is one which han­dles the trans­la­tion well.

User in­ter­face de­sign is a more gen­eral ver­sion of the same prob­lem: take what­ever struc­tures are used by a tool in­ter­nally, and figure out how to pre­sent them to ex­ter­nal users in a use­ful, in­tel­ligible way. Con­cep­tu­ally, the only differ­ence from API de­sign is that we no longer as­sume our users are pro­gram­mers in­ter­act­ing with the tool via code. We de­sign the in­ter­face to fit how­ever peo­ple use it—that could mean han­dles on doors, or but­tons and icons in a mo­bile app, or the tem­per­a­ture knobs on a fridge.

Eco­nom­i­cally, in­ter­face de­sign is a nec­es­sary in­put to make all sorts of things eco­nom­i­cally use­ful. How scarce is that in­put? How much are peo­ple will­ing to spend for good in­ter­face de­sign?

My im­pres­sion is: a lot. There’s an en­tire cat­e­gory of tech com­pa­nies whose busi­ness model is:

  • Find a soft­ware tool or database which is very use­ful but has a bad interface

  • Build a bet­ter in­ter­face to the same tool/​database

  • Profit

This is an es­pe­cially com­mon pat­tern among small but prof­itable soft­ware com­pa­nies; it’s the sort of thing where a small team can build a tool and then lock in a small num­ber of very loyal high-pay­ing users. It’s a good value prop—you go to peo­ple or busi­nesses who need to use X, but find it a huge pain, and say “here, this will make it much eas­ier to use X”. Some ex­am­ples:

  • Com­pa­nies which in­ter­face to gov­ern­ment sys­tems to provide tax ser­vices, travel visas, patent­ing, or busi­ness licensing

  • Com­pa­nies which set up web­sites, Sales­force, cor­po­rate struc­ture, HR ser­vices, or ship­ping lo­gis­tics for small busi­ness own­ers with lit­tle rele­vant expertise

  • Com­pa­nies which provide graph­i­cal in­ter­faces for data, e.g. web­site traf­fic, sales fun­nels, gov­ern­ment con­tracts, or mar­ket fundamentals

Even big­ger ex­am­ples can be found out­side of tech, where hu­mans them­selves serve as an in­ter­face. En­tire in­dus­tries con­sist of peo­ple serv­ing as in­ter­faces.

What does this look like? It’s the en­tire in­dus­try of tax ac­coun­tants, or con­tract law, or lob­by­ing. It’s any in­dus­try where you could just do it your­self in prin­ci­ple, but the sys­tem is com­pli­cated and con­fus­ing, so it’s use­ful to have an ex­pert around to trans­late the things-you-want into the struc­ture of the sys­tem.

In some sense, the en­tire field of soft­ware en­g­ineer­ing is an ex­am­ple. A soft­ware en­g­ineer’s pri­mary job is to trans­late the things-hu­mans-want into a lan­guage un­der­stand­able by com­put­ers. Peo­ple use soft­ware en­g­ineers be­cause talk­ing to the en­g­ineer (difficult though that may be) is an eas­ier in­ter­face than an empty file in Jupyter.

Th­ese are not cheap in­dus­tries. Lawyers, ac­coun­tants, lob­by­ists, pro­gram­mers… these are ex­perts in com­pli­cated sys­tems, and they get paid ac­cord­ingly. The world spends large amounts of re­sources us­ing peo­ple as in­ter­faces—in­di­cat­ing that these kinds of in­ter­faces are a very scarce re­source.

When And Why Is It Hard?

Don Nor­man’s work is full of in­ter­est­ing ex­am­ples and gen­eral tech­niques for ac­cu­rately com­mu­ni­cat­ing the in­ter­nal struc­ture of a tool to users—the clas­sic ex­am­ple is “han­dle means pull, flat plate means push” on a door. At this point, I think (at least some) peo­ple have a pretty good un­der­stand­ing of these tech­niques, and they’re spread­ing over time. But ac­cu­rate com­mu­ni­ca­tion of a sys­tem’s in­ter­nal struc­ture is only use­ful if the sys­tem’s in­ter­nal struc­ture is it­self pretty sim­ple—like a door or a fridge. If I want to, say, write a con­tract, then I need to in­ter­face to the sys­tem of con­tract law; ac­cu­rately com­mu­ni­cat­ing that struc­ture would take a whole book, even just to sum­ma­rize key pieces.

There are lots of sys­tems which are sim­ple enough that ac­cu­rate com­mu­ni­ca­tion is the bulk of the prob­lem of in­ter­face de­sign—this in­cludes most ev­ery­day ob­jects (like fridges), as well as most web­sites or mo­bile apps.

But the places where we see ex­pen­sive in­dus­tries pro­vid­ing in­ter­faces—like law or soft­ware—are usu­ally the cases where the un­der­ly­ing sys­tem is more com­plex. Th­ese are cases where the struc­ture of what-hu­mans-want is very differ­ent from the sys­tem’s struc­ture, and trans­lat­ing be­tween the two re­quires study and prac­tice. Ac­cu­rate com­mu­ni­ca­tion of the sys­tem’s in­ter­nal struc­ture is not enough to make the prob­lem easy.

In other words: in­ter­faces to com­plex sys­tems are es­pe­cially scarce. This eco­nomic con­straint is very taut, across a num­ber of differ­ent ar­eas. We see en­tire in­dus­tries—large in­dus­tries—whose main pur­pose is to provide non-ex­pert hu­mans with an in­ter­face to a par­tic­u­lar com­plex sys­tem.

Given that in­ter­faces to com­plex sys­tems are a scarce re­source in gen­eral, what other pre­dic­tions would we make? What else would we ex­pect to be hard/​ex­pen­sive, as a re­sult of in­ter­faces to com­plex sys­tems be­ing hard/​ex­pen­sive?

AR vs VR

By the stan­dards of soft­ware en­g­ineer­ing, pretty much any­thing in the real world is com­plex. In­ter­fac­ing to the real world means we don’t get to choose the on­tol­ogy—we can make up a bunch of ob­ject types and data struc­tures, but the real world will not con­sider it­self obli­gated to fol­low them. The in­ter­nal struc­ture of com­put­ers or pro­gram­ming lan­guages is rarely a perfect match to the struc­ture of the real world.

In­ter­fac­ing the real world to com­put­ers, then, is an area we’d ex­pect to be difficult and ex­pen­sive.

Aug­mented re­al­ity (AR) is one area where I ex­pect this to be keenly felt, es­pe­cially com­pared to VR. I ex­pect AR ap­pli­ca­tions to lag dra­mat­i­cally be­hind full vir­tual re­al­ity, in terms of both adop­tion and product qual­ity. I ex­pect AR will mostly be used in sta­ble, con­trol­led en­vi­ron­ments—e.g. fac­tory floors or es­cape-room-style on-lo­ca­tion games.

Why is in­ter­fac­ing soft­ware with the real world hard? Some stan­dard an­swers:

  • The real world is com­pli­cated. This is a cop-out an­swer which doesn’t ac­tu­ally ex­plain any­thing.

  • The real world has lots of edge cases. This is also a cop-out, but more sub­tly; the real world will only seem to be full of edge cases if our pro­gram’s on­tolo­gies don’t line up well with re­al­ity. The real ques­tion: why is it hard to make our on­tolo­gies line up well with re­al­ity?

Some more in­ter­est­ing an­swers:

  • The real world isn’t im­ple­mented in Python. To the ex­tent that the real world has a lan­guage, that lan­guage is math. As soft­ware needs to in­ter­face more with the real world, it’s go­ing to re­quire more math—as we see in data sci­ence, for in­stance—and not all of that math will be easy to black-box and hide be­hind an API.

  • The real world is only par­tially ob­serv­able—even with ubiquitous sen­sors, we can’t query any­thing any­time the way we can with e.g. a database. Ex­plic­itly mod­el­ling things we can’t di­rectly ob­serve will be­come more im­por­tant over time, which means more re­li­ance on prob­a­bil­ity and ML tools (though I don’t think black-box meth­ods or “pro­gram­ming by ex­am­ple” will ex­pand be­yond niche ap­pli­ca­tions).

  • We need enough com­pute to ac­tu­ally run all that math. In prac­tice, I think this con­straint is less taut than it first seems—we should gen­er­ally be able to perform at least as well as a hu­man with­out brute-forc­ing ex­po­nen­tially hard prob­lems. That said, we do still need effi­cient al­gorithms.

  • The real-world things we are in­ter­ested in are ab­stract, high-level ob­jects. At this point, we don’t even have the math­e­mat­i­cal tools to work with these kinds of fuzzy ab­strac­tions.

  • We don’t di­rectly con­trol the real world. Vir­tual wor­lds can be built to satisfy var­i­ous as­sump­tions by de­sign; the real world can’t.

  • Com­bin­ing the pre­vi­ous points: we don’t have good ways to rep­re­sent our mod­els of the real world, or to de­scribe what we want in the real world.

  • Soft­ware en­g­ineers are mostly pretty bad at de­scribing what they want and build­ing on­tolo­gies which line up with the real world. Th­ese are hard skills to de­velop, and few pro­gram­mers ex­plic­itly re­al­ize that they need to de­velop them.


Con­tin­u­ing the dis­cus­sion from the pre­vi­ous sec­tion, let’s take the same prob­lems in a differ­ent di­rec­tion. We said that trans­lat­ing what-hu­mans-want-in-the-real-world into a lan­guage us­able by com­put­ers is hard/​ex­pen­sive. That’s ba­si­cally the AI al­ign­ment prob­lem. Does the in­ter­faces-as-scarce-re­source view lend any in­ter­est­ing in­sight there?

First, this view im­me­di­ately sug­gests some sim­ple analogues for the AI al­ign­ment prob­lem. The “Nor­man’s fridge al­ign­ment prob­lem” is one—it’s sur­pris­ingly difficult to get a fridge to do what we want, when the in­ter­nal struc­ture of the fridge doesn’t match the struc­ture of what we want. Now con­sider the in­ter­nal struc­ture of, say, a neu­ral net­work—how well does that match the struc­ture of what we want? It’s not hard to imag­ine that a neu­ral net­work would run into a billion-times-more-difficult ver­sion of the fridge al­ign­ment prob­lem.

Another analogue is the “Ethereum al­ign­ment prob­lem”: we can code up a smart con­tract to give mon­e­tary re­wards for any­thing our code can rec­og­nize. Yet it’s still difficult to spec­ify a con­tract for ex­actly the things we ac­tu­ally want. This is es­sen­tially the AI al­ign­ment prob­lem, ex­cept we use a mar­ket in place of an ML-based pre­dic­tor/​op­ti­mizer. One in­ter­est­ing corol­lary of the anal­ogy: there are already eco­nomic in­cen­tives to find ways of al­ign­ing a generic pre­dic­tor/​op­ti­mizer. That’s ex­actly the prob­lem faced by smart con­tract writ­ers, and by other kinds of con­tract writ­ers/​is­suers in the econ­omy. How strong are those in­cen­tives? What do the re­wards for suc­cess look like—are smart con­tracts only a small part of the econ­omy be­cause the re­wards are mea­ger, or be­cause the prob­lems are hard? More dis­cus­sion of the topic in the next sec­tion.

Mov­ing away from analogues of al­ign­ment, what about al­ign­ment paths/​strate­gies?

I think there’s a plau­si­ble (though not very prob­a­ble) path to gen­eral ar­tifi­cial in­tel­li­gence in which:

  • We figure out var­i­ous core the­o­ret­i­cal prob­lems, e.g. ab­strac­tion, poin­t­ers to val­ues, em­bed­ded de­ci­sion the­ory, …

  • The key the­o­ret­i­cal in­sights are in­cor­po­rated into new pro­gram­ming lan­guages and frameworks

  • Pro­gram­mers can more eas­ily trans­late what-they-want-in-the-real-world into code, and make/​use mod­els of the world which bet­ter line up with the struc­ture of reality

  • … and this cre­ates a smooth-ish path of steadily-more-pow­er­ful declar­a­tive pro­gram­ming tools which even­tu­ally leads to full AGI

To be clear, I don’t see a com­plete roadmap yet for this path; the list of the­o­ret­i­cal prob­lems is not com­plete, and a lot of progress would be needed in non-agenty math­e­mat­i­cal mod­el­ling as well. But even if this path isn’t smooth or doesn’t run all the way to AGI, I definitely see a lot of eco­nomic pres­sure for this sort of thing. We are eco­nom­i­cally bot­tle­necked on our abil­ity to de­scribe what we want to com­put­ers, and any­thing which re­laxes that bot­tle­neck will be very valuable.

Mar­kets and Contractability

The pre­vi­ous sec­tion men­tioned the Ethereum al­ign­ment prob­lem: we can code up a smart con­tract to give mon­e­tary re­wards for any­thing our code can rec­og­nize, yet it’s still difficult to spec­ify a con­tract for ex­actly the things we ac­tu­ally want. More gen­er­ally, it’s hard to cre­ate con­tracts which spec­ify what we want well enough that they can’t be gamed.

(Defi­ni­tional note: I’m us­ing “con­tract” here in the broad sense, in­clud­ing pretty much any ar­range­ment for eco­nomic trans­ac­tions—e.g. by eat­ing in a restau­rant you im­plic­itly agree to pay the bill later, or boxes in a store im­plic­itly agree to con­tain what they say on the box. At least in the US, these kinds of con­tracts are legally bind­ing, and we can sue if they’re bro­ken.)

A full dis­cus­sion of con­tract speci­fi­ca­tion goes way be­yond in­ter­faces—it’s ba­si­cally the whole field of con­tract the­ory and mechanism de­sign, and en­com­passes things like ad­verse se­lec­tion, sig­nal­ling, moral haz­ard, in­com­plete con­tracts, and so forth. All of these are tech­niques and bar­ri­ers to writ­ing a con­tract when we can’t spec­ify ex­actly what we want. But why can’t we spec­ify ex­actly what we want in the first place? And what hap­pens when we can?

Here’s a good ex­am­ple where we can spec­ify ex­actly what we want: buy­ing gasoline. The product is very stan­dard­ized, the mea­sures (liters or gal­lons) are very stan­dard­ized, so it’s very easy to say “I’m buy­ing X liters of type Y gas at time and place Z”—ex­ist­ing stan­dards will fill in the re­main­ing am­bi­guity. That’s a case where the struc­ture of the real world is not too far off from the struc­ture of what-we-want—there’s a nice clean in­ter­face. Not co­in­ci­den­tally, this product has a very liquid mar­ket: many buy­ers/​sel­l­ers com­pet­ing over price of a stan­dard­ized good. Stan­dard effi­cient-mar­ket eco­nomics mostly works.

On the other end of the spec­trum, here’s an ex­am­ple where it’s very hard to spec­ify ex­actly what we want: em­ploy­ing peo­ple for in­tel­lec­tual work. It’s hard to out­source ex­per­tise—of­ten, a non-ex­pert doesn’t even know how to tell a job well done from sloppy work. This is a nat­u­ral con­se­quence of us­ing an ex­pert as an in­ter­face to a com­pli­cated sys­tem. As a re­sult, it’s hard to stan­dard­ize prod­ucts, and there’s not a very liquid mar­ket. Rather than effi­cient mar­kets, we have to fall back on the tools of con­tract the­ory and mechanism de­sign—we need ways of ver­ify­ing that the job is done well with­out be­ing able to just spec­ify ex­actly what we want.

In the worst case, the tools of con­tract the­ory are in­suffi­cient, and we may not be able to form a con­tract at all. The lemon prob­lem is an ex­am­ple: a sel­ler may have a good used car, and a buyer may want to buy a good used car, but there’s no (cheap) way for the sel­ler to prove to the buyer that the car isn’t a lemon—so there’s no trans­ac­tion. If we could fully spec­ify ev­ery­thing the buyer wants from the car, and the sel­ler could visi­bly ver­ify that ev­ery box is checked, cheaply and effi­ciently, then this wouldn’t be an is­sue.

The up­shot of all this is that good in­ter­faces—tools for trans­lat­ing the struc­ture of the real world into the struc­ture of what-we-want, and vice versa—en­able effi­cient mar­kets. They en­able buy­ing and sel­l­ing with min­i­mal over­head, and they avoid the ex­pense and com­plex­ity of con­tract-the­o­retic tools.

Create a good in­ter­face for spec­i­fy­ing what-peo­ple-want within some do­main, and you’re most of the way to cre­at­ing a mar­ket.

In­ter­faces in Organizations

Ac­cu­rately com­mu­ni­cat­ing what we want is hard. Pro­gram­mers and product de­sign­ers are es­pe­cially fa­mil­iar with this:

In­cen­tives are a prob­lem some­times (ob­vi­ously don’t trust ads or sales­peo­ple), but even mostly-earnest com­mu­ni­ca­tors—cus­tomers, pro­ject man­agers, de­sign­ers, en­g­ineers, etc—have a hard time ex­plain­ing things. In gen­eral, peo­ple don’t un­der­stand which as­pects are most rele­vant to other spe­cial­ists, or of­ten even which as­pects are most rele­vant to them­selves. A de­signer will ex­plain to a pro­gram­mer the parts which seem most de­sign-rele­vant; a pro­gram­mer will pay at­ten­tion to the parts which seem most pro­gram­ming-rele­vant.

It’s not just that the struc­ture of what-hu­mans-want doesn’t match the struc­ture of the real world. It’s that the struc­ture of how-hu­man-spe­cial­ists-see-the-world varies be­tween differ­ent spe­cial­ists. When­ever two spe­cial­ists in differ­ent ar­eas need to con­vey what-they-want from one to the other, some­body/​some­thing has to do the work of trans­lat­ing be­tween struc­tures—in other words, we need an in­ter­face.

A par­tic­u­larly poignant ex­am­ple from sev­eral years ago: I over­heard a de­signer and an en­g­ineer dis­cuss a minor change to a web page. It went some­thing like this:

De­signer: “Ok, I want it just like it was be­fore, but put this part at the top.”

Eng­ineer: “Like this?”

De­signer: “No, I don’t want ev­ery­thing else moved down. Just keep ev­ery­thing else where it was, and put this at the top.”

Eng­ineer: “But putting that at the top pushes ev­ery­thing else down.”

De­signer: “It doesn’t need to. Look, just...”

… this went on for about 30 min­utes, with steadily in­creas­ing frus­tra­tion on both sides, and steadily in­creas­ing thump­ing noises from my head hit­ting the desk.

It turned out that the de­signer’s tools built ev­ery­thing from the bot­tom of the page up, while the en­g­ineer’s tools built ev­ery­thing from top down. So from the de­signer’s per­spec­tive, “put this at the top” did not re­quire mov­ing any­thing else. But from the en­g­ineer’s per­spec­tive, “put this at the top” meant ev­ery­thing else had to get pushed down.

Some­body/​some­thing has to do the trans­la­tion work. It’s a two-sided in­ter­face prob­lem.

Han­dling these sorts of prob­lems is a core func­tion for man­agers and for any­one de­cid­ing how to struc­ture an or­ga­ni­za­tion. It may seem silly to need to loop in, say, a pro­ject man­ager for ev­ery con­ver­sa­tion be­tween a de­signer and an en­g­ineer—but if the pro­ject man­ager’s job is to trans­late, then it can be use­ful. Re­mem­ber, the ex­am­ple above was frus­trat­ing, but at least both sides re­al­ized they weren’t com­mu­ni­cat­ing suc­cess­fully—if the dou­ble illu­sion of trans­parency kicks in, prob­lems can crop up with­out any­body even re­al­iz­ing.

This is why, in large or­ga­ni­za­tions, peo­ple who can op­er­ate across de­part­ments are worth their weight in gold. In­ter­faces are a scarce re­source; peo­ple who op­er­ate across de­part­ments can act as hu­man in­ter­faces, trans­lat­ing model-struc­tures be­tween groups.

A great ex­am­ple of this is the 1986 Gold­wa­ter-Ni­chols Act. It was in­tended to fix a lack of com­mu­ni­ca­tion/​co­or­di­na­tion be­tween branches of the US mil­i­tary. The ba­sic idea was sim­ple: no­body could be pro­moted to lieu­tenant or higher with­out first com­plet­ing a “joint mis­sion”, one in which they worked di­rectly with mem­bers of other branches. Peo­ple ca­pa­ble of serv­ing as in­ter­faces be­tween branches were a scarce re­source; Gold­wa­ter-Ni­chols in­tro­duced an in­cen­tive to cre­ate more such peo­ple. Be­fore the bill’s in­tro­duc­tion, top com­man­ders of all branches ar­gued against it; they saw it as con­gres­sional med­dling. But af­ter the first Iraq war, ev­ery one of them tes­tified that it was the best thing to ever hap­pen to the US mil­i­tary.


The struc­ture of things-hu­mans-want does not always match the struc­ture of the real world, or the struc­ture of how-other-hu­mans-see-the-world. When struc­tures don’t match, some­one or some­thing needs to serve as an in­ter­face, trans­lat­ing be­tween the two.

In sim­ple cases, this is just user in­ter­face de­sign—ac­cu­rately com­mu­ni­cat­ing how-the-thing-works to users. But when the sys­tem is more com­pli­cated—like a com­puter or a body of law—we usu­ally need hu­man spe­cial­ists to serve as in­ter­faces. Such peo­ple are ex­pen­sive; in­ter­faces to com­pli­cated sys­tems are a scarce re­source.