A IXC Soft é uma empresa que sempre buscou trabalhar com as últimas tecnologias e métodos de desenvolvimento do mercado com o objetivo de otimizar o trabalho de todos, por isso, metodologias ágeis logo foram implantadas na empresa. Porém, faz pouco mais de dois anos que profissionais (especialistas) focados em experiência do usuário (UX) entraram para a equipe.
Não demorou para o momento em que, inevitavelmente, tivemos que unir metodologias ágeis – que já eram solidamente usadas – com experiência do usuário.
O primeiro passo foi definir o processo de UX na empresa, depois de muita pesquisa para entender como o mercado já fazia, e como nós poderíamos adaptar para a realidade da IXC Soft. É importante lembrar que esse processo não deve ser imutável, muito pelo contrário, deve ser sempre otimizado de acordo com as necessidades.
UX Designer
Como UX Designer, meu trabalho é fazer pesquisas com o cliente (ter empatia), compartilhar insights dessas pesquisas com a equipe de produto, identificar as necessidades e os pontos fracos de nossos produtos, idealizar uma forma para encontrar soluções com as equipes, prototipar ideias, testá-las com usuários, aprender com os erros e, em seguida, enviar a melhor forma de solucionar o problema (de acordo com minha percepção) ao time de desenvolvimento, auxiliando os desenvolvedores e, posteriormente, continuar melhorando o produto.
Por se tratar de um assunto relativamente novo, não existe uma receita de bolo de como os processos devem ser executados, mas sim alguns pontos em comum que nos guiam, como no manifesto ágil, em que seus princípios falam sobre: indivíduos e interações, software em funcionamento, colaboração com o cliente e adaptação a mudanças.
Percebeu alguma semelhança com UX? É muito importante lembrarmos que o manifesto ágil não foi feito apenas para desenvolvedores. O que existe realmente é colaboração da comunidade e troca de experiências entre pessoas, para cada um adaptar o melhor para sua realidade. E vale ressaltar que UX e Agile têm uma causa em comum: o foco no usuário, nas pessoas que vão usar o produto desenvolvido.
Como chegamos ao processo?
Hoje na IXC Soft, dependendo das necessidades de cada time, usamos duas metodologias: Scrum e Kanban.
No Scrum, o time de UX está envolvido em duas etapas: backlog de produto, em que é feita a análise de experiência do usuário, para que o P.O. (Product Owner) possa encaixar o cartão na próxima sprint de acordo com a prioridade, e na sprint de desenvolvimento, quando são realizadas as validações do design proposto de acordo com o que foi desenvolvido.
Já no Kanban, os times dividem seu processo em outras duas etapas: Discovery e Delivery. Em ambas, o time de UX está presente. Para uma rápida contextualização, no Discovery ocorre o entendimento, a triagem e a priorização das demandas; e no Delivery entram, de fato, os desenvolvedores e a programação.
Painéis de Discovery e Delivery da equipe Evolução.
Como é nosso processo?
Mas chega de enrolação e vamos ao que interessa. Afinal, como é nosso processo que envolve ágil e UX?
Para entender perfeitamente, vamos imaginar que surgiu um novo cartão de melhoria no cadastro de cliente. O processo se inicia na abertura do atendimento, quando o suporte levanta a demanda e passa (após validações) para o quadro de discovery da equipe de desenvolvimento, no qual existem três colunas que podem ser o início: análise de viabilidade, análise técnica ou análise de experiência do usuário – a ordem em que o cartão passa por essas colunas não interfere no produto final – sendo que a parte de experiência do usuário é dividida em duas: análise simples e análise avançada.
Via de regra, todos os cartões vão parar na coluna de análise simples de UX, ficando ao encargo do analista de experiência do usuário julgar se é realmente uma análise simples ou avançada.
Geralmente as análises simples são problemas mais superficiais, como alterar uma palavra em um campo, criar um botão, etc. (é claro que sabemos que por mais simples que seja, deveria passar por mais etapas, mas atualmente não dispomos de tempo e mão de obra suficiente para seguir esse modelo).
As análises avançadas, por sua vez, são cartões mais complexos, que precisam de maior atenção, como construção de uma nova tela, criação de diversos campos ou de um novo gráfico, etc.
Quando um cartão entra em análise avançada, ele é automaticamente clonado para nosso quadro de UX através do Jira Automation, ou seja, o cartão original fica na coluna de análise avançada no quadro de origem e seu clone irá para o quadro de UX a fim de passar pelos processos necessários.
Hoje, na empresa, temos um processo de UX que percorre algumas etapas e norteia o desenvolvimento de cartões e projetos: Entender, Pesquisar, Analisar, Desenhar, Design, Testar protótipo, Entregar, Desenvolver, Avaliar, Testar solução e Monitorar. Cada etapa é uma coluna no quadro, tornando visível para todos o trabalho do analista de UX.
Etapas do processo interno de UX na IXC Soft.
Etapas do processo
Dito isso, vou listar de forma muito resumida uma descrição de cada etapa, que em seguida serão combinadas com as metodologias ágeis.
- Entender: precisamos entender o projeto, os usuários, alinhar a visão entre Stakeholders e Product Owners e, principalmente, entender o real problema que vamos resolver.
- Pesquisar: é considerada a segunda etapa do entendimento do problema; muitas vezes as etapas de Pesquisar e Entender se relacionam e andam praticamente juntas. Nessa etapa vamos entender o projeto pela visão dos usuários e da análise de mercado. Também podemos pesquisar por fundamentações e padrões de Design para resolver o problema.
- Analisar: com todas as informações coletadas e catalogadas, vamos analisar os elementos mais importantes e gerar hipóteses para validá-las nas próximas etapas.
- Desenhar: começamos a pôr a ideia em prática, esboçando fluxos, protótipos de baixa fidelidade, wireframes, etc. Deve-se desenhar e redesenhar até uma aprovação.
- Design: aqui começa o refinamento do projeto, indo mais a fundo no design e colocando em prática os princípios, heurísticas e guidelines. Agora sim, trabalhamos com cores, iconografia, tipografia e diversos outros artefatos para chegarmos a uma interface agradável.
- Testar: a primeira bateria de testes do projeto é feita ainda com o protótipo. O intuito é detectarmos falhas e/ou desejos dos usuários que não foram contemplados.
- Entregar: etapa em que entregamos o projeto ou cartão para o P.O. e os desenvolvedores. Explicamos o que foi feito e por quê.
- Desenvolver: nessa etapa, o importante é estarmos junto com os desenvolvedores, prestando todo o suporte possível para garantir que a experiência projetada no protótipo chegue até o produto final.
- Avaliar: após o desenvolvimento, nossa primeira etapa de testes é a avaliação, na qual fazemos uma conferência detalhada do que foi proposto no protótipo com o que foi desenvolvido na solução final.
- Testar: na segunda bateria de testes, agora com a aplicação já concluída, é mais fácil para detectarmos dificuldades no uso, pois o usuário testa em um ambiente livre, o que não acontece no teste com protótipo, pois é impossível simular todo o ambiente da interface.
- Monitorar: após passar por todos os testes, nosso projeto ou cartão chega à etapa de monitoramento; a partir de agora, devemos ficar atentos ao produto durante toda sua vida útil, monitorando com mapas de calor e de clique, pesquisas, etc., em busca de melhorias contínuas. É nessa etapa, também, que ocorre a troca de experiências com a equipe de Customer Success.
Melhoria no cadastro do cliente
Voltando ao exemplo do cartão de melhoria no cadastro do cliente: como é uma melhoria grande que afeta diversas partes do sistema e precisa de atenção, ela será movida para análise avançada e irá cair no backlog do quadro de UX. Feito isso, o analista responsável analisa a demanda e passa o cartão pelas colunas que julgar necessário, até chegar à coluna ‘Desenvolver’.
Uma vez nesta coluna, um e-mail é disparado automaticamente para o responsável do cartão no quadro de origem, informando que o cartão passou pelas etapas de UX e o desenvolvimento pode ser iniciado. Agora, o cartão fica parado na coluna ‘Desenvolver’ do quadro de UX e volta a andar no quadro de origem, passando pelas etapas de desenvolvimento no painel de Delivery.
Quando os programadores finalizarem o desenvolvimento, eles movem esse cartão para uma coluna chamada ‘Revisão UX’. A partir de agora, o cartão no quadro original fica parado na coluna ‘Revisão UX’ e o analista de UX responsável recebe um e-mail informando que o cartão foi desenvolvido e já pode passar pelas etapas de testes.
Desse modo, o cartão passa pelas etapas de ‘Avaliar’ e ‘Testar solução’ até chegar em ‘Monitorar’ (coluna criada para o setor de Customer Success fazer o monitoramento do que foi entregue).
Quando chega nessa última etapa, é disparado novamente um e-mail para o responsável no cartão original, informando que o cartão passou pelos testes de UX e já pode ser entregue ao cliente.
Importante lembrar que para realizar a integração entre os quadros e mandar os e-mails, usamos a ferramenta Jira Automation.
Muita informação né? Não se preocupe, eu fiz um fluxo bem simplificado para facilitar o entendimento.
Diagrama de processo unindo UX e Agile.
Fluxo de processos
No fluxo acima, mostrei como é o processo usando Kanban; nos times que usam Scrum, a lógica é a mesma, porém utilizando o backlog de produto.
Por que decidimos pela separação entre análise simples e avançada?
No sistema existem algumas demandas realmente muito simples, como dito anteriormente, que podem ser ‘despachadas’ com maior facilidade e simplicidade. No início, cometemos um erro tentando melhorar a experiência do cliente e tivemos que voltar atrás, pois nosso tempo de entrega aumentou muito.
Quando todos os cartões passavam por análise avançada, o processo era moroso e por vezes demorava mais que o necessário. Dessa forma, precisávamos pensar em algo para dividir as demandas simples, com vazão rápida, das avançadas, que necessitam de mais atenção.
Como dito anteriormente, hoje, na empresa, contamos com equipes usando as metodologias Scrum e Kanban e nós do setor de UX conseguimos nos adaptar às duas de forma tranquila.
No Scrum, é interessante pontuar o fato de que em todo planejamento de Sprint existe um analista de UX que participa. Então, quando os cartões – previamente avaliados por esse analista – são discutidos, ele pode argumentar seu ponto de vista, levando em consideração a visão do usuário e expondo para toda a equipe qual foi a linha de pensamento e os processos que resultaram naquela solução.
Melhorias percebidas
Atualmente, todas as demandas (ou a maioria delas) passam por uma análise de UX e isso é de extrema importância para um fator: conhecimento de regra de negócio, um item muito relevante para o profissional que lida com experiência do usuário, pois a base de tudo é a regra de negócio, e sem conhecê-la fica difícil propor um bom caminho ao usuário – ou, ainda, propor caminhos equivocados pela falta desse conhecimento.
Existem três princípios básicos que norteiam uma boa relação entre Agile e UX: comunicação, colaboração e confiança. Com o passar do tempo, pude perceber que cada princípio foi amplamente atendido dentro da empresa e que todos os envolvidos se comprometeram com a causa.
Nossa comunicação (entre UX e desenvolvedores, principalmente) melhorou muito, pois com um processo bem definido, as coisas ficam mais claras e de fácil entendimento para ambos os lados, incentivando ainda mais o princípio da colaboração: hoje praticamente todos os desenvolvedores dão ‘pitacos’ e gostam de participar pelo menos um pouquinho do processo de criação, o que antes era raro de acontecer.
Percebo um envolvimento e uma preocupação enorme com a questão do desenvolvimento centrado no usuário por parte dos desenvolvedores, fechando com chave de ouro o terceiro princípio – confiança –, que vem aumentando a cada dia, cada reunião e conversa que temos entre programadores e analistas de experiência do usuário.
Conclusão
- Teste! Elabore diversas metodologias, processos, etapas e testes, essa é a dica de ouro.
- Não se prenda à ideia de que precisa estar uma sprint à frente do time de desenvolvimento, ou duas sprints à frente. Você só precisa estar anterior ao trabalho dos desenvolvedores.
- Não pense que ao estabelecer um processo, ele será definitivo. Você deve manter a cabeça aberta o tempo todo para aceitar ideias que melhorem esse processo.
- Pessoas são muito importantes, muito mais importantes que o processo.
- Adapta-se. Não existe receita de bolo e você não vai encontrar uma solução ideal/perfeita/mágica para sua empresa em um artigo. Ele pode ajudar, mas nunca terá a palavra final. Entenda o macro, como funcionam os processos existentes de desenvolvimento e tente adaptar-se a eles da melhor forma possível.
- Você precisa de métricas. Elas são fundamentais para validar seu trabalho e trazer números visíveis a todas as partes interessadas. Esse é um auto puxão de orelha, pois ainda não trabalhamos com métricas nos processos, mas estamos iniciando.
- Esqueça de obrigatoriedades, não é porque você tem um ótimo processo definido, que ele deverá ser seguido à risca, passando por todas as etapas e entregando todos os artefatos. Dê liberdade às pessoas, desde que o foco seja o cliente.
- E, por fim, mas não menos importante: colaboração. Integre toda a equipe – desenvolvedores, analistas, stakeholders. Todos devem estar cientes dos processos de desenvolvimento e devem sentir-se aptos a contribuir com ideias e praticar empatia com o usuário.
Nunca esqueça da comunicação, colaboração e confiança entre os times!
Autor │Jean Carlos da Campo │UX designer
