Métricas para Developer Experience (DX)

Como medir DX utilizando métricas de UX. É sobre isso que falaremos aqui.

Fala pessoal, seguindo a série de artigos sobre developer experience agora iremos abordar o tema de métricas para DX, a ideia central deste artigo é trazer uma lista de métricas que podem ser utilizadas para mensurar se seu produto está adequado ou não dentro desse princípio. Caso você não tenha uma ideia clara do que é DX recomendo que leia o primeiro artigo da série.

Na minha visão o primeiro passo para criar métricas de DX é já ter domínio pleno sobre métricas de UX, mas por que? Basicamente porque DX é uma vertente dentro de UX, ou seja, os developers que utilizam seu produto, mesmo que usuários extremamente técnicos, ainda são usuários que serão impactados caso seu produto tenha uma UX ruim.

Users > user experience > developers > developer experience

Então, indo de encontro com a ideia de que entender sobre DX quer dizer entender sobre UX também, vamos listar alguns pilares dentro do universo de user experience e como medi-los.

Pilares de UX

Usabilidade

O quão fácil seu produto é para seus usuários? O pilar da usabilidade vem para nos direcionar em relação a experiência que iremos desenhar para nosso produto, ou para nos mostrar pontos de melhoria dentro da experiência atual. Para medir usabilidade recomendo os seguintes métodos:

• Teste de guerrilla (vá pra rua e pergunte a quem encontrar)
• Teste em laboratório (chame um grupo de pessoas para um local específico e teste seu produto com elas)
• Teste de usabilidade remoto (Dê acesso do produto ao usuário e meça a interação dele, para isso eu uso hotjar, mixpanel, entre outros)
• Entrevista presencial e/ou remota (Monte seu roteiro e selecione um grupo de pessoas para entrevistar, aqui podem ser coletados dados qualitativos e quantitativos, geralmente adoto uma abordagem de dados qualitativos e posteriormente transformo-os em quantitativos).

Acessibilidade

Seu produto ou serviço é acessível para seus usuários alvo em seus respectivos papéis? É importante mapear todas as pessoas que vão usar seu produto e suas jornadas durante esse uso, para isso geralmente é elaborado um artefato chamado journey map, nele você consegue mapear todas as etapas da jornada, também podendo mapear alguns pontos importantes para seu contexto, como desafios em cada etapa, abaixo coloquei o framework que utilizo para criar meus journey maps.

Como podem ver, em cada etapa eu já elenco quais possíveis métricas posso utilizar para validar que aquele step está indo bem ou não, para um product manager isso facilita muito o processo mapeamento de KPIs de negócio e tecnologia.

Encontrabilidade

Pra quem é brasileiro e gosta de futebol ler essa palavra pode parecer um termo que o técnico Tite da seleção brasileira inventou rsrs. Brincadeiras a parte, o quão simples é para seu usuário encontrar o que ele precisa no seu produto?

Neste pílar a principal maneira de validar eficiência é através da medição do tempo utilizado para o usuário completar uma tarefa, você pode fazer isso através de testes em laboratório com gravação de tela e usuário, ou então remotamente com utilização do hotjar ou ferramenta de screen record.

Uma coisa legal pode ser colocar na matriz de user flows uma linha de "Time to complete task", assim você pode comparar tempo entre várias propostas de jornada diferentes.

Credibilidade

Acredito que esse é o pílar que mais tenha relação direta com DX, pois credibilidade em produtos é saber se o que você promete é realmente entregue ao seu cliente, e se tem algo que desenvolvedores não gostam, é de pessoas/empresas que prometem coisas e não as entregam.

Trabalhei em um projeto de grande uma empresa que utilizava um framework gigante para desenvolvimento, ele prometia acelerar o trabalho dos desenvolvedores em até 10x, porém ele tinha tantos bugs que no final éramos atrasados em quase 2x, no final das contas, deixamos o framework de lado e somente consumíamos suas APIs quando necessário, projeto entregue no prazo.

Sendo assim, uma das melhores maneiras de medir credibilidade é medir bugs, simples assim, meça além de bugs que aparecem dentro do produto, bugs de processo devido a seu usuário não entender como algo funciona são tão ruins quanto.

Para medir bugs utilizo o service desk do Jira, sei que algumas vezes um caractere a mais numa frase pode ser entendido como um bug crítico pelos seus usuários e isso pode atrapalhar sua métrica, por isso, é importante ter mapeado KPIs de negócio e tecnologia, para em algum momento você revisitar os tickets e categoriza-los de acordo com sua real importância de acordo com as KPIs que você tem.

É possível aplicar métricas de UX em DX?

Essa é uma questão que em fiz no começo da minha jornada atuando com produtos que eram destinados a developers, pois ao pesquisar sobre métricas de DX não encontrei nenhum framework ou lista de métodos de validação de experiência, porém, encontrei pílares de DX que me ajudaram a definir processos para mensuração de efetividade do meu produto.

Ao analisar os pílares de DX percebi uma correlação natural com UX com algumas pequenas mudanças, logo imaginei ser possível aplicar métricas UX, para isso fiz uma correlação dos pílares de cada um e possível aplicação de mesmas métricas. Abaixo listo os pílares de DX e UX e sua correlação.

