Agile UX: como incorporar UX e design de produto no Agile

DevOps é frequentemente definido como os processos, operações, metodologias, ferramentas e cultura que cercam o desenvolvimento de software e sistemas de uma empresa.

Mas a engenharia não opera no vácuo. Projetos, ideias, designs e conceitos vêm de especialistas em design de produto que decidem layouts, fluxos e interatividade. Esses são indivíduos e equipes que não são engenheiros que compartilham as metas e os resultados desejados do DevOps.

DevOps é muito mais do que como os desenvolvedores se conectam à TI, como a infraestrutura é gerenciada e como as estruturas podem ser aprimoradas. Trata-se de reconhecer quantas equipes estão realmente envolvidas no processo de desenvolvimento de software, quão interligadas estão suas funções e trabalho e encontrar melhores maneiras de garantir que todos estejam à mesa.

Desenvolvedores e arquitetos de engenharia querem estar envolvidos quando as equipes de produto e criação estão projetando o software ou sistema. Mas onde está isso na definição atual de DevOps? As equipes de produto, UX e criação querem se envolver durante os processos de engenharia, mas muitas metodologias os excluem. Estes são silos antigos que precisamos quebrar.

Seus clientes veem apenas sua experiência do usuário (UX). Eles não veem quantos desenvolvedores você tinha ou se você era Agile ou Lean. Eles não têm ideia de quais ferramentas de DevOps estão sendo usadas. O UX da sua empresa é o produto e pode fazer ou quebrar você. Eles se perguntam quem construiu este pedaço de lixo. Com tanta concorrência e pessoas felizes em desinstalar um aplicativo ou sair de um site, você terá uma segunda chance com o cliente que o abandonou?

Ágil raramente treina em UX ou trabalha com especialistas em UX

Muitas equipes de engenharia geralmente acham que o UX é isolado e difícil de colaborar. UX não parece Lean e muitos sabores de Agile excluem especificidades sobre como trabalhar com UX. Algumas abordagens ágeis sugerem especificamente que um proprietário do produto descrevendo um recurso é “bom o suficiente”.

O SAFe Agile comete o erro de decidir que a melhor maneira de resolver os silos de UX é excluí-los completamente. O SAFe “capacita as equipes ágeis” a fazer seu próprio “Lean UX”. À medida que mais empresas entendem o valor de incorporar especialistas em UX e um processo completo de UX, o SAFe está indo na direção errada.

A ausência de explicação de UX e seus processos de treinamento e livros Agile levou equipes de todo o mundo a excluir ou minimizar o envolvimento de designers de produtos especializados.

• Quando você imagina incorretamente que o UX apenas desenha caixas nas páginas, é fácil supor “eu posso fazer esse trabalho”. Como muitos participantes do American Idol têm certeza de que são os melhores cantores do planeta, a maioria dos gerentes de produto e engenheiros se autoavaliam como sendo ótimos em UX. Isso normalmente significa que eles acreditam que são ótimos no layout de telas. Mas como este artigo explica o que realmente acontece no trabalho de UX, você verá como um especialista em UX não veria um desenvolvedor que faz wireframes como alguém que deveria receber tarefas de UX.
• Livros sobre Scrum sugerem que, se um especialista em UX se tornar um gargalo, ele deve treinar funções não UX para fazer seu trabalho. Esse tipo de decisão raramente é sugerido sobre outras funções no desenvolvimento de software; ninguém gostaria que um desenvolvedor não treinado ou inexperiente fizesse a codificação, mesmo depois de um bootcamp ou lendo um livro sobre programação. Nós nunca sugerimos que, se um desenvolvedor se tornar um gargalo, ele deve treinar o gerente de projeto para fazer alguma codificação.
• Os gerentes de contratação que acreditam incorretamente que o UX é um trabalho artístico (UI) contratam artistas para fazer o trabalho do UX. Não há sobreposição educacional entre um diploma em UX e em UI. Os talentos naturais geralmente não se sobrepõem; alguém ótimo em UX pode ser um artista ruim e vice-versa. Contratar para “UX/UI” geralmente oferece a você um ótimo artista com experiência, conhecimento, processo ou educação mínima em UX.

