---
title: The blank box is a systems problem
description: "One text box, a billion different intents. OpenAI's head of design calls it the blank box problem. Not a case for a new interface. A case for a design system where the model does the assembling. With a working demo."
date: 2026-08-26
tags: [ai, design, design-systems, interfaces]
url: "https://mahdif.com/blog/the-blank-box-is-a-systems-problem/"
---

# The blank box is a systems problem

One text box, a billion different intents. OpenAI's head of design calls it the blank box problem. Not a case for a new interface. A case for a design system where the model does the assembling. With a working demo.

I have designed interfaces for 17 years. Screens that tell you what you can do here. Buttons, menus, empty states. The whole craft rests on one assumption: the product knows what you came for.

Recently I listened to Ian Silber, the head of product design at OpenAI, describe the problem that breaks that assumption [on Lenny's Podcast](https://www.lennysnewsletter.com/p/openais-head-of-design-this-is-the). One text box serves a person asking about a rash on their finger and a person building a Salesforce. He called designing for it uncharted territory, and he is right.

I have been circling this problem from a few directions. At Ava we built one captioning product that deaf and hearing people used inside the same live conversation, with completely different needs. At Meta I watched the same ads tools serve a food truck owner and a professional media buyer. And for the past two years I have been building with AI agents daily, which mostly means watching a chat interface try to be everything at once. This post is my answer to the blank box, with a working demo you can poke at along the way. Not a hot take.

## The two wrong answers

Chat gets called a glorified terminal, and the critique usually comes with a proposed fix. The fixes land in one of two places.

The first is the brand new paradigm. Canvases, node graphs, spatial interfaces. Fun to prototype, and every one of them serves a slice of intents beautifully and abandons the rest. Any fixed interface picks a lane. The blank box's whole job is refusing to pick one.

The second is piling controls onto chat. Toolbars, modes, pickers, settings. This one fails slower but fails worse, because every control taxes the person who came in with the simplest question. Ian says things become for billions of users when there is no switch or mode to think about. I think he is understating it. The controls are the tax, not the feature.

## Writing blocks are the tell

Buried in that same interview is the thing I think matters most, and it goes by fast.

Ian describes what his team calls writing blocks. Ask ChatGPT for an email and the reply arrives with the email inside an editable block. You manipulate it directly, copy just that part, rework a sentence without touching the rest.

It is easy to file that as a feature. I think it is a tell. Look at what actually happened: the model recognized an intent, and a piece of purpose-built UI got composed into the response. Nobody opened an email tool. The interface came to the intent.

Here is that idea made visible. This is a live sketch, not a screenshot. The dashed outlines are an x-ray of the response: each labeled part is a reusable system piece, not a bespoke screen.

<figure style="margin:2.75rem 0;" data-wide><iframe src="/demos/response-kit/?embed=1&amp;q=1&amp;xray=1&amp;chrome=0" scrolling="no" style="width:100%;height:var(--rk-h0,790px);border:0;overflow:hidden;" title="An email response decomposed into system primitives" loading="lazy"></iframe><figcaption>The email answer, decomposed. Two primitives: prose, then a work block you can actually edit.</figcaption></figure>

There is already a name for a small set of purpose-built parts that compose into whatever the situation needs. A design system. The blank box does not need a new interface. It needs a design system where the model is the layout engine.

## Five primitives, one rule

My sketch of the kit, and it is deliberately small. I would be surprised if teams inside OpenAI are not already several steps past it. The value of naming the pattern is that the rest of us get to design with it too.

**Prose.** Plain text. The default, and the right answer more often than designers want to admit.

**Clarify chips.** Tap-to-answer questions when the intent is ambiguous.

**Work block.** Writing blocks generalized to any artifact you edit directly.

**Data block.** A table and a small chart when the answer is numbers.

**Plan block.** A stepper for anything multi-step. Check off a step, expand it, hand one back to the model.

The rule that holds it together: the primitives stay few, dumb, and consistent, and the model does the assembling. Cohesion does not come from designing every screen. It comes from the kit being small enough that any composition still feels like one product.

## The density dial

The second half of the problem is not what to render but how much.

At Ava this was the job every day. In the same conversation, the deaf user needed the caption stream front and center with speaker labels and correction controls. The hearing user needed almost nothing. Same data, same moment, radically different density. We learned to treat density as a property of the person, not of the screen.

The blank box needs the same move. Below, the same data answer rendered for a daily power user: the table grew sorting, copy, and keyboard affordances instead of growing screens. A novice gets the identical primitive with the controls folded away.

<figure style="margin:2.75rem 0;" data-wide><iframe src="/demos/response-kit/?embed=1&amp;q=2&amp;density=pow&amp;chrome=0" scrolling="no" style="width:100%;height:var(--rk-h1,790px);border:0;overflow:hidden;" title="The data answer at power-user density" loading="lazy"></iframe><figcaption>One kit, turned up. Power density grows affordances, not screens.</figcaption></figure>

## Try the whole thing

Here is the full sketch. Four intents from Ian's exact spectrum, five primitives, and the two switches that carry the argument: flip the x-ray to see every response decompose into named system parts, then flip Novice to Power and watch the same answers change density.

<figure style="margin:2.75rem 0;" data-wide><iframe src="/demos/response-kit/?embed=1" scrolling="no" style="width:100%;height:var(--rk-h2,860px);border:0;overflow:hidden;" title="Response Kit, the full interactive demo" loading="lazy"></iframe><figcaption>Response Kit. Everything is clickable; the content is canned on purpose. Also at <a href="/demos/response-kit/">mahdif.com/demos/response-kit</a>.</figcaption></figure>

It is canned on purpose. There is no model behind it, so it is instant, unbreakable, and honest about what it argues: the interface layer, not the model. I designed and built it with Claude Code in one working session, one dependency-free HTML file.

## Where this breaks

The routing is the whole ballgame, and I have not solved it. A wrong affordance is worse than plain text. Prose that should have been a table is annoying. A stepper that should have been a sentence is insulting. The model has to be right about intent before any of this earns its keep.

Composition also fails in ways nobody designed. Every design system has this problem, but here the layout engine is probabilistic, and "the model produced a layout no designer approved" is a genuinely new failure class.

And there is a tension I have not resolved between shape-shifting and familiarity. Products earn trust by looking the same tomorrow. A response surface that adapts per intent has to earn it another way, and I do not think anyone knows what that way is yet.

## The commission

Designers look at the blank box and see the interface disappearing. Seventeen years of craft dissolving into a text field.

I see the opposite. Somebody has to design the primitives. Somebody has to set the densities and the rules of composition, and decide what the model is allowed to assemble. The blank box is not the end of interface design. It is the largest design system commission ever written.

<script>
(function(){
  function frames(){return [].slice.call(document.querySelectorAll("iframe[src*='response-kit']"));}
  addEventListener("message",function(e){
    if(!e.data||e.data.type!=="rk-height")return;
    frames().forEach(function(f,i){
      if(f.contentWindow===e.source)document.documentElement.style.setProperty("--rk-h"+i,e.data.height+"px");
    });
  });
  function ping(){frames().forEach(function(f){try{f.contentWindow.postMessage({type:"rk-report"},"*");}catch(err){}});}
  if(document.readyState==="complete"){setTimeout(ping,300);}else{addEventListener("load",function(){setTimeout(ping,300);});}
})();
</script>