A interface após o chatbot
A caixa que ensinou toda a gente a perguntar
O chatbot fez algo importante. Deu às pessoas comuns uma forma de tocar num modelo poderoso sem aprender uma nova superfície de controlo. Escreva um pedido. Receba uma resposta. Pergunte de novo. Essa simplicidade importava. Fez com que a IA parecesse menos um instrumento de laboratório e mais um colega que tinha lido demais e, de vez em quando, inventava coisas com uma postura impecável. Durante algum tempo, a caixa de texto em branco foi exatamente a porta certa.
Depois, as equipas tentaram fazer trabalho sério através dessa porta. Redigir uma política, verificar um registo, comparar fornecedores, preparar um plano de cuidados, fazer a triagem de um incidente, rever um contrato, investigar uma reclamação, fazer um horário, conciliar dados de origem. A caixa de chat podia ajudar, mas a interação começou a ranger. O estado importante vivia numa transcrição que se desenrolava. As provas de origem misturavam-se com a conversa. As ações estavam escondidas dentro da prosa. As correções apareciam como mais mensagens. O utilizador tinha de se lembrar do que tinha sido decidido, do que ainda era rascunho e de qual resposta tinha substituído silenciosamente outra. A interface tinha-se tornado uma reunião sem atas.
O chat é uma boa interface para perguntar, explorar e negociar significado. É uma interface fraca para operar. O trabalho precisa de estado, estrutura, controlos, proveniência, comparação, anulação, aprovação, restrições e visibilidade partilhada. Um fluxo de trabalho sério não pode depender de alguém percorrer o ecrã para cima para descobrir se o modelo prometeu usar a folha de cálculo antiga ou a nova. Isso não é colaboração. Isso é arqueologia com um cursor.
A interface depois do chatbot não vai abandonar a linguagem. A linguagem é demasiado útil. Vai colocar a linguagem no seu devido lugar: como um modo de entrada e saída entre formulários, tabelas, cronologias, mapas, telas, inspetores, cursores, painéis de origem, filas, aprovações e simulações. O futuro não é menos conversacional. É menos preso na conversa.
O chat esconde o estado à vista de todos
A transcrição é um mecanismo de armazenamento sedutor porque parece completa. Tudo o que foi dito está lá. O problema é que o trabalho não é simplesmente o que foi dito. O trabalho tem estados. Uma cláusula é rascunho ou aceite. Uma fonte está dentro ou fora do âmbito. Uma tarefa está bloqueada ou pronta. Um risco está aberto ou mitigado. Um número veio de um ficheiro, de uma suposição ou de um cálculo. Uma decisão foi proposta, rejeitada, escalada ou aplicada. O chat pode mencionar esses estados, mas mencionar não é gerir.
Quando o estado vive apenas na conversa, os utilizadores tornam-se a máquina de estados. Lembram-se de que a segunda resposta foi melhor do que a primeira, de que o modelo usou o conjunto de dados errado até ser corrigido, de que o último parágrafo ainda precisa de revisão jurídica, de que a tabela está final exceto por duas linhas, e de que a ação ainda não deve ser executada. As pessoas conseguem fazer isto numa troca curta. Não o conseguem fazer de forma fiável numa equipa, ao longo de um mês, ou num processo regulado. Os seres humanos são excelentes a compreender significado. São bases de dados medíocres com sentimentos.
A interface pós-chat torna o estado visível. Mostra o conjunto de trabalho atual, as alterações aceites, as perguntas por resolver, o estado das fontes, a confiança, as aprovações, os prazos e as próximas ações. Separa a conversa do artefacto. O utilizador pode discutir um contrato em linguagem natural, mas a superfície do contrato mostra quais as cláusulas que mudaram. O utilizador pode pedir um rascunho de plano de cuidados, mas a superfície do plano mostra medicação, riscos, consultas, evidências e conflitos por resolver. A conversa ajuda. A interface mantém a pontuação.
Esta separação também protege a colaboração. Um colega que chegue mais tarde não deve precisar de ler quarenta mensagens para saber o que mudou. Um auditor não deve precisar de toda a conversa para ver a decisão. Um gestor não deve depender da última resposta do modelo como registo. O artefacto precisa do seu próprio estado, versão e proveniência. O chat pode narrar o trabalho. Não deve ser o único sítio onde o trabalho existe.
A resposta não é um balão de chat melhor
Muitas melhorias nos chatbots tentam tornar o balão mais inteligente: citações, botões, memória, sugestões, anexos de ficheiros, chamadas de funções, voz, avatares, formatação mais útil. Estas podem melhorar a experiência. Não resolvem o desfasamento mais profundo. Um fluxo de trabalho não é uma pilha de mensagens com acessórios. É um conjunto de objetos, restrições, decisões e ações que mudam ao longo do tempo.
Considere a análise de aprovisionamento. Uma interface de chat pode resumir fornecedores, comparar critérios e responder a perguntas. Útil. Mas o utilizador também precisa de uma tabela de comparação, ponderação ajustável, documentos de origem, conflitos, notas de risco, estado de aprovação, restrições orçamentais e um registo exportável. Se tudo isto for espremido para uma conversa, o utilizador gasta energia a reconstruir a estrutura que o sistema poderia ter mostrado diretamente. É assim que um assistente se torna num spreadsheet muito articulado que se recusa a ser um spreadsheet.
Ou considere a resposta a incidentes. O chat pode ajudar a fazer perguntas de diagnóstico e a redigir atualizações. Mas os intervenientes precisam de um cronograma, hipóteses em aberto, sistemas afetados, responsáveis, evidências, decisões, comunicações e ações reversíveis. Uma transcrição de chat é demasiado linear para o trabalho paralelo de uma crise. Mistura especulação com factos confirmados, a menos que seja cuidadosamente gerida. Torna difícil ver o que ainda é desconhecido. Durante um incidente, a interface deve reduzir a carga cognitiva, não transformar a resposta numa competição de profundidade de scroll.
A melhor direção são as superfícies de tarefa. Cada superfície dá ao modelo um papel dentro de um padrão de trabalho reconhecível: redigir, comparar, investigar, reconciliar, planear, rever, encaminhar, simular. A linguagem continua disponível, mas a superfície fornece os objetos e os controlos que a tarefa exige naturalmente. O utilizador deixa de pedir ao chatbot para se tornar a aplicação inteira. A aplicação torna-se capaz de IA onde a tarefa beneficia disso.
Iniciativa mista precisa de pegas
As interfaces de IA são frequentemente descritas como de iniciativa mista: o humano e o sistema alternam na liderança. Essa expressão é útil, mas pode tornar-se vaga. A iniciativa mista exige pegas. O utilizador tem de poder definir o âmbito, fixar factos, rejeitar pressupostos, escolher fontes, alterar a tolerância ao risco, congelar partes de um artefacto, pedir alternativas, comparar versões e aprovar ações. O sistema tem de poder propor, avisar, fazer perguntas de esclarecimento, abster-se e explicar por que precisa de mais evidências.
No chat, muitas dessas pegas transformam-se em palavras. Não altere a segunda secção. Use apenas estas fontes. Seja mais conservador. Mantenha a tabela, mas ajuste a pontuação. Explique a diferença entre a versão três e a quatro. Isto funciona até deixar de funcionar. Instruções em prosa podem ser ignoradas, mal interpretadas, contraditas ou soterradas. Um controlo que importa repetidamente deve tornar-se visível. Se um utilizador precisar de dizer não toques neste parágrafo cinco vezes, a interface precisa de um bloqueio, não de um parágrafo mais obediente sobre bloqueios.
Boas pegas reduzem o fardo dos prompts. Um seletor de âmbito é melhor do que um parágrafo a explicar o âmbito. Um painel de fontes é melhor do que colar nomes de ficheiros repetidamente. Um controlo deslizante de risco é melhor do que adjetivos vagos como cauteloso ou ousado quando o domínio pode definir o que esses significam. Uma comparação de versões é melhor do que perguntar o que mudou. Um botão de aprovação estruturado é melhor do que aplica isto, por favor, mas apenas as partes seguras. A linguagem continua a ser a camada flexível. Os controlos carregam a intenção repetida.
As pegas também tornam a responsabilidade mais clara. Se o utilizador selecionou fontes, o registo pode mostrar isso. Se o sistema ignorou uma fonte excluída, isso é um defeito. Se uma definição de risco estava alta, a revisão a jusante pode compreender por que o modelo sugeriu uma opção mais agressiva. Se uma ação exigiu aprovação, a interface pode provar quem a aprovou e com que evidências. Isto não é burocracia de interface. É a diferença entre colaboração e vibrações com um botão de enviar.
As fontes devem ser objetos, não decorações
As citações no chat são um começo, mas muitas vezes são demasiado fracas para trabalho sério. Uma nota de rodapé no fim de um parágrafo gerado não diz ao utilizador qual afirmação veio de qual fonte, se a fonte era atual, se uma fonte melhor foi excluída ou se duas fontes estavam em conflito. Pode tranquilizar mais do que informar. Uma citação pode tornar-se uma pequena fantasia de autoridade se a interface não permitir ao utilizador inspecionar a relação com a fonte.
As interfaces pós-chat tratam as fontes como objetos. Mostram o conjunto de fontes, a atualidade, as permissões, os campos extraídos, as passagens conflituosas, a confiança e a linhagem. Permitem que os utilizadores incluam, excluam, fixem, comparem e contestem fontes. Mostram quando uma afirmação não tem suporte. Distinguem registos oficiais de material de contexto, notas de utilizador, valores inferidos e suposições do modelo. Uma fonte não é uma ligação decorativa. É um participante no trabalho.
Isto é importante porque os sistemas de IA falham muitas vezes na fronteira entre informação disponível e informação justificada. Podem produzir uma resposta fluente a partir de provas fracas. Podem misturar documentos antigos e novos. Podem tratar um rascunho como política. Podem inferir um número que devia ter sido calculado. A interface deve tornar essas fronteiras visíveis. Deve ajudar o utilizador a perguntar: o que usaste, o que não usaste, o que conflitua, o que falta e o que mudaria se esta fonte fosse removida.
Quando as fontes se tornam objetos, a revisão torna-se mais rápida e melhor. Um advogado pode ver que cláusula suporta uma alteração sugerida. Um clínico pode ver que observação moldou um plano. Um engenheiro pode ver que linha de registo suporta um diagnóstico. Uma equipa de compras pode ver que documento de fornecedor contribuiu para uma pontuação. O utilizador deixa de ler prosa e esperar que o sistema de recuperação invisível se tenha comportado bem. A esperança é agradável. Não é uma estratégia de gestão de fontes.
Da resposta ao artefacto
A unidade natural do chatbot é uma resposta. A unidade natural do trabalho é muitas vezes um artefacto. Um relatório, plano, contrato, calendário, processo, ficha de modelo, memorando de decisão, registo de riscos, consulta, design, orçamento ou bilhete de serviço tem estrutura para além de uma réplica. Tem secções, campos, responsáveis, estados, dependências, versões e públicos. A interface depois do chatbot trata o resultado da IA como uma alteração proposta a um artefacto, não como o próprio artefacto.
Esta distinção muda a interação. Em vez de aceitar uma resposta inteira, o utilizador pode aceitar um parágrafo, rejeitar uma afirmação, fixar uma fonte, dividir uma tarefa, alterar um campo, pedir alternativas para uma secção ou aplicar uma transformação a linhas selecionadas. O sistema pode realçar partes incertas, marcar afirmações sem suporte, mostrar o que mudou e preservar opções rejeitadas. O utilizador trabalha com um objeto, não com uma transcrição.
O design centrado nos artefactos também suporta automação parcial. O modelo pode redigir o resumo, mas não a recomendação. Pode extrair campos, mas não submeter o caso. Pode propor alterações ao calendário, mas não notificar os participantes. Pode classificar riscos, mas não aprovar a mitigação. A interface pode tornar estes limites explícitos. Uma interface de conversa pode indicar que não vai tomar uma ação. Uma superfície de tarefas pode impedir a ação, a menos que o controlo, o papel e as evidências corretos estejam presentes.
Desfazer torna-se central. Quando a IA atua sobre artefactos, os utilizadores precisam de operações reversíveis, diferenças, instantâneos e registos de alterações aplicadas. As pessoas estão mais dispostas a experimentar quando conseguem ver e reverter alterações. Estão menos dispostas quando o modelo emite uma substituição polida de tudo e o único mecanismo de recuperação é copiar de uma mensagem anterior. O controlo de versões não é um luxo de programadores aqui. É um padrão de design para a coragem.
Personalização não é o mesmo que memória
Muitos chatbots dependem da memória como forma de melhorar a utilidade. Lembra-te das minhas preferências. Lembra-te dos meus projetos. Lembra-te do meu tom. A memória pode ajudar, mas as interfaces pós-conversa precisam de uma distinção mais disciplinada entre personalização, estado da sessão, contexto organizacional e registo autoritativo. Um modelo lembrar-se de que um utilizador gosta de resumos curtos é diferente de um processo registar que uma decisão foi aprovada. Misturar tudo isto é como a conveniência se torna evidência por acidente.
Para trabalho sério, a interface deve mostrar o que recorda e porquê. As preferências pessoais devem ser editáveis e de baixo risco. O contexto do projeto deve ser visível e delimitado. Os registos autoritativos devem ser geridos. Factos sensíveis não devem tornar-se memória ambiente simplesmente por terem aparecido numa conversa. Um utilizador deve poder perguntar ao sistema porque está a comportar-se de determinada forma e ver se a resposta vem da preferência, da política, do histórico, dos dados de origem ou da inferência do modelo.
A memória também precisa de esquecimento. Uma suposição cancelada não deve assombrar recomendações futuras. Uma fonte de rascunho não deve tornar-se contexto permanente. Uma correção passada do utilizador não deve aplicar-se fora do seu domínio. Uma restrição temporária do projeto deve expirar. As interfaces de conversa muitas vezes fazem a memória parecer mágica. As interfaces de trabalho precisam de uma memória suficientemente monótona para ser administrada. A memória monótona é a que evita ter de explicar a um cliente porque é que uma nota privada do trimestre passado reapareceu no rascunho público deste trimestre.
A interface pós-conversa separa, portanto, os controlos de memória. O que está fixado para esta tarefa. O que está guardado para este artefacto. O que é uma preferência pessoal. O que é política organizacional. O que é temporário. O que é eliminado. O que é herdado. O utilizador não deve precisar de fazer um exorcismo por prompt. Deve ter controlos.
A interface torna-se uma superfície de governação
À medida que a IA passa de responder a perguntas para moldar o trabalho, a interface torna-se uma superfície de governação. Decide o que os utilizadores podem ver, o que podem ignorar, quais os padrões que parecem normais, quais as ações que exigem aprovação, quais as evidências apresentadas, qual a incerteza admitida e quais os registos que sobrevivem. A governação não é apenas texto de política. É também a forma do ecrã.
Isto torna o design de interfaces mais consequente do que muitas organizações esperam. Um painel de fontes oculto enfraquece a revisão. Um crachá de confiança vago cria falsa precisão. Um caminho de aprovação predefinido aumenta o enviesamento de automação. Uma diferença em falta transforma o texto gerado num exercício de confiança. Uma rota de escalonamento enterrada desencoraja o cuidado. Um botão de ação brilhante pode sobrepor-se a um parágrafo de cautela. Os ecrãs têm política, mesmo quando usam cinzento neutro.
Uma boa governança de superfícies torna visível o atrito importante. Abranda ações irreversíveis. Exige provas para mudanças consequentes. Mostra o contexto em falta. Mantém as sugestões rejeitadas disponíveis para revisão. Separa o estado de rascunho do estado aplicado. Facilita a escalada quando o sistema está incerto. Não envergonha o utilizador por recusar a automatização. A melhor interface de IA pode, por vezes, ser aquela que diz não há provas suficientes e depois dá ao utilizador um próximo passo produtivo.
É também aqui que a acessibilidade importa. Uma superfície de IA pós-chat não pode assumir que todos os utilizadores querem prosa longa, tabelas densas ou atalhos de teclado escondidos. Deve apoiar a leitura rápida, o controlo por teclado, os leitores de ecrã, um foco claro, etiquetas compreensíveis e um comportamento previsível. O trabalho sério é feito por pessoas cansadas em dias normais. A interface deve ajudá-las, não criar uma pequena pista de obstáculos cognitivos e chamar-lhe inovação.
Porque é que o chat vai ficar
Nada disto significa que o chat desapareça. Continuará a ser valioso porque a linguagem é a interface mais flexível que os humanos têm. Usamo-la para explicar objetivos, negociar ambiguidades, perguntar porquê, descrever exceções e inventar novas tarefas. O chat é especialmente útil no início do trabalho, quando o utilizador ainda não conhece a estrutura. Também é útil nas margens, onde os controlos fixos se tornariam um museu de todas as exceções possíveis.
O erro é tratar o chat como o estado final universal porque foi a demonstração universal. A primeira folha de cálculo não eliminou os sistemas de contabilidade. A primeira caixa de pesquisa não eliminou a arquitetura da informação. O primeiro mapa não eliminou o software de logística. Os primitivos de interface úteis tornam-se parte de ferramentas mais ricas. O chat é um primitivo. Poderoso, mas ainda assim um primitivo.
O mundo pós-chat estará cheio de híbridos. Um planeador com conversa ao lado de uma linha cronológica. Um editor de contratos com sugestões ao nível da cláusula e provas de origem. Uma consola de apoio com respostas redigidas, confiança, verificações de políticas e histórico do cliente. Uma superfície clínica com contexto do paciente, propostas de plano, sinalizadores de risco e controlos de revisão. Uma ferramenta de dados onde a linguagem gera uma consulta, mas o resultado vive numa tabela com linhagem e validação. O modelo torna-se presente em todo o espaço de trabalho sem forçar todo o trabalho para um registo de conversa.
Isto é mais difícil de construir do que uma janela de chat. Exige compreender o domínio, os objetos, os papéis dos utilizadores, os modos de falha e os registos que importam. Exige disciplina de design. Exige dizer não a funcionalidades que tornam a demonstração mágica enquanto tornam o trabalho de produção ambíguo. Mas é esta a direção que as interfaces de IA sérias têm de tomar. O chatbot tornou o modelo acessível. A próxima interface tem de o tornar operável.
A lição
A interface depois do chatbot não é um chatbot mais bonito. É uma superfície de trabalho onde a linguagem, os controlos, os artefactos, as fontes, o estado e os registos se encontram. Deixa as pessoas perguntarem, mas também inspecionarem. Deixa os modelos proporem, mas não decidirem silenciosamente. Deixa os utilizadores aceitarem partes, rejeitarem suposições, fixarem fontes, compararem versões, anularem alterações e aprovarem ações com evidência. Transforma o modelo de uma caixa que fala num participante num fluxo de trabalho governado.
O chat ensinou às pessoas que a IA podia ser conversacional. Essa foi uma lição necessária. A próxima lição é que conversa não é o mesmo que trabalho. O trabalho tem memória, forma, propriedade, risco e consequência. A interface precisa de honrar essas coisas em vez de as esconder numa transcrição. O futuro continuará a falar. Também mostrará as suas fontes, exporá o seu estado, lembrará as suas decisões e dará aos utilizadores pegas suficientemente fortes para orientar.