AI Affordances
If you’ve driven a car lately, you’ve noticed that they just don’t have that many buttons any more. Instead, most functionality is accessed in nested layers of touch-screen menus. Want to raise the temperature for the rear seats? Tap for the climate menu, tap for rear settings, tap tap tap tap tap to increase it by five degrees.
The main problem is that this poses a road hazard. A secondary issue is that it obscures from the user any clear indication of what the system can do for you. In UI/UX (User Interface/User Experience) speak, the features of such a car have low discoverability because they lack affordances.
Affordances are the characteristics or properties of an object that suggest how it can be used. — What are Affordances?
I’ve been in hotel showers where I struggled longer than I’d care to admit figuring out how to turn the damn thing on. No indication what should be turned, twisted, pulled, or pushed. All sacrificed to “fancy” design.
Which, as always, brings us to AI systems.
When they are purely chat-based, they have no signifiers or affordances hinting at their capabilities: ChatGPT will draw you an image if you ask it to. Claude can’t do that. But you wouldn’t know that from just looking at either of them.
This, in turn, limits the amount of use the typical user (i.e., not a power-user who reads every “top 10 secret prompts to unleash your whatever” article out there) gets out of the tool. That’s mildly annoying for OpenAI, Anthropic, and co, but their tools get enough attention, and are sufficiently embedded in the zeitgeist, that over time everyone “gets it”.
If, on the other hand, you’re building and rolling out a custom tool for an internal workflow to supercharge your team’s capabilities, you need to account for how users will learn about and discover the capabilities. Luckily, you’ve got options
Go full UI
UIs have buttons and other control elements with well-defined and understood behaviour. Buttons are for clicking, toggles are for toggling, and dropdown menus present more options. At their leisure, users can look at everything in the UI and get a full picture of the tool’s capabilities, much like they’d do with a physical system (such as a car that still has traditional buttons…).
If you have buttons, toggles, and menu options for everything you want people to accomplish with your tool, they’ll figure it out.
Document everything
Command-line tools live on the opposite spectrum. They have no affordances whatsoever. You must know which command to type, how to pass in the right options and flags. It’s not there staring at you.
Instead, such tools come with comprehensive documentation about every subcommand and every variation you can use to control the behavior of the program. Check out the Git - Reference if you ever have to escape insomnia.
In the case of an AI tool, you’d want to list concrete examples of all the workflows and queries you built the tool for, explaining any caveats and limitations, the preferred format for passing additional instructions or data, and an explanation of what is (and isn’t) to be expected from the response.
Or something in between
Likely, you’ll combine some affordances in the user interface and comprehensive documentation for the rest. The documentation is there as the ground truth of the tool’s capabilities, and the UI elements facilitate a smooth flow for the everyday use of the tool.
Just don’t hide everything away in a misguided attempt to “simplify”. People want their car buttons back, and they don’t want to go hunting many layers deep to get their work done.
