Notícias
Notícias
5 min de leitura
25 de setembro de 2026

Chat é UI errada pro seu AI agent. Como consertar?

Seu AI agent é um chatbot (texto → texto). Customer quer ação (decisão, resultado, mudança). Chat box é lixo pra isso. Redesenhe.

Equipe OpenClaw

Equipe OpenClaw · Time de Engenharia & Produto

A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…


Chat é UI errada pro seu AI agent. Como consertar?

Você é founder de SaaS.

Você construiu AI agent (suporte, recomendações, automação).

Agent é chatbot (por padrão).

Customer interacts via chat:

Customer: "Qual plano eu deveria contratar?" │ Your agent: "Baseado em seu usage, Plano Pro é ideal. Custa R$999/mês. Inclui..." │ Customer: "Ok, contrata pra mim." │ Agent: "Para contratar, clique no botão 'Upgrade' no dashboard." │ Customer: Goes to dashboard. Clicks upgrade. Chooses plan. Fills form. Confirms payment. │

Problem: Why did customer need to leave chat to complete action?

Answer: Because chat is wrong UI for this task.

Chat is good for: Asking questions, getting information, explaining things.

Chat is bad for: Making decisions, completing transactions, taking action, seeing results.

Better UX:

Customer: "Qual plano eu deveria contratar?" │ Your agent: Shows comparison table (in-chat) ├─ Plano Basic: R$299/mês ├─ Plano Pro: R$999/mês (← recommended for you) ├─ Plano Enterprise: Custom └─ [Upgrade Pro] button (inline) │ Customer: Clicks [Upgrade Pro] │ Agent: Shows payment form (inline) ├─ Card number: [input] ├─ Expiry: [input] ├─ CVC: [input] └─ [Confirm Payment] button │ Customer: Enters card. Clicks confirm. │ Agent: Shows confirmation ├─ ✓ Payment successful ├─ Your plan: Plano Pro (activated) ├─ Next billing: 2026-10-25 └─ [View invoice] link │

Customer never leaves chat. Task completed in 2 clicks instead of 10 steps.


O problema real (por que chat é UI padrão, mas errada)