Aqueles que olham apenas para o resultado final adorariam reduzir o orçamento, dando tarefas de UX a indivíduos que podem não ter educação, experiência, conhecimento, habilidade ou talento natural em UX. Mas isso é míope e pode levar à baixa produtividade, eficiência, cultura, produto e satisfação do cliente.

A importância de incorporar especialistas especialistas em UX em Agile

No final de 2018, a consultoria de gestão McKinsey & Company publicou “The Business Value of Design”, um relatório sobre pesquisas que fizeram com mais de 300 empresas.

Eles descobriram que “o design é a única maneira de as empresas se destacarem da multidão”. Quando os concorrentes têm conjuntos de recursos próximos, o que os diferencia? Às vezes, o design é pensado apenas como a estética ou o que faz com que isso se pareça com a nossa marca. Mas quando usado com “UX”, design significa a arquitetura de recursos e as decisões tomadas sobre telas, etapas, fluxos, layouts, processos, organização e menus.

A UX faz parte do processo de melhoria contínua, sempre buscando entender melhor os usuários e selecionar e projetar os recursos e o produto que melhor atendem às suas necessidades, resolvem seus pontos problemáticos e trazem inovação significativa.

A McKinsey também relatou que “as empresas devem adotar o design de forma holística e no início do processo, em vez de vê-lo como uma pequena ferramenta que se encaixa mais tarde”. As equipes que assumem que a atenção à experiência do usuário é algo que pode ser minimizado, excluído ou feito após o lançamento do produto estão adotando a abordagem errada.

A McKinsey coletou dados quantitativos e descobriu que as empresas que adotaram o design de UX geraram 32% mais receita e 56% mais retorno aos acionistas em um período de 5 anos. Declarar que sua empresa é “centrada no usuário” não é suficiente. Você deve percorrer o caminho integrando profissionais e processos de UX, desde o planejamento e portfólio até o desenvolvimento e o controle de qualidade.

Processos de desenvolvimento de software com e sem UX

Se sua empresa não inclui especialistas em UX no processo de design e desenvolvimento de software, seu processo provavelmente se parece com a imagem abaixo.

Um cliente, gerente de produto, CEO ou alguém com a visão diz à engenharia o que eles querem. A engenharia o constrói, testa e o coloca em um servidor de teste ou de produção. A pessoa com a visão então a vê e, você não sabe, ela não está feliz. Eles querem algo diferente ou mudaram de ideia.

A engenharia tem que então voltar ao início, descobrir o que essa pessoa quer agora, construir, testar e cruzar os dedos que esse é o charme.

Se você tem especialistas em UX na equipe, o processo é bem diferente. Essa pessoa com a visão chega ao UX com as ideias, dados e pontos problemáticos do cliente. O UX percorre as tarefas em seu processo de design centrado no usuário e testa esses conceitos antes que a engenharia escreva uma linha de código. Isso garante que o produto ou recurso que estamos pensando em construir seja a execução certa da ideia certa para nossos clientes-alvo.

O teste pode trazer algumas falhas à luz, o que permite que o UX seja iterado e, muitas vezes, teste novamente. Após o processo de UX, você tem um design totalmente aprovado e pronto para entregar à engenharia.

Se alguém mudar de ideia ao longo do caminho, essa pessoa fala com o UX em vez de colocá-lo como uma solicitação de mudança aos desenvolvedores. O UX executa interferência durante o processo e nada é enviado para a engenharia sem que o UX esteja envolvido em projetos, decisões e testes em clientes reais ou arquetípicos.

Mudanças de opinião neste momento não são desastres, pois o custo para alguém mudar de ideia neste momento é mínimo. A engenharia não recebeu os projetos, eles não começaram e não têm nada para reconstruir. UX itera em seus projetos e pode fazer testes de usuário para garantir que as ideias sejam uma boa e forte combinação com a base de clientes. Mudanças de opinião queimam tempo, mas o impacto geral no orçamento é pequeno.

