BrisaVerse — Plano de UX e Produto
Status: Referência ativa · Última atualização: 2026-06-20
TL;DR: Personas definidas, jornadas mapeadas, wireframes ASCII, 8 anti-padrões documentados.
Sumário rápido
| Seção | O que tem |
|---|---|
| 0. Premissas | Princípios que guiam todas as decisões de UX |
| 1. Personas | Lucas (âncora), Marina (designer), Rafael (ADHD/WhatsApp) |
| 2. Jornadas | Setup inicial, uso diário, integração nova |
| 3. Mural atual | Análise das 4 abas: Hoje, Nexus, Lores, Config |
| 4. Onboarding | Fluxo completo + solução cold start |
| 5. Telas por Sessão | O que construir em cada sessão (4 sessões) |
| 6. Wireframes | ASCII mockups dos fluxos principais |
| 7. Anti-padrões | 8 erros de UX a evitar (com o que fazer) |
| Adendos | Revisões externas: timeline, Nexus mobile, áudio |
Foco: experiência real do usuário, mobile-first, local-first
0. Premissas de Produto
Antes de qualquer jornada ou wireframe, três premissas não-negociáveis que guiam todas as decisões de UX:
-
O Telegram é o canal de entrada — o mural é o espelho. O usuário não precisa aprender uma nova UI para capturar. Ele já usa Telegram. O mural existe para visualizar, navegar e questionar o contexto — não para ser a interface principal.
-
A IA precisa parecer que conhece o usuário desde o primeiro dia. O cold start é o maior risco de abandono. A interface deve comunicar "já tenho contexto sobre você" mesmo com poucos dados, e tornar visível o crescimento da memória ao longo do tempo.
-
Nunca criar culpa. Streaks, percentuais de conclusão, avisos de inatividade — tudo isso vai contra o princípio de interface que convida. O padrão visual deve ser calmo mesmo quando o usuário está com muitas tarefas atrasadas.
1. User Personas
Persona 1 — O Lucas (persona-âncora, já existe)
Perfil: Desenvolvedor 30 anos, múltiplos projetos paralelos (Stronda Cup, bot Brisa, cliente freelance), usa VPS próprio, tem Telegram como canal de comunicação principal. Comportamento: Captura ideias em rajadas curtas no Telegram, depois perde o fio. Abre o mural no computador para revisar contexto antes de sessões de trabalho. Valoriza que os dados são seus e ficam no seu servidor. Dores principais: Não saber onde estava em um projeto após 2 semanas de afastamento. Ter notas espalhadas que não se conectam. IA genérica que não conhece seus projetos. Momento uau esperado: Perguntar "o que eu estava pensando sobre o Stronda Cup?" e a Brisa trazer notas de 3 semanas atrás que ele tinha esquecido.
Persona 2 — A Marina (persona nova)
Perfil: Designer UX 32 anos, trabalha remoto para startup, tem projeto paralelo de cursos online, cuida da própria saúde mental ativamente. Stack: Mac + iPhone, usa Notion para trabalho (imposto pelo time) e odeia a rigidez para uso pessoal. Testou Obsidian mas desistiu depois de 2 semanas configurando plugins. Comportamento: Anota reflexões longas no fim do dia, mas raramente as relê. Quer um sistema que "entenda" o que ela escreveu sem precisar categorizar. Usa Telegram para grupos, mas não como ferramenta de produtividade. Dores principais: Gastar 30 minutos configurando sistemas que abandona em 1 mês. Não conseguir encontrar uma nota que sabe que escreveu mas não lembra onde. Querer entender padrões emocionais ao longo do tempo. Momento uau esperado: Abrir a timeline e ver que em agosto ela sempre fica ansiosa — padrão que ela não teria identificado sozinha. Barreira de entrada: Setup técnico. A persona-Marina só adota se o docker run for realmente simples e houver uma alternativa ao Telegram como canal de entrada (quick capture pelo mural). Implicação de produto: A Fase 2 (quick capture no mural) é crítica para personas não-Telegram. Sem ela, o produto fica limitado ao perfil técnico.
Persona 3 — O Rafael (persona nova)
Perfil: Empreendedor 38 anos, sócio em 2 empresas, 3 filhos, viaja 1 semana por mês. Usa iPhone como ferramenta principal de trabalho. Stack: iPhone + iPad, usa WhatsApp para negócios, tem assistente que gerencia agenda no Google Calendar. Comportamento: Captura tudo em notas de voz no WhatsApp (manda para si mesmo). Tem ADHD diagnosticado — começou 4 sistemas de PKM nos últimos 2 anos e abandonou todos. Valoriza ação imediata, não planejamento. Dores principais: Ter insights importantes esquecidos porque foram mandados no WhatsApp e nunca mais vistos. Não ter um "estado atual" claro dos projetos. Depender da memória humana para contexto de reuniões. Momento uau esperado: Antes de uma reunião, perguntar "o que aconteceu com o projeto X desde a última vez que vi o Rafael?" e ter um briefing automático. Barreira de entrada: WhatsApp como canal de entrada (Fase 4+) e captura por voz funcionando bem. Sem isso, o produto não encaixa no workflow real. Implicação de produto: A integração WhatsApp é Fase 4+ pelo roadmap — o Rafael não é a persona do MVP. Mas o produto não deve ser arquitetado de forma que o torne impossível de incorporar depois.
2. Jornadas de Usuário
Jornada 1 — Setup Inicial (usuário novo → primeira brisa capturada)
PONTO DE ENTRADA: README / indicação de amigo / post de blog
│
▼
[1] LÊ O PITCH
"docker run + 5 minutos + sua IA que te conhece de verdade"
Risco de abandono: pitch técnico demais → "parece complicado"
Mitigação: primeira linha do README é uma pergunta ("Você já perdeu
uma ideia importante porque não achou mais onde anotou?")
│
▼
[2] EXECUTA docker run
Tempo esperado: 2-3 minutos (download da imagem)
Risco de abandono: erro de porta ocupada, erro de permissão
Mitigação: saída do container mostra URL clicável + instruções de
troubleshooting inline
│
▼
[3] ABRE O MURAL (primeira vez)
Vê: tela de onboarding — NÃO o mural vazio
Conteúdo: "Olá. Sou a Brisa. Antes de começar, me conta 3 coisas."
Risco de abandono: formulário longo de configuração
Mitigação: máximo 3 perguntas (ver Seção 4)
│
▼
[4] RESPONDE AS 3 PERGUNTAS DE ONBOARDING
- "Qual o seu nome?" → personalização imediata
- "Quais são os 3 principais domínios da sua vida agora?"
(exemplos: Trabalho / Saúde / Projetos pessoais)
- "Como você prefere me chamar?" (nome do bot)
Tempo esperado: 90 segundos
Risco de abandono: pergunta que parece invasiva
Mitigação: todas as perguntas têm "pode pular" visível
│
▼
[5] VÊ O MURAL PRÉ-POPULADO COM SEUS DOMÍNIOS
Os nós do mapa já mostram os domínios que o usuário escolheu
Mensagem da Brisa: "Seu espaço está pronto. Agora me manda
qualquer coisa que está na sua cabeça."
Risco de abandono: mural parece vazio/inútil
Mitigação: nós já têm dicas de o que capturar em cada domínio
│
▼
[6] CONECTA O TELEGRAM (ou usa quick capture)
Duas opções apresentadas como cards:
A) "Conectar Telegram" (recomendado para mobile)
B) "Usar aqui mesmo" (para quem prefere mural)
Risco de abandono: configuração do bot Telegram confusa
Mitigação: botão "Instruções passo a passo" com GIF animado
│
▼
[7] PRIMEIRA CAPTURA
Via Telegram: usuário manda qualquer mensagem
Via mural: usuário clica no "+" flutuante
Bot/mural responde: "Captei! Salvei em [Domínio].
Já tenho 1 item de contexto sobre você."
MOMENTO: usuário sente que o sistema "recebeu" e confirmou
│
▼
[8] RECEBE PRIMEIRA BRISA NO DIA SEGUINTE
Briefing matinal automático no Telegram:
"Bom dia [Nome]. Você tem 1 item de ontem: [resumo].
O que você quer fazer com isso hoje?"
MOMENTO UAU 1: "Ela lembrou de mim"
│
FIM DA JORNADA 1 — usuário ativado
Métrica de sucesso da Jornada 1: tempo médio entre docker run e primeira mensagem enviada < 8 minutos.
Onde vai abandonar: Passo 6 (configuração do Telegram). Mitigação principal: fazer a configuração do bot ser automática via deep link (t.me/BrisaBot?start=TOKEN) em vez de manual.
Jornada 2 — Uso Diário (dia normal após ativação)
06:30 — ACORDA, OLHA O TELEGRAM
│
▼
[1] RECEBE BRIEFING MATINAL DA BRISA (já existe, Fase 0)
Conteúdo: tarefas do dia, eventos do calendário (se integrado),
uma frase de contexto ("Ontem você estava focado em X")
Duração de leitura esperada: 30 segundos
Comportamento: usuário lê, talvez responda com "ok" ou pergunta rápida
│
▼
[2] DURANTE O DIA — CAPTURA NO TELEGRAM (mobile)
Mensagens curtas e não-estruturadas:
- "preciso ligar pra seguradora da casa"
- áudio de 45 segundos descrevendo ideia de produto
- foto de um post-it com task
Comportamento da Brisa: confirma captura, classifica, não interrompe
Frequência típica: 3-8 capturas por dia
│
▼
[3] PERÍODO DE TRABALHO — SESSÃO NO MURAL (desktop, 15-30 min)
O usuário abre o mural para "checar o estado das coisas"
Aba mais usada: HOJE (visão de tarefas do dia)
Interações típicas:
- Marcar tasks como concluídas
- Expandir um flow para ver próximo passo
- Abrir o chat para perguntar algo sobre contexto passado
Duração típica de sessão: 10-20 minutos
│
▼
[4] PERGUNTA PONTUAL AO CHAT (Fase 1)
"O que eu tinha definido sobre a arquitetura do ContextStore?"
Brisa responde com citação de nota de 2 semanas atrás
MOMENTO UAU 2: "Ela encontrou o que eu precisava"
Frequência: 1-3 vezes por semana
│
▼
[5] FIM DO DIA — REFLEXÃO OPCIONAL
Usuário manda no Telegram:
"hoje foi difícil, travei no problema X, mas resolvi Y"
Brisa captura como reflexão, não responde com conselho
Apenas: "Guardei. Boa noite."
Design intencional: sem gamificação, sem "parabéns pela consistência"
│
▼
FIM DO DIA — CICLO SE REPETE
Sessões esperadas por dia: - Mobile (Telegram): 3-8 capturas espalhadas, cada uma < 2 minutos - Desktop (mural): 1 sessão de 10-20 minutos, geralmente manhã ou tarde - Chat com contexto: 2-3 vezes por semana, quando há uma dúvida específica
O mural não é aberto todos os dias. Isso é esperado e saudável. O Telegram é o ponto de contato diário. O mural é aberto quando o usuário quer "ver o estado das coisas", não como hábito diário.
Jornada 3 — Integração Nova (Google Calendar)
TRIGGER: usuário menciona no Telegram "seria legal se você soubesse
minha agenda" ou encontra a opção em Configurações
│
▼
[1] DESCOBRE A OPÇÃO
Via Telegram: "você pode conectar com meu Google Calendar"
Via mural: aba Config → seção "Integrações" → card do Google Calendar
Estado do card: desconectado, com descrição "Veja seus eventos
no mural e nos briefings"
│
▼
[2] INICIA CONEXÃO (1 clique)
Botão "Conectar" abre OAuth do Google em nova aba
Permissões solicitadas: read-only (calendário, sem escrita)
Texto explicativo: "Só leitura. Seus eventos ficam no seu VPS,
não são enviados a terceiros."
Risco: usuário não confia no OAuth — quer saber o que está
autorizando. Mitigação: link "O que esta permissão permite?"
com explicação em linguagem simples.
│
▼
[3] AUTORIZA NO GOOGLE (padrão OAuth)
Tempo: 30-60 segundos
Risco: redirecionamento falha se URL de callback não estiver
configurada. Mitigação: verificar URL de callback no setup inicial
ou mostrar instrução manual como fallback.
│
▼
[4] VOLTA AO MURAL — CONFIRMAÇÃO IMEDIATA
Card do Calendar agora mostra: "Conectado — sincronizando..."
Em 5-10 segundos: "Sincronizado. X eventos encontrados."
MOMENTO UAU: eventos já aparecem no briefing do dia seguinte
│
▼
[5] PRIMEIRA EXPERIÊNCIA COM CALENDÁRIO INTEGRADO
Briefing matinal inclui: "Você tem reunião às 14h com [nome]"
Mural → aba Hoje mostra eventos do dia no topo
MOMENTO: "agora ela sabe minha agenda"
│
▼
FIM DA JORNADA 3 — integração ativa
Contagem de cliques: 3 cliques (Conectar → Autorizar no Google → Voltar). Este é o target. Qualquer configuração adicional deve ser pós-ativação, não pré.
Regra de ouro para todas as integrações: Valor percebido antes de qualquer configuração avançada. O usuário deve ver algo novo no próximo briefing após conectar, sem precisar fazer mais nada.
3. Revisão do Mural Atual (4 abas)
Aba HOJE
O que faz bem: - Hierarquia clara: brisa-says no topo (contexto da IA) → ecos (urgentes) → flow ativo → insights → metas da semana - Componente de flow (portal) é o mais rico visualmente — transmite progresso
O que está desnecessariamente complexo:
- O seer (card de futebol) é contextual demais — aparece mesmo quando não há jogo relevante, gerando ruído
- O oracle-card (insight aleatório) compete com a brisa-says — duas vozes da IA na mesma tela confunde
- A seção de "Pulse" (gráfico de barras) não tem contexto suficiente para o usuário entender o que está medindo
O que remover sem perder valor: - Pulse graph (movido para página de analytics, se existir) - Oracle card duplicado (fundido com brisa-says) - Meta-week bar individual (substituído por indicador simples no topo do flow)
Com o novo produto: A aba Hoje ganha o "Este dia, ano passado" (F3.5) e um link direto para o Chat quando o usuário parece estar buscando contexto (heurística: hora do dia + tarefas abertas).
Aba NEXUS
O que faz bem: - Mapa de nós com SVG links — visualmente elegante e único - Nós coloridos por tipo criam taxonomia visual intuitiva - Click no nó abre painel inline — sem navegação
O que está desnecessariamente complexo: - Os links SVG são decorativos (dasharray animado) — não representam conexões reais de dados - O posicionamento dos nós é estático/hardcoded — não reflete relações reais - Não há interação depois de clicar no nó — o painel não adiciona contexto
O que precisa mudar com o novo produto: - Após Fase 4, o Nexus vira um grafo real com D3.js — os nós e links passam a representar conexões semânticas reais - Antes da Fase 4, o Nexus mantém o mapa visual mas com dados reais de tasks/flows por nó - Risco de expectativa: o mapa atual parece interativo mas não é. Usuário novo pode clicar esperando ver conexões reais. Adicionar estado vazio bem escrito: "Conexões semânticas disponíveis após X notas capturadas."
Aba LORES
O que faz bem:
- Timeline de tarefas concluídas com filtros por categoria
- Componente .tl-item.major para itens importantes — diferenciação visual clara
- Filtros por tag são o único mecanismo de navegação — simples e suficiente por enquanto
O que está desnecessariamente complexo: - Filtros de lore duplicam a lógica de filtros da aba Nexus — mesmos chips, mesma interação - Sem busca textual: para encontrar uma task concluída específica, o usuário tem que rolar ou filtrar
Evolução com novo produto: - Lores absorve parte da Fase 3 (timeline de vida) — os itens do Lores viram a âncora histórica da timeline - Adicionar barra de busca simples (texto) no topo do Lores é quick win de alto impacto
Aba que o usuário vai usar mais com o novo produto: A aba HOJE segue sendo a mais usada diariamente. Com a Fase 1 (chat), o usuário vai abrir uma nova aba /chat que potencialmente compete com a Hoje. Com a Fase 3, a timeline vira a segunda aba mais usada (revisão semanal/mensal).
Aba CONFIG
O que faz bem: - Drag-and-drop para priorização de domínios — interação sofisticada que funciona no mobile - Cards de modo de captura com descrição clara de o que cada modo faz
O que está desnecessariamente complexo: - Configuração de "axes" (eixos de contexto por modo) é cognitivamente pesada — o usuário não sabe o que preencher - Não há indicação de qual configuração está ativa vs. qual é default
Evolução com novo produto: - Config ganha seção "Integrações" com cards para Google Calendar, Google Drive, etc. - Cada integração tem status visual (conectado/desconectado) e botão de ação único
4. Onboarding de Produto (Fase 0 Crítica)
O problema do cold start
Um novo usuário que abre o BrisaVerse sem dados tem uma experiência de "mural vazio". O mapa de nós aparece sem tasks, o nexus parece decorativo, o lores está vazio. Isso é o caminho mais curto para o abandono.
Solução: onboarding como conversa, não como formulário.
Fluxo de onboarding completo
TELA 1 — Boas-vindas (aparece ANTES do mural, só na primeira vez)
┌─────────────────────────────────────────┐
│ │
│ ○ (orb animado) │
│ │
│ "Olá. Sou a Brisa." │
│ │
│ "Sou uma IA que aprende sobre │
│ sua vida e te ajuda a não │
│ perder o fio das coisas." │
│ │
│ "Antes de mostrar seu espaço, │
│ me conta 3 coisas." │
│ │
│ [ Vamos lá → ] │
│ │
└─────────────────────────────────────────┘
TELA 2 — Pergunta 1 (nome)
┌─────────────────────────────────────────┐
│ ← 1 de 3 │
│ │
│ "Qual é o seu nome?" │
│ │
│ [ _________________ ] │
│ │
│ [ Continuar → ] [pular] │
│ │
└─────────────────────────────────────────┘
TELA 3 — Pergunta 2 (domínios)
┌─────────────────────────────────────────┐
│ ← 2 de 3 │
│ │
│ "Quais áreas da vida você quer │
│ acompanhar aqui?" │
│ (escolha até 5) │
│ │
│ [💼 Trabalho] [🏠 Casa] [❤️ Saúde] │
│ [🚀 Projetos] [📚 Estudos] [💰 Finan] │
│ [+ Outro...] │
│ │
│ [ Continuar → ] [pular] │
│ │
└─────────────────────────────────────────┘
TELA 4 — Pergunta 3 (canal preferido)
┌─────────────────────────────────────────┐
│ ← 3 de 3 │
│ │
│ "Como você prefere me falar?" │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 📱 Telegram (recomendado) │ │
│ │ Rápido, funciona no celular │ │
│ └─────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ 🌐 Aqui mesmo (pelo mural) │ │
│ │ Sem app extra necessário │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
SE ESCOLHEU TELEGRAM:
┌─────────────────────────────────────────┐
│ │
│ "Clique no link abaixo para │
│ conectar no Telegram:" │
│ │
│ [ Abrir @BrisaBot no Telegram ] │
│ (abre deep link com token pré- │
│ preenchido) │
│ │
│ "Manda qualquer mensagem lá │
│ quando estiver pronto." │
│ │
│ [ Já conectei — ver meu espaço ] │
│ │
└─────────────────────────────────────────┘
SE ESCOLHEU MURAL:
Vai direto para o mural com o "+" flutuante
pulsando com dica: "Clique aqui para capturar
sua primeira ideia"
TELA FINAL — Mural pré-populado
┌─────────────────────────────────────────┐
│ │
│ ○ "Pronto, [Nome]. Seu espaço está │
│ configurado com [domínios escolh]. │
│ Manda qualquer coisa quando │
│ quiser." │
│ │
│ [mapa de nós com domínios do usuário] │
│ │
│ Nó "Trabalho" já tem dica inline: │
│ "Você ainda não tem itens aqui. │
│ Que tal começar com uma tarefa?" │
│ │
└─────────────────────────────────────────┘
Regras do onboarding
- Máximo 3 perguntas. Qualquer pergunta adicional vai para configurações avançadas acessíveis depois.
- "Pular" sempre visível — nunca forçar resposta. O sistema tem defaults razoáveis.
- Zero jargão técnico. Não mencionar "ContextStore", "embedding", "MCP" no onboarding.
- Primeira confirmação de valor em < 2 minutos. O usuário deve ver o mural com seus dados (mesmo que sejam só os domínios escolhidos) antes de sair da tela de onboarding.
Como mostrar valor antes de ter dados (cold start)
Estratégia 1 — Importação opcional de contexto existente: Depois do onboarding, oferecer: "Você tem tarefas em algum lugar?" com opções: - "Sim, tenho um arquivo de texto" → import de todo.md - "Sim, uso o Google Tasks / Reminders" → pull via API - "Começo do zero" → segue normal
Estratégia 2 — "Exemplo de vida real": Se o usuário não tem dados, mostrar um perfil fictício (Persona Marina, por exemplo) como "demonstração" com toggle "Mostrar exemplo / Mostrar meu espaço". Isso torna o produto "tangível" antes de ter dados reais.
Estratégia 3 — Prompt de primeira captura: Imediatamente após o onboarding, a Brisa faz uma pergunta direta: "Me conta: qual é a coisa mais importante que você precisa fazer essa semana?" A resposta vai direto para o ContextStore como primeira nota — e o mural já mostra 1 item.
5. Telas e Componentes por Sessão (4 Sessões)
Sessão 1 — Fundação + Chat com Contexto (Fase 0 + Fase 1)
Telas a construir:
| Tela / Componente | Propósito | Elementos essenciais |
|---|---|---|
| Onboarding (3 telas) | Ativar usuário novo com mínimo atrito | Pergunta nome, domínios (chips), canal preferido |
/chat (nova página) |
Chat com contexto semântico | Input de texto, histórico da sessão, citações de fontes |
ChatBubble component |
Resposta da Brisa com sources | Texto da resposta + lista colapsável de "Baseado em: [nota X]" |
| Estado vazio do chat | Onboarding do chat | Sugestões de perguntas ("Tente perguntar...") |
| Barra de navegação + ícone Chat | Acesso ao chat | Ícone novo na nav bar (substituir ou adicionar) |
Telas que NÃO precisa construir na Sessão 1: - Página de analytics / métricas - Settings avançados de embedding - Histórico de sessões de chat (pode ser Fase 1.5) - Qualquer visualização de grafo
Momento uau da Sessão 1: Usuário faz uma pergunta sobre algo que escreveu há semanas e a Brisa encontra com citação da fonte. "Ela sabe."
Sessão 2 — Captura Multi-Canal (Fase 2)
Telas a construir:
| Tela / Componente | Propósito | Elementos essenciais |
|---|---|---|
QuickCapture modal |
Captura rápida sem sair do mural | Input textarea, botão enviar, feedback imediato |
| Botão "+" flutuante (melhoria) | Acesso rápido à captura | FAB no canto inferior direito, atalho de teclado (Ctrl+K) |
| Feedback de classificação | Mostrar o que a IA entendeu | Card: "Capturei: [tipo] → [domínio]" com botão de correção |
| Inline keyboard Telegram (correção) | Corrigir classificação errada | 4 botões: Task / Ideia / Reflexão / Evento |
| Estado de processamento de áudio | Transparência no transcurso | "Transcrevendo áudio..." com spinner, depois mostra texto transcrito |
Telas que NÃO precisa construir na Sessão 2: - Página dedicada de "histórico de capturas" - Configuração avançada do Whisper (modelo, idioma) - Dashboard de estatísticas de captura
Momento uau da Sessão 2: Usuário manda áudio de 1 minuto com 3 assuntos misturados e a Brisa separa em 3 itens classificados corretamente, sem intervenção manual.
Sessão 3 — Timeline de Vida (Fase 3)
Telas a construir:
| Tela / Componente | Propósito | Elementos essenciais |
|---|---|---|
/timeline (nova página) |
Visualização cronológica da vida | Scroll vertical por mês, âncoras de mês, ícone por tipo de evento |
TimelineItem component |
Card de item na timeline | Data, título, tipo (ícone), botão expandir |
TimelineItem (expandido) |
Detalhe do evento | Conteúdo completo, campo de edição de importância (0-3) |
| Navegação por mês (prev/next) | Navegar no tempo | Botões anterior/próximo + indicador "Junho 2026" |
| Widget "Este dia, ano passado" | Retenção + memória emocional | Card no topo da aba Hoje com evento de 1 ano atrás |
| Filtro de importância | Reduzir ruído na timeline | Toggle: Todos / Relevantes / Marcos |
| Estado vazio da timeline | Cold start | "Sua história começa aqui. Capture sua primeira reflexão." |
Telas que NÃO precisa construir na Sessão 3: - Edição de eventos na timeline (Fase 4) - Compartilhamento de timeline - Export de dados (PDF, etc.) - Filtros por domínio na timeline (adicionar em Sessão 4 se necessário)
Momento uau da Sessão 3: Usuário abre a timeline pela primeira vez e vê o histórico de tarefas concluídas dos últimos meses num scroll contínuo. "Eu fiz mais coisas do que pensava."
Sessão 4 — Nexus Semântico (Fase 4)
Telas a construir:
| Tela / Componente | Propósito | Elementos essenciais |
|---|---|---|
/nexus (nova página, substitui o mapa atual) |
Grafo de conexões semânticas reais | D3.js force-directed, nós com ícone por tipo, arestas com espessura por score |
NodeDetail drawer |
Detalhe de um nó no grafo | Título, tipo, data, conteúdo, lista de conexões do nó |
ConnectionExplainer |
"Por que estão conectados?" | Card com explicação em 1-2 frases gerada pela IA |
| Filtros do nexus (obrigatórios) | Evitar grafo ilegível | Filtro por período (último mês / 3 meses / tudo) + filtro por tipo |
| Mini-nexus no painel de nó do mural | Conexões cruzadas no contexto do domínio | Lista "Top 5 conexões deste domínio" no painel inline |
| Estado de construção do nexus | Transparência sobre o processo | "Analisando X notas... Encontrei Y conexões." com progress bar |
| Estado vazio do nexus | < 10 notas ainda | "Capture mais algumas ideias para eu encontrar conexões." |
Telas que NÃO precisa construir na Sessão 4: - Edição manual de conexões (anti-padrão: o valor é nas conexões automáticas) - Exportação do grafo como imagem - Nexus compartilhável (multi-usuário é Fase 5+) - Configuração avançada de threshold de similaridade (expor só em Config avançado)
Momento uau da Sessão 4: Usuário clica em uma conexão e a Brisa explica em 1 frase por que duas notas de contextos completamente diferentes estão relacionadas — e faz sentido.
6. Wireframes em Texto (ASCII Mockups)
Wireframe 1 — Tela de Chat (/chat)
┌─────────────────────────────────────────┐
│ ← Chat com a Brisa [⌘K nova] │
├─────────────────────────────────────────┤
│ │
│ ─── Sugestões para começar ────────── │
│ │
│ ╔═══════════════════════════════════╗ │
│ ║ "O que eu estava pensando sobre ║ │
│ ║ [último projeto ativo]?" ║ │
│ ╚═══════════════════════════════════╝ │
│ │
│ ╔═══════════════════════════════════╗ │
│ ║ "O que ficou pendente essa ║ │
│ ║ semana?" ║ │
│ ╚═══════════════════════════════════╝ │
│ │
│ ╔═══════════════════════════════════╗ │
│ ║ "Me faz um resumo do mês passado" ║ │
│ ╚═══════════════════════════════════╝ │
│ │
├─────────────────────────────────────────┤
│ [Digite uma pergunta... ] [→] │
└─────────────────────────────────────────┘
── APÓS ENVIAR PERGUNTA ──────────────────
┌─────────────────────────────────────────┐
│ ← Chat com a Brisa [⌘K nova] │
├─────────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ O que eu │ │
│ │ defini sobre │ │
│ │ o ContextStore│ │
│ └───────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ ○ Brisa │ │
│ │ │ │
│ │ Encontrei 3 notas relevantes. │ │
│ │ Na nota de 03/06 você definiu │ │
│ │ usar sqlite-vec para embeddings │ │
│ │ e abstrair o provider em │ │
│ │ embeddings.py para trocar │ │
│ │ depois. │ │
│ │ │ │
│ │ ▼ Baseado em (3 fontes) │ │
│ │ · nota · 03/06 · ContextStore │ │
│ │ · nota · 28/05 · Arquitetura │ │
│ │ · task · F0.1 · Migration │ │
│ └─────────────────────────────────┘ │
│ │
│ [Continuar perguntando... ] [→] │
└─────────────────────────────────────────┘
Notas de design: - Citações de fontes são colapsadas por padrão — não poluem a resposta - Cada fonte é clicável e abre o item original - O histórico da sessão está acima, com scroll, mas a sessão não persiste entre reloads (até F1.3)
Wireframe 2 — Quick Capture Modal
── TRIGGER: clique no "+" flutuante ──────
┌─────────────────────────────────────────┐
│ ████████████████████████████████████ │
│ ████████████████████████████████████ │ (overlay escuro)
│ ████████████████████████████████████ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ ≡ (drag handle) │ │
│ │ │ │
│ │ Captura rápida │ │
│ │ A Brisa vai classificar │ │
│ │ │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ O que está na sua │ │ │
│ │ │ cabeça agora? │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────┘ │ │
│ │ │ │
│ │ [🎤 Áudio] [→ Enviar] │ │
│ │ │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
── APÓS ENVIAR ───────────────────────────
│ ┌─────────────────────────────────┐ │
│ │ ✓ Capturado! │ │
│ │ │ │
│ │ 📋 Task → Projetos │ │
│ │ "Ligar para seguradora" │ │
│ │ │ │
│ │ [Corrigir tipo] [Ver no mural]│ │
│ │ │ │
│ │ (fecha em 3s automaticamente) │ │
│ └─────────────────────────────────┘ │
Notas de design: - Modal bottom sheet, como o padrão atual do mural - Sem seleção de categoria pelo usuário — a IA classifica - Feedback imediato com a classificação feita - Botão "Corrigir tipo" abre seletor rápido (Task / Ideia / Reflexão / Evento) - Auto-fecha após 3 segundos se o usuário não interagir
Wireframe 3 — Timeline de Vida (/timeline)
┌─────────────────────────────────────────┐
│ ← Sua história │
│ [Todos ▼] [← Jun 2026 →] │
├─────────────────────────────────────────┤
│ │
│ ── Junho 2026 ───────────────────── │
│ │ │
│ ● 19/06 · quinta-feira │
│ │ ┌───────────────────────────────┐ │
│ │ │ 🚀 Defini arquitetura │ │
│ │ │ do BrisaVerse (Fase 0) │ │
│ │ │ [flow] [nota] │ │
│ │ └───────────────────────────────┘ │
│ │ │
│ ◉ 15/06 · domingo ← MARCO │
│ │ ┌───────────────────────────────┐ │
│ │ │ ✨ Stronda Cup versão 1.0 │ │
│ │ │ lançada │ │
│ │ │ [flow concluído] │ │
│ │ └───────────────────────────────┘ │
│ │ │
│ ● 12/06 · quinta │
│ │ ┌───────────────────────────────┐ │
│ │ │ 📝 Reflexão sobre foco │ │
│ │ │ "Percebei que divido │ │
│ │ │ muito..." │ │
│ │ └───────────────────────────────┘ │
│ │ │
│ ── Maio 2026 ────────────────────── │
│ │ │
│ ● ... │
│ │
│ │
│ ───────────────────────────────────── │
│ [← Maio] [Julho →] │
└─────────────────────────────────────────┘
Notas de design: - Linha vertical à esquerda como fio condutor - Nó maior (◉) para marcos — diferenciação visual clara - Data + dia da semana (não só data) — mais humano - Filtro de importância no topo: "Todos / Relevantes / Marcos" - Navegação por mês com botões prev/next, sem calendar picker complexo - Cada card é clicável e expande inline (sem nova página)
Wireframe 4 — Tela de Integrações (Config)
┌─────────────────────────────────────────┐
│ ← Configurações │
├─────────────────────────────────────────┤
│ │
│ Integrações │
│ Conecte fontes de contexto externas │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 📅 Google Calendar ✓ Conectado│ │
│ │ Última sync: há 5 min │ │
│ │ [Desconectar] │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 📧 Gmail Desconect.│ │
│ │ Receba emails como contexto │ │
│ │ [Conectar] │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 📁 Google Drive Desconect.│ │
│ │ Documentos como contexto │ │
│ │ [Conectar] │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 💬 WhatsApp Em breve │ │
│ │ Captura por WhatsApp │ │
│ └─────────────────────────────────┘ │
│ │
│ ───────────────────────────────────── │
│ │
│ Modelo de embedding │
│ ○ OpenAI (text-embedding-3-small) │
│ ○ Local (sentence-transformers) [Beta] │
│ │
└─────────────────────────────────────────┘
7. Anti-padrões de UX a Evitar
Com base nos concorrentes analisados (Notion, Obsidian, Logseq) e nos princípios do BrisaVerse:
Anti-padrão 1 — "Configure antes de usar" (Obsidian)
O problema: Obsidian exige que o usuário entenda o modelo mental de vaults, plugins e links antes de capturar qualquer coisa. A curva de aprendizado é de dias. Como o BrisaVerse evita: Onboarding de 3 perguntas. O sistema funciona no modo zero-config desde o primeiro dia. Configuração avançada existe mas não é pré-requisito.
Anti-padrão 2 — "Você precisa decidir onde guardar" (Notion)
O problema: Notion tem databases, páginas, sub-páginas, blocos. Cada captura exige uma decisão de onde colocar — mata o fluxo de pensamento. Como o BrisaVerse evita: A IA classifica. O usuário manda texto livre e a Brisa decide onde vai. O usuário pode corrigir depois, mas não precisa decidir na hora.
Anti-padrão 3 — "Streaks e gamificação" (Notion, Habitica-style)
O problema: Sistemas que mostram "você não usou por 3 dias" ou "sua sequência foi quebrada" criam culpa e ansiedade. O usuário evita abrir o app para não ver o aviso. Como o BrisaVerse evita: Zero streaks, zero percentuais de conclusão no default. O princípio "interface que convida, não que exige" é inegociável. Métricas de progresso existem (ex: barra de flow) mas são sobre o projeto, não sobre o comportamento do usuário.
Anti-padrão 4 — "Grafo bonito mas inútil" (Obsidian/Logseq)
O problema: O grafo do Obsidian é visualmente impressionante na demo, mas poucos usuários o utilizam para encontrar informação real. Virou feature de marketing. Como o BrisaVerse evita: O Nexus é ancorado em casos de uso reais: "encontrar uma nota que sei que escrevi", "ver o que está conectado com esse projeto". O grafo não existe sem filtros. A feature de "Por que estão conectados?" garante que cada conexão tem significado explícito.
Anti-padrão 5 — "Hierarquia infinita de pastas" (Notion, Logseq)
O problema: Quando o usuário pode criar pastas infinitas, cria. E depois perde tempo categorizando em vez de capturando. "Onde vou colocar isso: Projetos > Trabalho > Cliente X > 2026 > Q2?" Como o BrisaVerse evita: Estrutura plana com domínios (máximo 5-7). Sem sub-domínios. A profundidade vem de tags e conexões semânticas, não de hierarquia de pastas.
Anti-padrão 6 — "Cloud-first com promessa de privacidade" (Mem.ai, Reflect)
O problema: Produtos que afirmam ser privados mas sincronizam tudo para servidores de terceiros. Após a aquisição do Limitless pela Meta, usuários estão mais atentos a isso. Como o BrisaVerse evita: Local-first não é feature, é arquitetura. O usuário controla o VPS. Integrações com Google são read-only e explicitamente opt-in. A UI comunica isso: "seus dados ficam no seu servidor" aparece na tela de onboarding.
Anti-padrão 7 — "Sync infinito que trava" (Obsidian mobile)
O problema: Obsidian mobile + sync tem reputação de ser lento e quebrar. O usuário perde a confiança no sistema. Como o BrisaVerse evita: O canal mobile primário é o Telegram — não precisa de sync. O mural é desktop-first. A versão mobile do mural é leitura/consulta, não captura (a captura vai pelo Telegram).
Anti-padrão 8 — "IA que responde sem contexto" (ChatGPT genérico)
O problema: Perguntar para uma IA genérica sobre seus projetos resulta em respostas inventadas ou irrelevantes. O usuário perde confiança. Como o BrisaVerse evita: Toda resposta do chat inclui citações das fontes usadas. Se não há contexto relevante, a Brisa diz explicitamente: "Não encontrei notas sobre isso. Quer que eu responda com conhecimento geral?" — sem inventar contexto.
8. Métricas de UX (local-first, sem analytics externos)
Como o BrisaVerse é local-first e não deve ter telemetria externa, as métricas precisam ser auto-reportadas ou auto-medidas no próprio sistema.
Métricas estruturais (medidas pelo sistema, sem esforço do usuário)
M1 — Taxa de captura / abandono no onboarding
- Como medir: flag onboarding_completed no ContextStore, definida na última tela
- O que indica: se a taxa for < 80%, o onboarding está com fricção demais
- Como acessar: /api/metrics (endpoint interno)
M2 — Frequência de captura - Como medir: contagem de eventos por dia nos últimos 30 dias - O que indica: se cair para 0 por mais de 3 dias, o usuário pode estar em churn - Visualização: sparkline no Config (para o próprio usuário ver sua atividade)
M3 — Latência do chat (P95)
- Como medir: log de timestamp start/end em cada chamada /api/chat
- Meta: < 3 segundos P95
- Como acessar: log no container ou endpoint /api/health
M4 — Taxa de correção de classificação - Como medir: conta quantas vezes o botão "Corrigir tipo" é usado vs. total de capturas - O que indica: se > 30%, a classificação automática precisa ser melhorada - Meta: < 15% de correções manuais
M5 — Abertura de fontes no chat - Como medir: log de clicks em "Ver fonte" nos cards de resposta - O que indica: se o usuário nunca abre as fontes, ou confia cegamente na IA ou as fontes não são relevantes - Meta qualitativa: > 20% das respostas têm ao menos uma fonte aberta
Métricas qualitativas (auto-reportadas, mensais)
Q1 — "Encontrei o que procurava" - Como medir: botão 👍/👎 no final de cada resposta do chat - Meta: > 80% de thumbs up - Implementação: botões simples, sem formulário, resultado salvo localmente
Q2 — Conexões do nexus que "fazem sentido" - Como medir: botão "Faz sentido / Não faz sentido" nas conexões do grafo - Meta: > 70% de "faz sentido" nas primeiras 4 semanas após Fase 4 - Sem esse dado, não há base para ajustar o threshold de similaridade
Q3 — A métrica qualitativa que mais importa Uma vez por mês, o próprio usuário testa: "Qual era meu plano para [projeto X] há 3 meses?" Se consegue responder em < 30 segundos usando o BrisaVerse, o produto está funcionando como segunda mente. Não há como automatizar isso — é uma checagem intencional.
Dashboard de saúde (página /metrics no mural)
┌─────────────────────────────────────────┐
│ Saúde do sistema │
├─────────────────────────────────────────┤
│ │
│ Sua memória │
│ ████████████░░░░░░ 847 notas │
│ Crescimento: +23 esta semana │
│ │
│ Latência do chat │
│ P50: 1.2s P95: 2.8s ✓ OK │
│ │
│ Qualidade das respostas (30 dias) │
│ 👍 91% 👎 9% (43 avaliações) │
│ │
│ Uso de espaço │
│ context.db: 124MB │
│ embeddings: 89MB │
│ Total: 213MB │
│ │
└─────────────────────────────────────────┘
9. Critérios de Aceite de UX por Fase
Fase 0 — Critérios de UX
- [ ] Novo usuário consegue completar o onboarding em < 5 minutos sem documentação adicional
- [ ] Mural carrega em < 500ms em conexão local (medido com DevTools)
- [ ] CSS extraído para arquivo separado — nenhuma regra inline no HTML principal
- [ ] Todos os estados de "vazio" têm texto explicativo (sem telas em branco)
- [ ] Onboarding pode ser pulado completamente e o mural ainda funciona
Fase 1 — Critérios de UX (Chat)
- [ ] Usuário consegue fazer uma pergunta e receber resposta com citação de fonte em < 30 segundos
- [ ] Respostas com zero contexto relevante NUNCA inventam informação — dizem explicitamente que não encontraram
- [ ] A fonte citada é clicável e leva ao item original (nota / task / evento)
- [ ] O chat tem estados claros: ocioso / digitando / buscando contexto / respondendo (com streaming)
- [ ] Não há limite mínimo de dados para usar o chat — funciona com 0 notas (com mensagem de estado vazio)
- [ ] Interface do chat funciona em mobile (Telegram WebApp ou browser mobile) sem horizontal scroll
Fase 2 — Critérios de UX (Captura)
- [ ] Quick capture abre em < 200ms após clique no "+"
- [ ] Modal de captura fecha automaticamente após confirmação (auto-dismiss em 3s)
- [ ] Classificação automática tem feedback visual em < 2 segundos
- [ ] Botão de correção de tipo está visível sem scroll
- [ ] Transcrição de áudio completa em < 30 segundos para audios de até 2 minutos
- [ ] O usuário recebe confirmação de áudio transcrito com o texto completo (para revisar)
Fase 3 — Critérios de UX (Timeline)
- [ ] Timeline carrega o mês atual em < 1 segundo
- [ ] Navegação entre meses não recarrega a página — apenas substitui o conteúdo (SPA-like)
- [ ] Distinção visual clara entre evento cotidiano e marco (tamanho, cor, ícone diferentes)
- [ ] Timeline não mostra mensagem de erro para períodos sem dados — mostra estado vazio contextual
- [ ] Widget "Este dia, ano passado" não aparece se não há dados de um ano atrás
- [ ] Usuário pode editar a importância de um evento diretamente na timeline (sem ir para outra tela)
Fase 4 — Critérios de UX (Nexus)
- [ ] Grafo nunca renderiza sem filtro ativo (sempre começa com período = "último mês")
- [ ] Cada conexão tem explicação disponível em 1 clique
- [ ] Grafo com > 100 nós ainda é navegável (não trava o browser)
- [ ] Estado "nexus sendo construído" é comunicado enquanto o job de embeddings roda
- [ ] Taxa de "conexão faz sentido" > 70% medida nos primeiros 30 dias (via botão de feedback)
- [ ] Usuário consegue encontrar uma nota específica usando o nexus em < 2 minutos
10. O Diferencial de UX do BrisaVerse
O que separa o BrisaVerse de todos os concorrentes na experiência, em ordem de impacto:
1. A IA conhece você de verdade. Não é uma IA genérica com memória simulada. É uma IA que acessa seu histórico real, cita as fontes, e é transparente sobre o que sabe e o que não sabe.
2. Você captura em texto livre e a IA organiza. Nenhum campo obrigatório, nenhuma categoria manual. Isso remove a barreira que destrói 90% dos sistemas de PKM — a decisão de onde colocar no momento em que você está pensando.
3. Os dados são seus, no seu servidor. Esse não é marketing — é arquitetura. O usuário pode desligar o servidor e os dados continuam existindo. Pode mudar o plano de cloud sem perder contexto. Isso é único no mercado pós-Limitless.
4. A interface é calma mesmo na complexidade. Um usuário com 50 tasks atrasadas e 3 flows travados ainda vê uma tela que convida, não que condena. Isso é raro em ferramentas de produtividade.
5. O canal de entrada é onde o usuário já está. Telegram não é uma escolha arbitrária — é o canal que o usuário já abre dezenas de vezes por dia. Zero fricção de hábito.
Documento gerado por revisão PO sênior — BrisaVerse UX Plan v1.0 — 2026-06-20
ADENDOS — Revisão UX Externa (2026-06-20)
Ponto de Atenção 1 — Fase 3 (Timeline): Armadilha da Quantidade
Quando a timeline acumular 50+ capturas por semana, o scroll vira ruído visual.
Fix:
- Default da visualização mensal: mostrar apenas importance >= 2
- Micro-eventos (importance 0-1) colapsados por padrão, expansíveis com tap
- Filtro de importância já previsto no schema — garantir que está no UI desde o primeiro dia da Timeline
[Mês] ▼
├── [Evento importante] ← importance 3
├── [Decisão] ← importance 2
└── [+ 23 micro-eventos] ← tap pra expandir
Ponto de Atenção 2 — Fase 4 (Nexus): D3.js force-directed no mobile
Grafos de força física no browser mobile = CPU spike + bateria drenada.
Fix obrigatório: - Limite rígido de 30 nós renderizados por vez (top conectados à busca/contexto atual) - Breakpoint mobile (< 768px): renderizar versão lista em vez de grafo - Grafo D3.js apenas no desktop
Desktop: grafo força-dirigido, até 30 nós
Mobile: lista de conexões ordenada por relevância
Validação das Personas
Persona 3 — Rafael (ADHD + WhatsApp) é o teste de fogo real: - Se a captura por áudio do WhatsApp funcionar sem fricção para o Rafael, está pronto para todos - Critério de aceite: áudio de 2 min → classificado + visível no mural em < 10s, sem ação manual do usuário
Ponto de Atenção 3 — Fase 2: Transparência do Áudio (Whisper)
Usuário manda áudio longo → 15s de silêncio → ansiedade.
Fix obrigatório:
# bot/handler.py — ao receber áudio
await bot.send_chat_action(chat_id, "typing")
# ou mensagem imediata:
await bot.reply("A Brisa está ouvindo... ⏳")
# depois transcreve + classifica + confirma
Fluxo de feedback: 1. Áudio recebido → "A Brisa está ouvindo... ⏳" (imediato) 2. Transcrição completa → "Captei: [resumo do que entendeu]" 3. Classificação → "Adicionei: 2 tasks, 1 ideia"