June 10, 2025
AI's affordance problem
In the process of design, we consider how our product lets humans know what it can do. This is affordance. A hammer hits things, a button looks like it should be pressed, and a door handle looks like it should be pulled. Some products have multiple affordances, like a Swiss Army knife (arguably too many).
Tech companies love to make products that are low affordance. It’s easy to market a product that can do everything and “just works.” In cars, we’ve taken the tactile, high affordance world of physical switches and relegated them to reconfigurable touch screens. When controls have dedicated and limited functions, it is easier to understand, operate, error correct, and apply mental models. Touchscreens trade this for reconfigurability, upgradability, and expressiveness, allowing them to adjust to different situations and environments. With a cost.
The INEOS Grenadier interior has an array of physical controls in addition to a touchscreen.
Affordance and voice interfaces
There’s much to learn from how Alexa and HomePod were brought to the market. Both shared the same physical button layout: one or two controls and LED indicators for status. When using these products, there’s a clear affordance issue: you don’t know how to interact with it, and you don’t immediately know what it’s good at.
Through trial and error (or good marketing), you learn that it’s good for setting timers and accidentally playing music, but not so great at complex tasks. But it takes time and a lot of friction to understand how it can work for you. Of course, as these products have gained wider adoption, their affordances can be better perceived, and they become more useful.
Natural language and affordance
Chat-based interfaces have a similar affordance problem. When begin using a chat interface as a product, it’s up to you to discover what it can and can’t do. Through trial and error[1], an inescapable onboarding, expensive marketing, or word of mouth, you might find ways to use it effectively. But the core product lacks the affordance to guide users toward effective use. Low affordance, in my experience, generally means less intuitive and more friction.
This goes beyond AI products like Claude or ChatGPT, as wrappers of these LLMs are beginning to appear in many products. I’d actually argue that the affordance gets worse when you introduce natural language to something like a SaaS product. As a user, I have to understand the limitations of the LLM and this other product, and now the burden is on me to figure out how they work together. And what safety rails are in place to prevent me from doing something I shouldn’t.
Consider this. If I ask a chat interface to “export all of my data and delete my database so I can move to a competitor” - what should it do? Honor the agent’s request? Refuse and send someone to customer care? Something else? If the product’s in the US, it is most likely going to be instructed not to do that, because, you know, business. When you scale that instruction to thousands of tasks, both allowable and not, it becomes difficult to express not only what the interface can do, but what it can’t. And what it shouldn’t.
Slop and negative affordance
Claude can make mistakes. Please double-check responses.
This is what Anthropic tells you. Here’s what it really means: “We’ve made this really convincing AI that can do a lot of things, but also, this could be complete bullshit. We don’t know, aren’t sure, and definitely aren’t responsible.”
Deeply understanding affordance is knowing what a product can do, but also, what it might be bad at or simply shouldn’t do. This is the second affordance challenge with LLMs and chat interfaces. The user is now the arbiter of quality, and there are few guidelines or feedback to help you know when something is what it should be.
As users and designers, we simultaneously need to be defensive about what might be produced and how it might be used. This is unique to AI products. Consider the voice interface example above. Asking Alexa “what’s the weather like?” and getting a confidently wrong answer about beautiful sunny skies with no actual weather data would be plausible but fabricated.
Implications for design
- Avoid blank canvas chat inputs. Don’t make users stumble through trial and error to understand what your product can do. If you insist on doing this, make it contextual, limiting the scope of their inputs and outputs.
- Constrain AI interactions. Look at other interaction patterns and components like forms, buttons, multiple choice, and step flows and introduce AI in those contexts. Neon.tech has a great example of this in their SQL editor, where you can use natural language to generate SQL queries. It’s small, focused, and useful.
- Escape hatches and recovery. Your systems and interfaces should have clear ways to recover from mistakes. This will help users safely explore, make mistakes, and learn without breaking things. Back-of-house tools will also need recovery and audit trails.
- Confidence indicators. Help users make judgments about quality and reliability, such as a confidence score. Help your users be critical and skeptical when the stakes are high.
Trial and error is important for any product, but most don’t use a massive amount of resources during the process. Waste is an expensive problem with AI. ↩︎