*Part 6 of 10 in [Curiosity’s Wager](/curiositys-wager/2026/11/02/start-here).*

Projection is the term I'm using for treating a limited picture of the world as though it adequately captures the situation before us. That picture might be mine, embedded in familiar software or generated by a model. The representation isn't the world itself. One version of projection is imagining that the chatbot interface is what AI is and the limit of what it could become. Using Claude or Codex through chat gives us one arrangement, particular ways of supplying information, receiving outputs, and deciding what happens next. Through APIs, we can remix those inputs and outputs, connect them with other tools, and reshape when and how people encounter them. That doesn't automatically make a better arrangement. But the chatbot we've encountered isn't the limit of what we could build or demand. Projection can also happen at a more particular level, when my picture of someone's work becomes the picture we build into a tool.

We developed a voice-notes feature for our salon and barbershop software. I imagined someone taking notes right after a client left. We put a button on each client’s card for that day: here you can check them out; here you can take notes. But after a client leaves, there may be another client arriving, preparation to do, and other demands on attention. My picture of the available moment didn’t fit the work.

Then I watched our design partner actually use the feature. A couple of days after the appointments, she was recording complicated hair-color formulas from memory. She moved in and out of different client cards to make several notes in a batch. This was a lot of click friction, the same sort of friction she wanted to remove in the first place, which is why we were working with her. There was a depth of knowledge in her practice that my picture of the task hadn't captured. She didn't need to record everything immediately. She was an expert. She also didn't want to keep it all in her memory indefinitely. So we changed the system so she could make one longer recording, referring to multiple clients.

That addressed a mismatch we'd observed. It didn't establish that we now understood everything important about her work. AI, you know, of course helped me prototype quickly and draw on examples of existing software and let me flesh out my own conception of how the work was formed. But familiar patterns can carry assumptions about how work happens. My ability to build the feature hadn't given me her knowledge of the work. What had I assumed?

What had the existing interfaces led me to expect? What did I need to encounter before I could recognize a different possibility? This is a relatively modest example.

You know, a small, not very harmful bias in the system. But it shows why design partnership matters. We need to see the work in action. We need to ask about what we didn't understand and leave room to change what we build. Shared curiosity means letting the encounter revise our picture. It means providing opportunities for such encounters to revise our picture and then the tool. We can bring a proposal without assuming it establishes how someone else's work should be done. We want to continue to work and make attempts at building tools, recognizing that we're building from a position of an incomplete picture.

---

[Series contents](/curiositys-wager/2026/11/02/start-here) · [Previous: Overreliance: what disappears in the handoff?](/curiositys-wager/2026/11/02/overreliance) · [Next: Entitlement: what makes this ours to use?](/curiositys-wager/2026/11/02/entitlement)