top of page

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.


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


O foco não era estética, mas legibilidade e tomada de decisão



Insight-chave

Um bom dashboard não mostra tudo — ele mostra o que importa, na ordem certa.

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.

bottom of page