O Desafio
O TestBooster nasceu de um pivot estratégico: de ferramenta no-code para consumidores para plataforma enterprise direcionada a QA Engineers, Desenvolvedores e times de DevOps. Com o reposicionamento, vieram novos usuários, novas expectativas e uma complexidade de produto radicalmente diferente. O sistema existente tinha 40 telas sem arquitetura coesa: módulos adicionados incrementalmente sem um padrão de navegação. Três tipos de teste distintos (UI, API, Flows) coexistiam sem hierarquia clara. Usuários técnicos precisavam configurar automações complexas, mas a interface não dava feedback visual sobre o estado das execuções. Um QA Engineer abrindo o dashboard não sabia o que estava rodando agora, o que tinha falhado ou por onde começar. O desafio era organizar, usuários enterprise toleram complexidade quando ela é previsível. O problema era a imprevisibilidade: cada módulo tinha padrões de interação diferentes, a navegação não mantinha contexto e os estados de execução eram comunicados apenas por texto, sem hierarquia visual.
Arquitetura e Fluxos
A reestruturação começou pela arquitetura de informação: mapear os 40 telas nos 12 módulos funcionais e definir um padrão de jornada que se repetisse em todos eles — list → editor → execution → results. A consistência do padrão é o que torna o sistema previsível.
Decisões de UX e UI
Cada decisão foi guiada pela mesma premissa: complexidade técnica não é problema de interface, mas sim responsabilidade da arquitetura. A interface documenta o estado do sistema, não o esconde.
UX – Sidebar persistente: navegação que mantém contexto entre módulos. A sidebar fixa com ícones + label curto exibe o módulo ativo com destaque em purple. Ao navegar entre Test Cases, API Tests e Flows, o item ativo permanece visível: o usuário nunca perde o contexto de onde está no sistema. Módulos agrupados por área (Testing, Orquestração, Gestão) com separador visual entre grupos.
Padrão list → editor: Mesmo modelo mental em todos os 12 módulos. Independente do módulo (Test Cases, API Tests, Flows, Team, Projects ), a estrutura é sempre a mesma: lista com filtros e busca, clique abre o editor no mesmo contexto (não em página nova), breadcrumb indica localização. O usuário aprende o padrão uma vez e aplica em todos os módulos.
UI – Sistema de status: 4 estados, 4 cores — aplicados de forma consistente em toda a plataforma
Passed (verde), Failed (vermelho), Running (purple pulsante), Skipped (cinza). Os mesmos tokens são usados em badges, linhas de tabela, indicadores de nó no canvas e na barra de progresso de execução. Um QA Engineer aprende os status uma vez — em qualquer parte do produto, a leitura é idêntica.
Log rolável com highlight de erro: Durante a execução, a tela exibe uma barra de progresso por etapa (não global), o log de saída em tempo real com syntax highlight para erros e warnings, e um contador de steps concluídos/total. O usuário técnico vê exatamente o que está acontecendo: a execução é transparente, não uma caixa preta com loading genérico.
Canvas drag-and-drop para sequenciar testes sem código. Test Flows permitem orquestrar sequências de testes existentes (UI ou API) em um fluxo condicional — “se o Login flow passar, execute o Checkout flow; se falhar, notifique o Slack e encerre”. O canvas drag-and-drop representa visualmente essa lógica sem exigir que o QA Engineer escreva um script de orquestração. Cada nó do canvas exibe: tipo de teste (UI/API/Condição/Notificação), nome do test case vinculado e status do último run com cor. Conexões entre nós são linhas com seta, não há ambiguidade de ordem.
4 tipos de nó com identidade visual distinta, sem legenda. O canvas usa quatro tipos de nó, cada um com cor de fundo e ícone próprios: Test Case (purple — testes de UI), API Test (teal — endpoints), Condição (amber — lógica if/else) e Notificação (cinza — Slack, e-mail, webhook). A cor é o identificador de tipo — o usuário não precisa ler o rótulo para entender o que o nó faz. Alternativa descartada: nós idênticos com tooltip de tipo ao hover. Tooltip como único identificador exige interação para obter informação essencial — antipadrão em interfaces de alta densidade.
Resultados
Plataforma enterprise completa: da arquitetura de informação às 40 telas, com documentação de padrões para handoff. O sistema de design modular garante que novos módulos possam ser adicionados sem quebrar a consistência.
40 Telas documentadas com estados default, execução, erro e resultado.
12 Módulos funcionais com padrão list → editor → execution → results.
1DS Design system com tokens de status, componentes de tabela, editor e canvas.
0 Padrões de navegação duplicados — um modelo mental aplicado nos 12 módulos.
