Andy
Objetivos
Centralizar dados de qualidade em uma única fonte de verdade
Gerar visibilidade acionável sobre bugs, estabilidade e evolução das entregas
Apoiar decisões estratégicas de produto e engenharia com base em dados
Promover uma cultura orientada à qualidade contínua
Transformar dados dispersos em insights claros, comparáveis e acionáveis para squads e liderança
O desafio
As squads não tinham uma visão consolidada sobre a qualidade das entregas, a evolução de bugs e o impacto das releases no produto.
As informações estavam distribuídas em diferentes ferramentas, o que dificultava acompanhar padrões de problemas e tomar decisões rápidas sobre priorização e correções.
QA Hub: Um painel de monitoramento para acompanhar qualidade de entregas e evolução de bugs
Overview
QAHUB é uma plataforma interna desenvolvida para centralizar a gestão da qualidade de entregas, oferecendo visibilidade contínua sobre bugs, estabilidade e performance das entregas de múltiplas squads.
Produto: Desktop
Usuários impactados: Engenheiros, QAs, tech leads, Lideranças de tecnologia, PMs
Times envolvidos: QA e Produto
Meu papel: Product Designer responsável pela concepção e estruturação do QA Hub.
Atuei na identificação da oportunidade, definição da arquitetura de informação do painel e no desenho da experiência de visualiza ção dos dados, em colaboração direta com QA e engenharia para estruturar os indicadores mais relevantes para acompanhamento da qualidade das releases.
Solução & Impacto
Por que iterar
Após a fase de ideação, ficou claro que a complexidade dos dados exigia validação contínua da estrutura e da legibilidade das informações.
A etapa de iteração teve como foco:
Refinar a organização e visualização dos dados para garantir clareza, comparabilidade e apoio à decisão.
Durante a ideação:
Testei diferentes composições de dashboard
Ajustei a hierarquia de informações
Simplifiquei blocos que geravam confusão
Ajustes com base em feedbacks de stakeholders
O foco não era estética, mas legibilidade e tomada de decisão.
Principais iterações
Iteração 1: Exploração de estrutura
Testei diferentes formas de organizar os blocos de informação, priorizando volume de dados, mas com baixa clareza na leitura.
Aprendizado: Excesso de informação sem hierarquia dificultava a tomada de decisão.
Iteração 2: Ajuste de Hierarquia
Reorganizei os dados em camadas (visão macro → detalhamento), melhorando a escaneabilidade da tela.
Aprendizado: A ordem de apresentação impacta diretamente a compreensão.
Iterações
Com as métricas definidas no discovery, o desafio passou a ser:
Como transformar um conjunto complexo de dados em uma experiência clara, comparável e orientada à decisão?
A ideação teve como foco estruturar como essas informações seriam organizadas, priorizadas e consumidas pelos diferentes stakeholders.
Objetivo
Traduzir métricas em visualizações compreensíveis
Definir a melhor estrutura para leitura e análise
Garantir equilíbrio entre visão executiva e operacional
Exploração
Referências de dashboards
Analisei diferentes padrões de dashboards (data analytics, produtos SaaS, BI tools) para entender:
Como dados complexos são simplificados visualmente
Padrões de comparação (tempo, categoria, ranking)
Estruturas de hierarquia de informação
Isso ajudou a evitar reinventar a roda e focar no que já funciona.
Utilizei referências de dashboards de mercado como base para padrões de visualização, adaptando-os para o contexto específico de qualidade de software.
Wireframes
Criei wireframes para explorar rapidamente:
Diferentes formas de organizar métricas
Agrupamentos por contexto (tempo, squad, tipo de bug)
Níveis de detalhe (visão geral vs análise profunda)
Esse processo foi iterativo e focado em responder:
O que o usuário precisa ver primeiro?
O que precisa estar comparável?
O que pode ficar em segundo nível?
Esses wireframes exploram diferentes formas de organizar as métricas, com foco em encontrar a melhor hierarquia de informação e facilitar a leitura comparativa entre squads e períodos.
Principais decisões de estrutura
1. Organização em camadas
Defini a tela com leitura progressiva:
Topo: visão macro (volume e tendência)
Meio: eficiência operacional (tempo, impacto)
Lateral: diagnóstico (categorias e ranking)
2. Comparabilidade como eixo central
Todas as visualizações foram pensadas para permitir comparação:
Entre períodos
Entre squads
Entre tipos de bugs
Entre pessoas
3. Priorização de simplicidade
Mesmo com alta densidade de dados:
Reduzi complexidade visual
Evitei excesso de gráficos diferentes
Mantive consistência de padrões
Síntese
Conduzi a ideação transformando métricas em uma estrutura de informação clara e escalável, garantindo que diferentes perfis de usuário conseguissem interpretar e agir sobre os dados com rapidez.
Ideação
Discovery
Durante o discovery, identificamos que o principal gap não era a ausência de dados, mas sim a falta de clareza sobre quais métricas realmente representavam qualidade.
Apesar do alto volume de informação disponível, não havia um modelo consistente que permitisse análise, comparação e tomada de decisão entre squads.
Diante disso, o foco desta etapa foi:
Definir um conjunto de métricas confiáveis, comparáveis e acionáveis que representassem a qualidade das entregas de forma consistente entre squads.
Como conduzi
Facilitei sessões colaborativas com stakeholders de engenharia e qualidade para mapear:
O que cada time já acompanhava
Quais métricas influenciavam decisões reais
Quais dados eram ruído vs. sinal
Esse momento foi menos sobre “inventar métricas” e mais sobre organizar o caos existente em algo estratégico.
Métricas Mapeadas
Métricas consideradas essenciais (IMPORTANTE)
Tempo médio de resolução de bugs
Quantidade de histórias impactadas por bugs
Categoria dos bugs (ex: funcional, performance, UI)
Taxa de bugs por entrega / release
Distribuição de bugs (com contexto + links para análise)
Bugs revisitados (recorrência)
Essas métricas foram priorizadas por:
Apoiar decisão
Serem comparáveis entre squads
Terem contexto suficiente para análise
Métricas descartadas ou secundárias (NÃO PRIORITÁRIAS)
Bugs em aberto (sem contexto de impacto)
Volume bruto de bugs sem categorização
Insight importante: Métricas isoladas geravam mais ruído do que clareza.
A liderança não queria só números — queria responder:
“Quem está melhorando?”
“Onde está o risco?”
Qualidade precisava ser traduzida
Dados técnicos precisavam virar linguagem acessível para:
Produto
Liderança
Negócio
Decisão estratégica
A partir desse mapeamento:
→ Definimos um modelo padronizado de métricas de qualidade → Criamos a base para os dashboards do QAHUB → Garantimos que todas as squads seriam analisadas sob os mesmos critérios
Síntese
Estruturei a definição de métricas transformando percepções subjetivas de qualidade em indicadores claros, comparáveis e acionáveis, criando a base para decisões estratégicas orientadas a dados.