[DX] Função = [UX] Acessibilidade

A base da experiência para developers, uma devtool é tão boa quanto a função que ela oferece para realizar uma atividade. Boa interface, marketing, promessas milagrosas, e bullshit em geral, não vão conseguir esconder funcionalidades ruins. Se não funciona, não adianta, não tem DX.

Uma coisa que percebo em muitas ferramentas para desenvolvedores é que elas resolvem o desafio que se propõem, mas não possuem uma boa acessibilidade, seja porque o produto está sendo usado por alguém que não é o público alvo, ou porque a jornada não foi pensada para os diferentes tipos de usuários que estarão em contato com o produto.

Para esse ponto é importante se fazer o journey map de todas as personas que estarão em contato com o produto, assim você consegue delinear uma jornada para cada pensando em suas particularidades.

[DX] Estabilidade = [UX] Credibilidade

Além de funcionar, seu produto tem que ter alta performance e confiança, claro que softwares estão sujeitos a bugs, por isso, é importante solucionar rapidamente erros no produto para não gerar grandes danos aos usuários.

Na estabilidade a relação de confiança com o seu produto começa a ser construída, sem ela, a percepção de valor cai drasticamente.

Parte da experiência de um produto é proporcionada pelo grau de credibilidade que esse produto passa para seus clientes. No caso de produtos para developers isso é o grau de estabilidade que esse produto proporciona, visto que a instabilidade de uma plataforma além de dar dor de cabeça para seus usuários pode gerar prejuízos de milhões de dólares.

Por exemplo quando AWS ou Azure caem por alguns momentos gerando prejuízos em todos os seus clientes que utilizam esse serviço e consequentemente nos clientes dos seus clientes. Pra mim estabilidade é um dos pílares mais fortes dentro de DX.

Para medir estabilidade recomendo utilização de ferramentas que metrifiquem uptime como Statuspage.io da Atlassian pela facilidade de implementação, flexibilidade para medir vários serviços e boa experiência para quem irá consumir o serviço.

[DX] Facilidade de uso = [DX] Usabilidade

Facilidade de uso em DX é além do que parece, não é somente sobre navegar na ferramenta, mas também acessar o que for necessário em todas as etapas da jornada de forma rápida e eficiente.

Documentação rica, casos de uso, comunidades, bases de conhecimento, atalhos de teclado, snippets, filtros intuitivos, pesquisas feitas anteriormente salvas, e também pontos mais profundos como desempenho, juntos adicionam velocidade no processo de interação dos developers com seu produto e aumentam o engajamento.

Em UX dizemos é comum dizer que bom design muitas vezes não precisa ser explicado, mas em DX isso é um pouco diferentes, pois as vezes seu produto é uma oferta horizontal (oferta horizontal = aplicável a vários segmentos e casos de uso diferentes) e o primeiro passo para fornecer uma boa DX é entender qual o desafio a ser resolvido dentro pelo seu cliente.

Para medir facilidade de uso recomendo utilização de ferramentas de feedback dentro da plataforma como o Hotjar ou Mixpanel (acho o Hotjar mais acessível em termos de custos porém menos abranjente como solução), sendo que o gatilho para esses feedbacks aparecerem deva ser ao final de um ponto chave da jornada.

[DX] Clareza = [UX] Encontrabilidade

Neste ponto a DX está comprometida a fornecer uma interface simples que traga as informações necessárias para o developer realizar seu trabalho, ajudando-o com ações críticas em seu dia-a-dia. A clareza se preocupa em fornecer ao developer visibilidade total das possíveis consequências envolvidas em uma ação e no histórico de suas ações.

Outro erro comum que vejo em plataformas para developers é apresentar todas as funcionalidades que possuem para uma persona ao mesmo tempo, as vezes mesmo tendo mapeado a jornada para aquela persona, isso acontece pelo fato da ideia de que estar tudo visível é melhor para o usuário no momento de encontrar algo que ele precisa.

Mas isso não está correto, o ideal é ir apresentando todas as funcionalidade de acordo com a evolução do usuário dentro do produto, de acordo com o caso de uso específico dele. Em plataformas muito grandes como por exemplo a suite da Atlassian eles redesenharem sua navegação para orquestrar as diversas funcionalidades entre produtos (visão usuário comum e admin) em dois menus e uma busca geral.

Para medir encontrabilidade e clareza recomendo que seja utilizado novamente ou Hotjar e Mixpanel para coleta de heatmaps em páginas específicas (neste caso só o Hotjar tem heatmaps), e também para mapeamento de funil de navegação passo-a-passo e mensuração de breakpoints desse funil.

Para finalizar, acredito que métricas de UX sejam válidas sim para medir DX e basicamente o único conjunto de métricas que você precise utilizar, contanto que você faça as adequações necessárias para o seu contexto, isso é o ponto mais importante, pois no final você precisa entender profundamente das pessoas, cenários, desafios, e objetivos que vão estar em contato com seu produto, somente assim você poderá escolher com asssertividade quais métricas fazem sentido para mensurar o sucesso do seu negócio.

Ficamos por aqui nesse artigo da série sobre DX, no próximo artigo irei abordar sobre como comunidades de developers podem fazer seu produto crescer absurdamente ou morrer num piscar de olhos.