UX tem um processo formalizado

O design centrado no usuário (UCD) é um processo formalizado que inclui tarefas que direcionam os especialistas em UX para pesquisar, projetar, prototipar, testar em usuários reais ou arquetípicos e, em seguida, iterar com base nos aprendizados dos testes.

Com foco em algumas dessas áreas, começamos com requisitos e discussões iniciais sobre recursos e projetos. Quando o UX obtém os requisitos e outras informações do projeto pela primeira vez, é importante começar a colaborar imediatamente. UX NÃO deve descobrir mais tarde que eles projetaram algo que não pode ser construído.

Comece trazendo trabalhadores ou gerentes de UX quando os gerentes de produto ou projeto estiverem decidindo os recursos e a priorização. Um projeto sem valor para o usuário pode ser removido, economizando tempo e dinheiro incalculáveis. É aqui que a maximização da quantidade de trabalho não feito entra em jogo. Produto e Engenharia devem dar suporte à UX quando criam menos trabalho para a Engenharia, reduzindo ou removendo recursos ou projetos inteiros. No entanto, muitas vezes, os projetos têm o ego anexado e os colegas de equipe geralmente excluem o UX dessas conversas iniciais para que o projeto seja financiado.

A pesquisa é uma parte importante do que o UX faz. Não é centrado no usuário sem envolver os usuários. Estatísticas e dados quantitativos são ótimos, mas não há substituto para entrevistar usuários, entendê-los profundamente e obter dados qualitativos. UX quer saber o porquê e não apenas o quê.

A pesquisa de UX também coloca os colegas de equipe na mesma página, unificando todos em torno de personas, arquétipos de clientes-alvo. Com base em entrevistas com usuários, agregamos o que aprendemos e reduzimos todos a 6 ou menos personas. O que os motiva? O que eles precisam? Onde estão as oportunidades para nossa empresa, produto ou serviço?

O melhor uso das personas seria incluí-las em todos os lugares. O produto imagina recursos baseados em personas (e bons dados). Projetos de UX baseados em personas. Testes de controle de qualidade enquanto imaginam que são essas personas. O marketing pode adicionar seus detalhes demográficos e outros, mas também deve considerar como a voz da marca, as mídias sociais e a publicidade falam com as personas.

As personas ajudam os trabalhadores que não são de UX a se afastarem de “Bem, eu gosto desse jeito” ou “O CEO gosta desse jeito”. Estamos projetando para esses clientes-alvo e se você ou o CEO não se encaixam nas personas, o UX não é influenciado pelo ego ou preferências pessoais. O UX deve permanecer focado no cliente.

A arquitetura da informação tem a ver com hierarquias, estrutura e taxonomias. Isso pode ser a navegação do site ou como os produtos são categorizados em um banco de dados de comércio eletrônico. Queremos garantir que os clientes encontrem facilmente produtos por categorias, metadados e filtros.

Design de interação , às vezes também chamado de design de experiência, é o que a maioria das pessoas pensa quando imagina UX. Estes são os wireframes e protótipos, os projetos e conceitos. Eles mostrariam fluxos de processos, layouts, menus, interações, caminhos, escolhas e muito mais.

Os protótipos de UX são como wireframes trazidos à vida. São maquetes digitais interativas e clicáveis. Não temos que escrever código; temos um software que nos ajuda a criá-los rapidamente. As empresas que procuram protótipos mais realistas usam o Axure, pois possui lógica condicional, variáveis, gestos de deslizamento móvel, arrastar e soltar e todos os tipos de acionadores de eventos. Você pode criar protótipos para praticamente qualquer tipo de dispositivo.

A prototipagem de UX é feita para:

• chuva de ideias
• Colaborar
• Iterar
• Explorar soluções
• Pitch para investidores (para startups)
• Teste o protótipo para ver se a solução se conecta bem com o(s) público(s)-alvo.
• Forneça um modelo interativo para desenvolvedores ou outros colegas de equipe, o que geralmente é preferível a páginas de documentação (e nenhum modelo clicável).

