Os desenvolvedores são a força vital da inovação. São eles que criam soluções tecnológicas transformadoras.
A experiência do usuário (UX) é central para quase todas as discussões na comunidade de desenvolvedores.
Por padrão, ao que parece, o usuário final é a prioridade em quase todas as decisões. No entanto, outra vertente da narrativa da “experiência” está se formando, e é aí que e onde o papel da experiência do desenvolvedor (DX) deve ficar na matriz UX.
Alguns argumentam que DX e UX são a mesma coisa, mas existem diferenças distintas e sutis.
DX é essencialmente outra camada para UX, uma camada que apenas um desenvolvedor que usa sua ferramenta pode aproveitar – ou não, como costuma acontecer.
“A maior diferença entre UX e DX é que a experiência do usuário se concentra nos usuários finais, enquanto a experiência do desenvolvedor é sobre os desenvolvedores que usam seu software para implementar uma solução para seus usuários finais”.
A distinção importa? Sim, porque quando falta o DX, falta também UX.
Você não pode esperar que os desenvolvedores forneçam consistentemente experiências de alto nível aos usuários quando eles estão se equilibrando em bases frágeis.
As ferramentas às quais os desenvolvedores têm acesso são um componente vital do DX de qualidade. Muitos argumentos sobre DX adotam uma postura semelhante, concentrando-se na tecnologia na ponta dos dedos do talento, em vez de em seu ambiente envolvente.
O DX deve ir muito além de como você projeta nossas ferramentas para desenvolvedores; deve ser voltado para a criação de uma cultura construída em torno da ideia de que os desenvolvedores devem aproveitar suas experiências em todos os níveis.
Suavizando a jornada para ‘Hello World’
Facilitar o caminho para os desenvolvedores que usam seu software é bastante simples.
Seja curioso sobre a experiência do desenvolvedor, ouça, observe e tome todas as medidas para tornar o uso do seu produto o mais tranquilo possível.
Certificando-se de que seus sistemas e ferramentas são facilmente navegáveis.
Muitas vezes, como Ian Jennings escreveu recentemente , “algum engenheiro espertinho construiu uma biblioteca, escreveu um leia-me (que na verdade é apenas uma coleção de seus comandos CLI) e pensa que qualquer outra pessoa que não pode usar o produto é ‘estúpida'”.
Quer seja tão simples quanto redesenhar seu processo de inscrição ou repensar onde as chaves de API são exibidas ou integrar um SDK para um idioma preferido, não importa qual seja, faça tudo o que puder para facilitar o caminho para os usuários do produto.
As ferramentas que criamos devem ser consumidas o mais facilmente possível, então tudo que você pode fazer desde uma perspectiva tecnológica até uma perspectiva de documentação deve ser para ajudar o desenvolvedor.
No entanto, muitas vezes há uma mensagem implícita de “goste ou não”. Não é assim que você trata os usuários finais (se você quer sucesso), então por que esperar que os desenvolvedores encontrem soluções alternativas ou aceitem menos do que DX?
Os desenvolvedores são clientes e, em muitos aspectos, com o boom da cultura de startups, são agora um dos compradores de tecnologia mais influentes, senão os mais influentes.
Isso significa que as empresas de software devem ver o DX como uma preocupação principal, trabalhando com eles, não contra eles.
Deve ser o objetivo de qualquer empresa de software ajudar os desenvolvedores a alcançar seu momento “Hello World” da maneira mais rápida e indolor possível.
Quanto mais tempo demorar, maior a probabilidade de abandonarem o barco. É por isso que é tão essencial que entendamos cada etapa, clique e pequena (e grande!) frustração que nossos usuários experimentam. Assim como o CX do usuário final é separado, o DX também deve ser.
Fechando o Circuito
DX é um círculo virtuoso. Ao incentivar ativamente o feedback do desenvolvedor, você pode aprender o que precisa fazer para conduzir um DX melhor.
Ouvir verdadeiramente os usuários, fornecer maneiras rápidas e fáceis para eles fornecerem esse feedback e recompensá-lo é crucial.
Você deve ouvir e implementar, ou pelo menos buscar respostas para seus desejos e se comunicar abertamente. Isso não apenas criará o ciclo de feedback mais curto possível – de usuário para empresa para usuário – mas bem feito significa que os usuários se tornarão defensores do seu produto.
Ivan Burazin