This is the approach I use when designing AI-driven products from concept through implementation. It emerged from building two independent AI product concepts — tuNirvana and Listo — and has proven applicable across different product types and team structures.
Most product design starts with screens and works backwards to behavior. For AI-driven products, that sequence reliably produces systems that feel inconsistent, lose user trust, and require expensive behavioral retrofits.
"If the behavior is wrong, the UI doesn't matter."
Traditional design asks: "What does this screen do?" AI products require a different question first: "What does the system need to understand before it can respond?" Behavior is the primary design surface. Poorly defined behavioral logic produces bad experiences regardless of how polished the interface is — and it directly impacts user retention and trust.
AI products are behavioral systems that happen to have interfaces — not interfaces that happen to use AI. The BFD Framework defines states, responses, fallbacks, and flows before screens are drawn. Getting this sequence right reduces friction, builds user trust, and improves engagement because the AI responds appropriately from the first interaction.
The BFD Framework emerged from designing two independent AI product concepts currently in development, both targeting the Latin American market. They differ in domain but share a common design challenge: the AI's behavior is the product.
An AI emotional companion platform designed to provide accessible mental health support for users in Latin America who cannot easily access traditional therapy. The AI acts as a bridge between silence and help — through empathy, not diagnosis.
An AI-powered service marketplace where users find, evaluate, and book local professionals through a conversational AI agent. The system operates across Web, WhatsApp, and Voice — serving both seekers and providers simultaneously.
This shift changes what gets designed first and how teams make decisions. It also changes what ships — and how well it performs with real users.
Standard product design asks: what does the user want to do, and how do we build a screen for it? That works for deterministic software — click a button, something predictable happens.
AI products work differently. The system interprets a situation and generates a response. That interpretation loop is where most of the design work lives. Poorly defined behavioral logic produces responses that feel off — and users who disengage, or worse, stop trusting the product entirely.
Behavior-first design maps that logic before drawing screens. What state is the user in? What does the AI detect? What does it do, and what does it say? Those four questions, answered for every significant input state, are the real product specification for an AI-driven experience.
Design a UI, then figure out what the AI should do within it. The interface constrains the behavior before the behavior is defined — the product ends up feeling reactive instead of intentional.
Define every user state and AI response first. Then design an interface that serves those behaviors. The result is a product where the AI feels coherent — and users come back because it works the way they expect.
In AI products, the exchange between user and system is the primary design artifact — not the screen. The quality of that loop — its accuracy, tone, pacing, and fallback logic — is what users experience. Interface design follows.
User goals tell you what someone wants. User states tell you what they're experiencing when they open the product. For AI to respond well, state information is essential. Goals alone are insufficient inputs.
The exact words an AI uses, its tone, its pacing, and what it suggests next are all design decisions — not engineering defaults. This applies before any code is written, and directly affects whether users engage or disengage.
In AI products, edge cases often represent the user's most difficult moment: crisis, confusion, hostility, silence. Products that treat edge cases as afterthoughts fail at the moments that matter most.
The AI Response Matrix makes behavioral intent visible to design, engineering, and product simultaneously — reducing ambiguity, preventing implementation drift, and making future changes auditable.
In both product concepts, retention depended on whether users trusted the AI — built through consistency, transparency, and restraint. Defining trust-building behaviors explicitly is a product decision, not an afterthought.
The BFD Framework works consistently across product types and team sizes. It is structured enough to follow and flexible enough to adapt. Each step produces a concrete deliverable the whole team can use.
Define every emotional and situational state users may be in — not only their goals, but their context and condition.
Identify state categories
Define emotional and situational dimensions that matter for this product: urgency, mood, familiarity, trust level.
Enumerate all input states
Create a comprehensive list of user states the AI might encounter. These become inputs for the behavior specification.
User State Map — all meaningful user states the AI must handle, grouped by type
For each user state, define in plain language what the AI detects, says, suggests, and does — including when the user does not respond.
Define tone, language, and response intent
Write the emotional register of each response, select exact phrases where precision matters, define what should not be said.
Define detection logic and state conditions
Specify how the system detects each state: keyword matching, NLP signal, mood threshold, or time-based triggers.
AI Response Matrix — every user input state mapped to a corresponding AI behavior, response type, tone, and branch action
Map every flow, branch, connection, loop, and edge case before touching the interface. This is where the product's behavioral complexity becomes visible.
Create full flow documentation
Map all user journeys across all states, including handoffs between modules, re-entry points, and what happens when the user goes quiet.
Review for technical feasibility
Identify state management requirements, data dependencies, and where persistence or memory is needed for coherent AI behavior.
Full Interaction Architecture — annotated flow diagrams covering all modules, branches, edge cases, and cross-section connections
With behavioral logic already defined, design screens that serve the specified behaviors. The interface becomes a container for what is already decided.
Translate behaviors into UI patterns
Choose interaction models that support the AI's behavioral intent. For each screen: does this interface serve the behavior, or get in the way of it?
Implement state-aware UI components
Build components that adapt to the AI's current output state. The interface should reflect what the AI knows, not present a fixed shell.
Behavior-informed wireframes and component specs — every design decision traceable to a behavioral requirement
Standard usability testing asks whether users can complete tasks. AI products also require testing whether responses feel appropriate — in tone, timing, and cultural register.
Run emotional tone testing
Ask users: does this feel right? Does it feel safe? Does it feel like it understands me? Adjust the behavior spec based on findings.
Monitor and audit AI behavior in production
Track where behavioral specifications are not being met. Build observability so AI behavior can be audited and corrected over time.
Revised Behavior Spec and updated AI Response Matrix — validation findings feed back into Step 02 (iterative)
The "Log Mood" feature in tuNirvana illustrates the difference between traditional UI thinking and the BFD Framework approach in a concrete way.
The conventional design starts with a screen: an emotion picker (happy / sad / anxious / calm), an optional text field, a save button. The user selects a mood, the app records it, the chart updates.
Functionally complete. Behaviorally inert. The system knows the user is anxious — and does absolutely nothing with that information. No response. No next action. No engagement. The AI has no role in the experience.
Result: Data is collected. The user is not helped.
The BFD approach starts with a different question: what is the user's state when they select "anxious"? What should the AI detect, say, and offer? These questions are answered before the screen is designed.
The mood log becomes the entry point to a behavioral loop. The AI interprets the selection, references history, selects a response strategy, and routes the user to a contextual next action — increasing engagement, reducing friction, and building the habit loop that drives retention.
Result: The user is helped. The session deepens.
The BFD Framework is only useful if everyone can work with it. Different roles engage with different parts — the goal is making behavioral intent visible across the whole team.
Product defines what the AI is responsible for — and what it is not. That boundary is a product decision, not a technical one.
Design owns the emotional register of the AI's responses and the full interaction architecture before any screen work begins.
Engineering translates behavioral specifications into detection logic and state management — and surfaces what is technically feasible.
A framework worth using includes its failure conditions. These are constraints that require explicit design decisions, not workarounds.
Even with a well-defined behavior spec, LLMs generate responses probabilistically. The spec constrains direction but does not eliminate variation. In emotionally sensitive products, this requires explicit guardrails — not just good prompts — and regular behavioral auditing in production. The spec should be treated as a living document.
Conversational AI introduces friction for simple, transactional tasks. If a user needs to book a time slot, a calendar picker is faster and more reliable than a natural language exchange. The question to ask: does the AI need to understand context to respond well, or is the task deterministic? If deterministic, use a standard UI.
In both product concepts, defining what the AI should not do was as important as defining what it should do. In tuNirvana, the AI is not a therapist — that boundary had to be explicit in the product's language, in its response patterns, and in the behavior spec. Without guardrails, the AI fills ambiguity with whatever seems helpful, which may not be appropriate.
The behavior specification should be treated as a hypothesis, not a blueprint. The first version will be wrong in ways only visible when real users interact with the AI. Building in explicit revision loops — especially after the first behavioral testing round — is not optional. Products that ship a spec and consider it done will find the AI coherent in testing and broken in production.
This shift changes what gets designed first, what the most valuable deliverables are, and how teams make decisions together. Applied consistently, the BFD Framework produces AI products that feel intentional, build user trust, and retain engagement — because the behavior is right before the interface exists.
Map crisis flows and error states before the happy path. This clarifies edge-case decisions early — when they're cheap to change — and improves the quality of every other flow in the process.
The most referenced document in both product concepts was the AI Response Matrix — not any wireframe or prototype. If that table is clear, most interface decisions follow from it automatically.
Defining what the AI will not do is as important as defining what it will. Boundaries set in the behavior spec prevent the AI from filling ambiguity with well-intentioned but inappropriate responses in production.
In AI-first products, the AI's language is experienced before any visual element. Word choice, tone, and pacing deserve design investment proportional to how central they are to the product's core value.
Users return to AI products because they trust them — not because they have more features. Consistency, clear limitations, and respect for user autonomy are the design variables that determine whether users stay.
Recording the reasoning behind behavioral decisions — not just the decisions themselves — prevents implementation drift, enables faster iteration, and keeps the team aligned as the product evolves.
Designing AI-driven products challenged me to think beyond interface patterns and focus on the behavioral systems that make AI feel coherent and trustworthy. The most important lesson: start with what the AI needs to understand, not with what the screen should look like. Define the response before you design the container. Test how it feels, not just whether it works.
