KPIs, SLAs e scorecard pronto para contratar uma consultoria UX que também constrói o produto

Um bom contrato de UX não mede vaidade. Ele mede avanço real em direção ao produto certo, construído do jeito certo e no tempo certo. Isso significa combinar indicadores de descoberta, validação, entrega e operação, porque cada fase carrega um tipo de risco diferente. Se você mede só entregáveis visuais, incentiva volume. Se mede só velocidade, incentiva atalhos. Se mede só qualidade, pode travar o time em over-engineering. Na fase de discovery, os KPIs mais úteis costumam estar ligados à qualidade da decisão, não à quantidade de workshops. Exemplo: número de hipóteses priorizadas com base em evidência, taxa de hipóteses invalidadas antes de desenvolvimento, tempo até a primeira decisão executiva e profundidade da amostra de entrevistas por perfil crítico. Em produtos B2B, uma boa prática é exigir entrevistas com decisores e usuários operacionais, porque o comprador nem sempre é quem sente a dor no dia a dia. No protótipo e validação, os SLIs precisam mostrar que o fornecedor está aprendendo com usuário real. Aqui entram taxa de conclusão de tarefas, tempo para completar fluxo principal, índice de erro, sinal de confiança do usuário, aceitação do fluxo proposto e percentual de problemas críticos resolvidos antes do código. Para validar essa etapa, ajuda muito usar métodos e critérios próximos aos que já detalhamos em consultoria UX para MVP com IA e em como transformar entrevistas com clientes em um backlog técnico priorizado. Na fase de produção, o contrato precisa sair do campo do “parece bom” e ir para o “sobe com segurança”. Aqui entram SLAs como prazo de resposta a bloqueios, tempo de correção de bugs críticos, cobertura mínima de testes de usabilidade com usuários representativos, frequência de rituais de alinhamento e tempo máximo para transferência de conhecimento ao time interno. Em projetos com integração a AWS, Azure, GCP, Power BI ou SAP, também faz sentido amarrar disponibilidade, observabilidade básica e documentação de handoff, porque UX sem engenharia navegável vira dívida operacional.

SLAs bons são os que protegem a entrega sem empurrar o fornecedor para soluções excessivamente complexas. Em consultoria UX que também constrói produto, o contrato precisa deixar claro que velocidade e qualidade andam juntas, mas não significam burocracia infinita. O ideal é amarrar compromisso de resposta, cadência de entrega e critérios de aceite, não microgerenciar a forma de trabalhar. Por exemplo, você pode negociar SLA de primeira resposta para bloqueios críticos em até um dia útil, revisão de hipótese em até dois dias úteis e apresentação de protótipo validável em uma janela definida por sprint. Já para bugs críticos em produção, o SLA deve refletir impacto de negócio, com priorização imediata e plano de contenção. Se o seu contexto envolve integrações complexas, um guia complementar útil é observabilidade para produtos digitais com IA, porque muitos atrasos de UX parecem problema de design, mas na verdade são problema de telemetria, logs e instrumentação. O que evitar é transformar SLA em fila de punição. Quando o contrato mede apenas velocidade, a consultoria tende a reduzir análise para “bater prazo”. Quando mede apenas detalhamento, o resultado vira excesso de documentação. O equilíbrio vem de três camadas: prazo de resposta, prazo de entrega e critério de qualidade. Essa lógica é a mesma que usamos em contratos de squad e em modelos híbridos, como você pode ver no modelo de SLA e onboarding para alocação de equipes e no guia de compra de alocação de equipe de TI. Em projetos com risco regulatório, como saúde, fintech e govtech, inclua SLAs para validação de requisitos críticos, revisão de acessibilidade, registro de decisões e rastreabilidade de alterações. Isso evita que o fornecedor entregue um produto “bonito” que não passa pela realidade operacional. Se houver uso de IA, ainda vale combinar essas regras com critérios de explicabilidade e consentimento, como os detalhamos em ética e explicabilidade no design de produtos com IA.

O primeiro erro é dar peso excessivo ao portfólio visual. Proposta bonita não prova capacidade de descobrir problema, validar hipótese e construir produto em produção. Em muitos casos, só mostra habilidade de apresentação. Se você quer comparar fornecedores de forma séria, peça também exemplos de decisão difícil, trade-off técnico e resultado operacional. O segundo erro é transformar SLA em controle de atividade. Isso incentiva relatórios longos e reuniões demais, mas não melhora o produto. Em consultoria UX que também desenvolve software, o que importa é a consistência da entrega e a qualidade da decisão. Uma cadência simples, com indicadores claros e critérios de aceite objetivos, costuma funcionar melhor do que burocracia pesada. O terceiro erro é ignorar a senioridade real do time. Alguns fornecedores vendem nome forte e alocam perfis júnior ou duplas mal distribuídas. Em projetos com backlog travado ou produto em fase de escala, isso costuma aparecer rápido em retrabalho, dependência excessiva do cliente e lentidão de decisão. Se quiser aprofundar esse ponto, o conteúdo sobre como decidir entre consultoria externa, equipe interna ou alocação ajuda a enxergar o trade-off entre custo, controle e velocidade. O quarto erro é não separar métrica de produto de métrica de esforço. Número de telas, número de reuniões e volume de documentação não garantem adoção. O que deveria entrar no scorecard é redução de risco comercial, aderência ao problema real, velocidade até validação e robustez de entrega. Se o contrato não traduz isso, ele está incompleto.

Se você quer deixar o contrato mais robusto, vale ancorar parte dos critérios em referências externas reconhecidas. Para acessibilidade, a base mais usada continua sendo o WCAG do W3C, útil para definir critérios mínimos de inclusão em produtos digitais. Em produtos com software vivo, monitoração e resposta a incidentes, a documentação de SLOs e SLIs do Google Cloud ajuda a separar disponibilidade, latência e qualidade percebida. Quando o produto usa IA, especialmente em fluxos que impactam decisão operacional, a NIST AI Risk Management Framework oferece uma linguagem comum para discutir risco, governança e monitoramento. Isso é útil para evitar contratos vagos, onde a equipe entrega algo funcional, mas sem mecanismo de controle para os efeitos colaterais. Em UX com IA, a clareza contratual reduz disputa depois do go-live. Essas referências não substituem o contexto do seu negócio. Elas ajudam a transformar preferência subjetiva em critério verificável. Na prática, esse é o tipo de rigor que melhora a comparação entre uma consultoria global, uma software house tradicional e uma equipe sob medida como a OrbeSoft, que trabalha com discovery profundo, validação antes da construção e entrega ponta a ponta.