Agora vai para o teste de usuário , também chamado de teste de usabilidade, que acontece durante o processo de UX e antes que a engenharia escreva uma linha de código. Você deve testar conceitos e designs para garantir que a ideia e a execução sejam fantásticas para os clientes-alvo.

O teste do usuário trará à luz quaisquer falhas, dando ao UX a chance de iterar as ideias, o que é barato neste momento, pois não há nada para a engenharia construir ou reconstruir.

Existem 5 razões principais pelas quais o UX executa testes antes de entregar à engenharia:

1. Melhor uso do tempo e recursos da engenharia. Se você quiser que os participantes do teste vejam um produto acabado criado por engenheiros, você precisa construir e testá-lo em busca de bugs. Se o teste de UX trouxer à luz as mudanças necessárias, os desenvolvedores teriam que reconstruir e o controle de qualidade teria que testar novamente. Se o teste de UX mostrou uma falha maior do conceito, isso pode significar que o tempo da engenharia foi completamente desperdiçado, pois esse não é um código que vai acabar em qualquer lugar. O conceito teria de ser repensado, redesenhado e testado de novo.
2. Iterar nos bastidores. Quando as empresas apenas constroem, apenas enviam, iteram nele e constroem e enviam novamente, isso significa que os clientes estão vendo uma variedade de versões. Eles estão vendo o trabalho em andamento e observando a salsicha sendo feita. Esta é muitas vezes uma experiência frustrante e confusa que exige que os clientes continuem reaprendendo um sistema que está evoluindo. É melhor iterar nos bastidores do processo de UX e deixar claro para os testadores que é um protótipo ou uma versão de demonstração.
3. Monitoramento e medição. Se um novo conceito é lançado ao vivo, os pesquisadores de UX não têm uma boa maneira de observar as pessoas usá-lo, fazer perguntas e obter o tipo de feedback que o UX precisa para determinar se algo está pronto ou precisa de outra iteração. O UX sempre quer saber o porquê, o qualitativo, e não apenas o quê ou quantos. Como os usuários estão gastando, convertendo, engajando, etc? Evitar o teste de UX adequado dificulta o diagnóstico e a correção de problemas ou pontos problemáticos do cliente.
4. O teste de UX se paga. O teste de UX não é uma despesa enorme. Algumas ferramentas de teste de terceiros exigem menos de US$ 100 por participante de teste, outras exigem um compromisso anual mínimo de milhares de dólares. Essas não são despesas enormes, considerando o orçamento geral da empresa para o processo de desenvolvimento de software e a importância do feedback dos testes iniciais. Rodadas de testes com usuários quase sempre custam menos e são mais rápidas do que fazer os programadores construirem algo que talvez tenhamos que desfazer ou construir novamente.
5. O teste do usuário resolve os argumentos. Se sua empresa não permite que especialistas em UX tomem a decisão final sobre como o produto é projetado, então você pode encontrar UX em conflito com o produto, engenharia ou uma parte interessada quando há ideias variadas sobre o que deve ser construído e liberado para o cliente. Ou se o UX tiver duas ideias fortes e eles estiverem se perguntando qual se conecta melhor com os clientes? A solução aqui é o teste do usuário.

UX pode prototipar os conceitos. É melhor reduzir a competição aos dois melhores designs, especialmente se você já conseguir encontrar compromissos entre ideias e membros da equipe. Isso significa que não estamos testando o que o UX quer versus o que o produto gosta versus o que o chefe de engenharia gosta versus o que o scrum master acha que parece uma boa ideia versus o que o parceiro de vida do CEO gosta.

O teste do usuário permite que os clientes se manifestem e ajuda você a encontrar a direção certa para os recursos ou o produto. Ele resolve os argumentos fornecendo às equipes dados quantitativos e qualitativos sólidos que informam a todos qual ideia provavelmente trará mais satisfação ao cliente.

Não é um design centrado no usuário sem envolver o usuário. Isso significa que pesquisamos e testamos com clientes reais ou arquetípicos, em vez de adivinhar, presumir ou “apenas enviar”. Devemos garantir que o que “simplesmente enviamos” tenha sido verificado por meio de testes de usuários e seja uma excelente execução de uma ótima ideia.

