Designing for Users, Developers, and Agents

Web3 designers have always served two audiences.

Your dApp interface serves users. Clean UI, intuitive flows, wallet connection, transaction confirmation, portfolio views. You design for the person clicking buttons.

Your API documentation and SDKs serve developers. Technical specs, integration guides, code examples, endpoint references. You design for the person writing code.

Now there's a third audience. And it changes everything.

The Third Audience

AI agents are becoming a primary consumer of your protocol's information. They're parsing your docs to explain your project to users. They're reading your smart contract data to route transactions. They're analyzing your governance proposals to help delegates make decisions. They're pulling your protocol's metadata to display in aggregators, wallets, and portfolio trackers.

These agents don't use your interface. They don't read your docs the way a developer does. They consume structured data, and they form opinions about your protocol based on whatever data they can find.

Right now, for most protocols, that data is a mess. Scattered documentation, inconsistent descriptions, outdated blog posts, and whatever someone wrote in a CoinGecko listing 18 months ago. The agent does its best with what it has. The result: your protocol gets explained wrong, positioned wrong, and described in language that doesn't match your brand.

You didn't design for this audience. But this audience is already consuming your protocol. The question is whether you give them something designed to consume, or let them keep guessing.

What Agent-Experience Design Looks Like

Designing for agents isn't about interfaces. It's about information architecture.

Structured brand data. Your positioning, voice, messaging, and guardrails in agent-parseable formats (YAML, Markdown, JSON). When an agent needs to describe your protocol, it should be able to query a structured file and get the canonical answer, not scrape your homepage and interpret the marketing copy.

Chunked documentation. Your docs broken into discrete, self-contained chunks with metadata tags. Each chunk answers one specific question. An agent retrieving "how does staking work on this protocol" should get a clean, accurate, 400-token explanation, not have to parse a 10,000-word technical document and figure out which section is relevant.

Machine-readable protocol data. On-chain data formatted for agent consumption. Current APRs, pool compositions, governance proposal statuses, risk parameters. Not as a dashboard that agents have to scrape, but as structured data they can query directly.

Retrieval rules. Mappings that tell agents which data to load for which task. An agent explaining your protocol to a new user needs different information than an agent helping a developer integrate your SDK. The retrieval rules route the right data to the right context.

The Shift Nobody's Prepared For

Here's what's coming. For a growing number of users, the primary interface to your protocol won't be your dApp. It'll be a conversation.

"Where should I put my ETH right now?"

Users will ask this to their AI assistant. The assistant will evaluate multiple protocols, compare yields, assess risks, and make a recommendation. Your protocol's chance of being recommended depends entirely on how well the agent understands what you offer, what your risks are, and who you're for.

If your structured data is clear, accurate, and well-organized, the agent represents you correctly. If it's not, the agent either skips you or misrepresents you.

This is the shift from dashboard-first to conversation-first interfaces. You're not designing the screen the user looks at anymore. You're designing the data that informs the conversation the user has.

The Brand Engineer Role

This requires a new kind of designer. Someone who thinks in both visual systems and structured data. Someone who can design a beautiful token page and also structure the YAML file that an agent consumes when explaining that token to a user.

We're calling this a brand engineer. Not a brand designer. Not a front-end engineer. Someone who sits at the intersection.

A brand engineer delivers:

Figma files for the design team. Visual identity, component libraries, design tokens, interaction patterns. The human-facing layer.

Structured data files for the agent layer. Positioning YAML, voice Markdown, visual tokens JSON, terminology, guardrails, retrieval rules. The agent-facing layer.

Information architecture for both audiences simultaneously. How is the protocol's knowledge organized so that humans can navigate it and agents can retrieve from it?

This is a new skill set. Most designers don't have it yet. The ones who develop it will be the most valuable people in Web3 over the next three years.

Composable Brands

Here's where Web3's native composability creates a problem nobody's solving yet.

In DeFi, protocols compose. Aave sits on Ethereum. Yearn routes through Aave. Aggregators route through everything. One transaction might touch four protocols.

When a user asks an agent to explain that transaction, whose brand voice does the agent use? When your protocol is displayed inside another protocol's interface, whose visual identity shows? When an aggregator lists your pool alongside 30 others, how is your brand represented?

Right now, the answer is: whoever described themselves best in whatever unstructured data the agent could find. That's not a strategy. That's a lottery.

Composable brands mean your protocol exposes its brand as structured data that other protocols and agents can consume programmatically. Your visual tokens, your positioning, your voice guidelines, available as a queryable system. Not just for your own agents. For the entire ecosystem that touches your protocol.

This is brand as a protocol primitive. Not as a nice-to-have. As infrastructure.

Where This Is Going

In 2027, the Web3 design portfolio looks different. You don't just show screenshots of dApp interfaces. You show the information architecture that serves all three audiences. You show the structured brand data that makes agents represent your clients correctly. You show the before/after of how a protocol was described by AI assistants before and after you designed its agent-facing layer.

The studios that understand this will win the best clients. The designers who can work across all three audiences will command premium rates. The protocols that invest in this layer will be better understood, better represented, and better positioned in every AI-mediated interaction.

Three audiences. One system. That's the new brief.