Dilema 1: Chat is default (because it's easy to build)

=== WHY CHAT IS DEFAULT === │ Why startups choose chat UI: ├─ Easy: Use existing chat framework (send text, receive text) ├─ Fast: Deploy in days (not weeks) ├─ Cheap: No fancy UI needed ├─ Popular: Everyone knows chat (WhatsApp, Slack, Teams) │ Why it sticks: ├─ LLMs are text-in, text-out (natural interface is chat) ├─ First mover advantage: ChatGPT normalized chat for AI ├─ Path of least resistance: Keep building chat features ├─ Sunk cost: Already invested in chat infrastructure │ Result: ├─ Every AI agent is chatbot (by default) ├─ Even when chat is wrong UI for task ├─ Because switching UI is expensive (rebuild, retrain, redesign) │ But customer doesn't care (about your constraints): ├─ Customer: "Can I buy this in chat?" ├─ You: "Go to dashboard, click upgrade." ├─ Customer: "That's annoying. Can you just let me do it here?" ├─ You: "Um... our architecture doesn't support that." ├─ Customer: "Cool, I'm switching to competitor." (competitor has better UX) │

Dilema 2: Chat is confusing for action-oriented tasks (customer gets lost)

=== CHAT CONFUSION PROBLEM === │ Example task: Refund request │ With chat UI: ├─ Customer: "I want a refund." ├─ Agent: "I can help. Let me ask some questions. │ 1. Which order? 2. What's the issue? 3. Refund to original payment method?" ├─ Customer: "My order #12345. Quality was bad. Yes to original method." ├─ Agent: "Processing refund. Expect 3-5 business days." ├─ Customer: "Great, thanks." ├─ Agent: "Is there anything else?" ├─ Customer: "No." │ Problems: ├─ Feels like support conversation (not transaction) ├─ Customer never sees confirmation (did it work?) ├─ Customer can't track status (when will refund show up?) ├─ Customer gets anxious (is it actually processing?) │ With proper UI: ├─ Customer: Clicks "Refund" on order page ├─ Agent: Shows refund form (inline) │ ├─ Order: #12345 (product name + price) │ ├─ Reason: [dropdown] Bad Quality ← selected │ ├─ Refund to: Original payment method ← option checked │ └─ [Process Refund] button ├─ Customer: Reviews. Clicks confirm. ├─ Agent: Shows confirmation │ ├─ ✓ Refund approved (order #12345) │ ├─ Amount: R$299 │ ├─ Timeline: 3-5 business days │ ├─ Status: [tracking link] │ └─ [Download receipt] │ Benefits: ├─ Looks like transaction (not support) ├─ Customer sees confirmation (clear success) ├─ Customer sees timeline (knows when to expect) ├─ Customer sees reference number (can track) │

Dilema 3: Chat wastes time (customer wants result, not conversation)

=== TIME WASTE PROBLEM === │ Customer mindset: ├─ "I want to schedule a meeting." ├─ Fastest way: Click time picker, send invite ├─ Time: 10 seconds │ With chat UI: ├─ Customer: "Can you schedule a meeting for next Tuesday?" ├─ Agent: "Sure! What time?" ├─ Customer: "3 PM." ├─ Agent: "With who?" ├─ Customer: "Sarah." ├─ Agent: "What's her email?" ├─ Customer: "sarah@acme.com" ├─ Agent: "What's the topic?" ├─ Customer: "Project review." ├─ Agent: "Meeting scheduled. Sarah will get invite." ├─ Time: 2 minutes │ Customer frustration: ├─ "Why did that take so long?" ├─ "I just wanted to pick Tuesday 3 PM and it goes to Sarah's calendar." ├─ "Why did agent need to ask me so many questions?" ├─ "UI should just have form fields (I fill all at once)." │ Better UI: ├─ Form: [Date picker] [Time picker] [Participant input] [Topic input] ├─ Customer: Fills all fields at once ├─ Agent: Sends invite ├─ Time: 20 seconds │

Dilema 4: Chat scales poorly (context gets lost)

=== CONTEXT LOSS PROBLEM === │ Long chat conversation (20+ messages): │ Message 1: "I want to change my billing address." Message 2: Agent: "Sure, what's your new address?" Message 3: Customer: "123 Main St, São Paulo, SP, 01234-567" Message 4: Agent: "Got it. Anything else?" Message 5: Customer: "Also, can I add a user to my account?" Message 6: Agent: "Sure. What's their name?" Message 7: Customer: "João." Message 8: Agent: "Last name?" Message 9: Customer: "Silva." Message 10: Agent: "Email?" Message 11: Customer: "joao@company.com" Message 12: Agent: "Added. Anything else?" Message 13: Customer: "What's my new billing address?" Message 14: Agent: "Um... let me check. It's... 123 Main St?" Message 15: Customer: "Yes, that's right." │ Problems: ├─ Customer has to scroll back (to find their address) ├─ Agent might forget context (especially with LLM hallucinations) ├─ No clear summary (what actually changed?) ├─ Hard to audit (what did customer request?) │ Better UI: ├─ Dashboard tab: "Billing" │ ├─ Address section: Shows address (live update) │ ├─ [Edit address] button → inline form ├─ Dashboard tab: "Team" │ ├─ Members list: Shows João Silva added today │ ├─ [Add member] button → inline form │ Benefits: ├─ No scrolling (information is always visible) ├─ Clear state (what is current vs what changed) ├─ Easy audit trail (who changed what when) ├─ No context loss (UI shows reality) │


Impacto no seu SaaS (konkretni problemi)

Problem 1: Customers leave chat (do action elsewhere, churn)

=== CUSTOMER CHURN === │ Journey: ├─ Customer: "How do I upgrade my plan?" ├─ Your agent: "Click dashboard → settings → billing → upgrade." ├─ Customer: Leaves chat. Goes to dashboard. ├─ Customer: Gets distracted (sees other features, gets lost) ├─ Customer: Closes browser ("I'll do it later.") ├─ Later: Customer forgets. Stays on old plan. ├─ Result: Lost revenue (customer never upgrades) │ Alternative: ├─ Chat: Shows [Upgrade Plan] button (inline) ├─ Customer: Clicks button (still in chat) ├─ Customer: Sees upgrade form (in chat) ├─ Customer: Fills form (in chat) ├─ Customer: Confirms (in chat) ├─ Result: Customer upgraded (conversion increases) │

Problem 2: Agent feels like support (not product feature)

=== PERCEPTION PROBLEM === │ Customer perception: │ With chat UI: ├─ Agent = Support person answering questions ├─ Customer mindset: "Asking for help" ├─ Emotion: Reluctance (bothering someone) │ With proper UI: ├─ Agent = Product feature (like calculator, recommendation engine) ├─ Customer mindset: "Using the product" ├─ Emotion: Empowerment (I did something) │ Result: ├─ Chat: Customer avoids agent (try to figure out alone) ├─ UI: Customer uses agent (trusts it) ├

Problem 3: Developers build chatbot, not product (wrong mental model)

=== DEVELOPER MINDSET === │ With chat default: ├─ Dev: "Build chatbot that answers questions." ├─ Dev: "LLM returns text. Display in chat." ├─ Dev: "Done." │ Missing: Product thinking ├─ What action does customer want to complete? ├─ What UI is best for that action? ├─ How do we reduce friction? ├─ How do we make it feel native? │ Result: ├─ Agent feels like chatbot (not product feature) ├─ Friction is high (customer has to leave) ├─ Adoption is low (customers avoid agent) │


Solução: Design AI UX beyond chat (action-oriented)

Pattern 1: Inline forms (not multi-turn conversation)

=== INLINE FORMS === │ Instead of: ├─ Agent: "What's your new email?" ├─ Customer: "newemail@company.com" ├─ Agent: "Updated." │ Better: Show form (all fields at once) ├─ Email: [input field] [already filled with current] ├─ [Update Email] button │ Benefit: ├─ Customer: Edits all fields (doesn't need conversation) ├─ Faster (one interaction vs 3) ├─ Clearer (customer sees what they're changing) ├─ Easier to validate (form validation, not LLM validation) │

Pattern 2: Rich UI elements (not just text)

=== RICH ELEMENTS === │ Option 1: Text only ├─ Agent: "Your options are: Basic (R$299), Pro (R$999), Enterprise (custom)." │ Option 2: Formatted table ├─ Plan | Price | Features ├─ Basic | R$299 | Up to 100 API calls/day ├─ Pro | R$999 | Up to 10K API calls/day ← Recommended for you ├─ Enterprise | Custom | Unlimited + dedicated support │ Benefit: ├─ Easier to scan (not reading paragraphs) ├─ Faster decision (visual comparison) ├─ Better UX (feels like product, not support) │

Pattern 3: Embedded widgets (actions in-place)

=== EMBEDDED WIDGETS === │ Instead of: ├─ Agent: "To schedule a meeting, go to calendar app." │ Better: Embed calendar widget ├─ [Date picker] [Time picker] ├─ Participant: sarah@acme.com ├─ Topic: Project review ├─ [Schedule] button │ Benefit: ├─ Never leaves chat (action happens in-place) ├─ Fewer clicks (all in one interface) ├─ Better conversion (lower friction = more usage) │

Pattern 4: Status dashboard (not text responses)

=== STATUS DASHBOARD === │ Instead of: ├─ Customer: "What's my order status?" ├─ Agent: "Your order #12345 is being shipped. │ It left the warehouse at 10am. │ Estimated delivery: tomorrow." │ Better: Show visual status ├─ Order #12345 ├─ Status: [●●●●●] Shipped (5/5 steps) ├─ Timeline: │ ├─ ✓ Ordered (Sept 25) │ ├─ ✓ Packed (Sept 25) │ ├─ ✓ Shipped (Sept 26, 10am) │ ├─ ● In transit (expected Sept 27) │ └─ ○ Delivered ├─ Tracking: [link to carrier] │ Benefit: ├─ Customer doesn't need to ask (status is visible) ├─ Reduces support load (fewer questions) ├─ Better UX (visual beats text) │

Pattern 5: Inline confirmations (not conversations)

=== INLINE CONFIRMATIONS === │ Instead of: ├─ Agent: "Refund processed. Expect 3-5 business days." │ Better: Show confirmation card ├─ ✓ Refund approved ├─ Amount: R$299 ├─ Order: #12345 ├─ Refund method: Original payment method ├─ Expected by: Sept 29 - Oct 1 ├─ [View receipt] [Track refund] │ Benefit: ├─ Customer has reference (can bookmark, screenshot) ├─ Reduces follow-up questions (all info visible) ├─ More official (looks like receipt, not chat) │


Praktični implementacija

Step 1: Audit your agent (what actions does it handle?)

  1. List all agent capabilities ├─ What questions does agent answer? ├─ What actions does agent enable? ├─ What decisions does agent help with?

  2. Categorize by interaction type ├─ Information lookup (chat is fine) ├─ Decision support (needs rich UI) ├─ Transaction (needs forms + confirmation) ├─ Status check (needs dashboard)

  3. Prioritize ├─ Which interactions have highest volume? ├─ Which interactions have lowest conversion? ├─ Which interactions cause most support escalations?

Example: ├─ "Get API pricing" → Info lookup (chat OK) ├─ "Upgrade plan" → Transaction (needs form + payment UI) ├─ "Schedule demo" → Transaction (needs calendar widget) ├─ "Check order status" → Status (needs dashboard) │ Focus: Transaction + status (highest impact) │

Step 2: Design UI for high-impact actions

  1. Map each action to best UI ├─ Upgrade plan → In-app upgrade flow (not chat) ├─ Schedule meeting → Calendar widget (not chat) ├─ Track order → Status dashboard (not chat) ├─ Request refund → Form + confirmation (not chat)

  2. Prototype each UI ├─ What fields are needed? ├─ What's the happy path? (fewest clicks) ├─ What are edge cases? (validation, errors) ├─ What's the confirmation?

  3. Test with customers ├─ Do they understand UI? ├─ Can they complete action? ├─ How long does it take? ├─ Do they feel confident? │

Step 3: Implement hybrid UI (chat + rich elements)

  1. Keep chat as fallback ├─ If customer asks in chat → Show rich UI ├─ But also provide [Upgrade] button (direct action) ├─ If customer clicks button → Use rich UI (not chat)

  2. Integrate rich elements ├─ Forms (inline, validated) ├─ Tables (sortable, filterable) ├─ Status dashboards (live updates) ├─ Embedded widgets (calendar, time picker) ├─ Confirmations (visual, not text)

  3. Measure improvement ├─ Conversion rate (% completing action) ├─ Time to completion (how fast?) ├─ Support escalations (fewer questions?) ├─ Customer satisfaction (CSAT improved?) │


Conclusão

Simple verdade:

Chat é default UI pra AI agents (porque é fácil de buildar). Mas chat é errado UI pra action-oriented tasks (upgrade plan, schedule meeting, request refund). Customer wants result (não conversa). Chat forces conversation (confusing, slow, high friction). Better: Hybrid UI (chat + rich elements). Keep chat for questions. Use forms for transactions. Use dashboards for status. Use confirmations for clarity. Result: Higher conversion (customers complete actions). Lower support load (fewer questions). Higher satisfaction (customers feel empowered). Bottom line: Don't build chatbot. Build product that happens to include AI.

3 facts:

  1. Chat is default (not optimal). Why? Easy to build (text in, text out). But customers don't want conversation (they want action). Form is faster than multi-turn chat (fill all fields at once vs ask-answer-ask). Table is clearer than paragraph (scan vs read). Dashboard is better than text status (visual progress vs "it's on the way"). Yet every AI agent is chatbot (because developers default to chat). Solution: Design UX for action (not conversation). Cost: Extra dev work. Benefit: Higher conversion (worth it).

  2. Chat wastes time (customer frustration). Why? Multi-turn conversation (each turn = waiting). Context loss (scroll back to find info). No visual feedback (did it work?). No record (what was the confirmation?). Form is faster (all fields at once, one submit, one confirmation). Dashboard is clearer (status is visible, no need to ask). Rich UI is better (compare options visually, not textually). Result: Chat adds friction. Rich UI removes friction. Customers prefer no friction.

  3. Chat feels like support (not product). Why? Conversation tone (sounds like help desk). No clear transaction (feels like asking, not doing). No record (where's my receipt?). Rich UI feels like product (clear UI patterns, familiar from other apps). Forms feel like purchasing (payment flows). Dashboards feel like business tools (tracking, management). Result: Chat adoption low (customers avoid asking). Rich UI adoption high (customers feel empowered). Perception shapes usage.

3 action items (this week):

  1. Audit agent interactions (1-2 hours, today). List all actions agent handles. Categorize: info lookup (chat OK) vs transaction (needs form) vs status (needs dashboard). Identify highest-impact actions (most volume, lowest conversion, most escalations). Example: "Upgrade plan" is transaction (needs rich UI, not chat).**

  2. Design UI for top action (2-4 hours, this week). Pick #1 highest-impact action (e.g., "Upgrade plan"). Design optimal UI (form with plan comparison + payment + confirmation). Prototype. Test with customer. Measure: Time to complete (faster than chat?). Conversion rate (more complete?).**

  3. Implement hybrid (4-8 hours, this week). Keep chat as fallback. Add rich UI for top action. Link from chat ("Customer asks in chat? Show [Upgrade] button"). Measure improvement (conversion +? satisfaction +? escalations -).**


Próximos passos

Na OpenClaw, ajudamos SaaS builders redesenhar AI agent UX (beyond chat):

  • Interaction Audit: Mapear todas as ações que agent maneja (quais precisam de rich UI?).
  • UI/UX Design: Desenhar optimal interface pra cada ação (forms, dashboards, widgets).
  • Prototype Testing: Testar UI com clientes reais (conversão melhora?).
  • Hybrid Architecture: Implementar chat + rich elements (best of both).
  • Forms & Validation: Inline forms (pré-preenchidas, validadas).
  • Rich Widgets: Calendar, time picker, dropdown, status dashboard (embedded).
  • Confirmation UI: Visual confirmations (receipt, tracking, status).
  • Analytics: Medir improvement (time to complete, conversion, escalations).
  • Multi-step Flows: Wizard patterns (se precisa muitos steps).
  • Mobile-first UX: Rich UI on mobile (não apenas desktop).
  • Accessibility: WCAG compliance (forms, buttons, labels).
  • Progressive Enhancement: Chat works. Rich UI is enhancement. Both work together.

AI Agent UX Design | Beyond Chat | Interaction Patterns | Forms & Widgets | Rich UI | Conversion Optimization →


Publicado em 25 de setembro de 2026

Leia também