O que acontece quando o UX é contornado ou reduzido?

O Skype anunciou recentemente que seu redesenho de 2017, que visava torná-lo mais parecido com o Snapchat, foi um fracasso. Os usuários não queriam, não precisavam ou não gostavam dos novos recursos. A reação foi grande o suficiente para que o Skype fizesse um anúncio em 2018 de que redesenharia o Skype novamente. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Os especialistas em UX saberiam em muitas etapas de seu processo que esses recursos provavelmente seriam indesejados ou falhariam. A pesquisa com usuários-alvo poderia ter revelado rapidamente que eles não queriam que o Skype se tornasse Snapchat. Matar o projeto ou dinamizar nesse ponto inicial poderia ter economizado milhões de dólares do Skype, além de má imprensa e alienação do cliente.

Mesmo se a pesquisa de UX tivesse sido contornada, testar um protótipo de UX em usuários deixaria claro que os clientes não queriam que o Skype fosse nessa direção. Com o UX ainda em andamento, a engenharia ainda não escreveu uma linha de código. Isso poderia ter economizado muito tempo, dinheiro e recursos humanos, celebrando a simplicidade e o trabalho que a engenharia não precisava fazer.

Processo Ágil de UX

Lembre-se dos princípios do manifesto Agile. Sua maior prioridade é a satisfação do cliente através da construção de software valioso. Dê aos trabalhadores (UX) o ambiente e o suporte de que precisam, confiando neles para realizar o trabalho. Maximize a quantidade de trabalho não feito. A atenção contínua ao bom design aumenta a agilidade.

Os projetos que estão avançando precisam dar ao UX uma grande pista para que pesquisas, projetos e testes apropriados possam começar. Não convide UX para sua reunião inicial e surpreenda-os com a exigência de que os wireframes finais sejam entregues em poucos dias. Isso não é UX.

Não olhe para isso como Big Design Up Front (BDUF), que é um termo criado para fazer as pessoas se encolherem e declararem que isso é algo que devemos nos afastar. Quando um projeto ou recurso é grande ou novo, é necessário que o UX percorra a maioria, se não todo, o processo de design centrado no usuário. Para UX, a menor parte possível para um recurso maior é o fluxo de trabalho ou processo do usuário. Se projetarmos e testarmos algo menor, corremos o risco de não obter o quadro geral da verdadeira experiência do usuário.

Por exemplo, se estivermos projetando um fluxo em que os usuários se cadastram e compram, não podemos simplesmente projetar campos de seleção de senha e enviá-los à engenharia. Se o UX funcionasse em pequenas partes, quando todo o processo seria testado? Não podemos conhecer a reação do usuário a todo o fluxo sem testar todo o fluxo... o que significa que todo o fluxo deve ser projetado antes de ir para o teste de usabilidade.

Onde recursos, histórias ou correções são pequenos, os profissionais de UX podem fazer um subconjunto do processo de design centrado no usuário e trabalhar mais rapidamente. O UX sempre será o mais rápido possível, mas um grande especialista em UX fará tudo o que puder para evitar sacrificar a qualidade do trabalho que está sendo feito. Na batalha entre rápido e bom, o UX sempre escolherá o bom sobre o rápido… e você também deveria.

Orçamentos e cronogramas são o que impede o UX de obter feedback e iteração rápidos. Os praticantes de UX sempre querem feedback e a chance de melhorar o produto, visando projetar o que realmente funciona para os clientes. Trazer profissionais de UX desde o gerenciamento e planejamento de portfólio permite que o UX estime o tempo e o orçamento de que precisarão; estes não devem ser mais tarde surpresas ou causas de conflito.

Um UX Practitioner faz parte da equipe ágil

Incorpore seu UX Designer na equipe Agile. Convide-os para planejamento de lançamento, stand-up, retro e todas as reuniões em que o UX possa ser discutido. Permita que o UX estime seu tempo durante o planejamento de lançamento para que não haja surpresas sobre o tempo que as tarefas de UX exigirão. Não tome decisões sem eles. Se seu colega de equipe de UX perdeu a reunião, espere até encontrá-lo pessoalmente, por bate-papo, e-mail ou qualquer outro método que sua empresa use.

Atribua perguntas, ambiguidades ou bugs ao seu colega de equipe de UX no JIRA ou em qualquer sistema de rastreamento de bugs que você use. Certifique-se de que os problemas de UX estejam no mesmo sistema que outros problemas; não descarte problemas de UX em um quadro do Trello se você estiver usando o VersionOne para todo o resto.

Depois que o UX tiver seu longo caminho, se for necessário para esse recurso ou produto, uma prática recomendada é fazer com que o UX tenha 2 ou mais Sprints à frente da engenharia. UX pode correr junto com você. Obtenha muitas histórias de tecnologia ou correção de dívidas de tecnologia na lista de pendências. Dessa forma, se o processo criativo e cíclico do UX se atrasar ou exigir mais sprints, os desenvolvedores podem ser realmente ágeis. Em vez de esperar pelo UX, eles podem mudar para algumas frutas fáceis que o produto ou a engenharia priorizou.

Considere também recursos, alocação e pessoal. Dependendo do tamanho do projeto, não atribua mais de 3 projetos a um designer de UX. Se você tiver pesquisadores de UX especializados e separados, que também fazem testes e análises, atribua um pesquisador a não mais que 3 designers de UX. Se o seu profissional de UX é conhecido como forma de T, o que significa que ele também é qualificado e excelente em pesquisa, testes e outras subespecialidades de UX, certifique-se de que ele não seja acidentalmente um gargalo por ser atribuído a muitos projetos.

Resultados de medição

Sem a satisfação do cliente, você pode não ter clientes. Você pode usar as métricas de satisfação do cliente para determinar como melhorar seus processos integrando a UX fez mudanças positivas.

• Menos reclamações
• Melhores avaliações de aplicativos
• Classificações mais altas do aplicativo
• Menos tickets de suporte
• Menos chamadas de call center
• Semântica mais positiva de postagens sociais
• Mais instalações de aplicativos, menos desinstalações
• Aumento do AOV (valor médio do pedido)
• Maior taxa de conversão

Você também pode medir as metas de DevOps desejadas, como tempo de lançamento no mercado e tempo entre correções. Quanto tempo as histórias, projetos e épicos levam para chegar ao mercado antes e depois da sua revolução UX? As estimativas de tempo do desenvolvedor provavelmente serão mais precisas quando eles tiverem finalizado os designs de UX nos quais basear suas estimativas versus trabalhar a partir de histórias ou o que você estiver fazendo agora.

Se a UX está fornecendo planos e eles estão sendo seguidos, esperamos que a engenharia tenha menos trabalho reduzindo mudanças e reconstruções surpresas. Melhor design de UX mais cedo, menos correções depois.

Agile UX é um investimento que mais do que se paga

Muitos gerentes de projeto veem o UX como uma linha de orçamento que pode ser removida ou reduzida, e os gerentes de contratação ficam empolgados com a ideia de combinar tarefas de UX com outra função. No entanto, mais e mais empresas estão aprendendo que não há substituto para investir em um processo de UX adequado realizado por especialistas em UX treinados e experientes.

Eric Ries, autor de The Lean Startup , pergunta: “E se nos encontrássemos construindo algo que ninguém queria? Nesse caso, o que importava se fizéssemos isso dentro do prazo e do orçamento?” Mesmo que sua organização não esteja usando a metodologia Lean, o alerta ainda é válido. Os resultados desejados do DevOps refletem isso quando buscamos criar a coisa certa para o cliente, melhorar a satisfação do cliente e desenvolver recursos com alto valor para o cliente.

Conhecer seu cliente, envolvê-lo no processo e desenvolver suas verdadeiras necessidades e preferências é, em última análise, mais importante do que cronogramas, orçamentos, estruturas e ferramentas. Confie que, se você construir as execuções certas das ideias certas, a receita estará lá.