UX Como SAC

Já parou para pensar em quanto tempo se perde para que uma reclamação ou sugestão de um cliente consiga chegar até você no desenvolvimento de um produto? 

Eu já, mas confesso que só depois que esbarrei em uma abordagem nova de pesquisa, tão simples e natural que fiquei pensando como não é assim em todo lugar e por mais que eu gostaria de falar que fui o responsável, ela aconteceu por uma feliz soma de fatores: Um time engajado, proximidade física dos clientes e uma combinação especial de pessoas. 

Normalmente em empresas de maior porte, o consumidor está longe não só fisicamente, mas o próprio organograma joga contra, fazendo com que as pessoas que possuem relacionamento direto com o cliente não possam compartilhar seus aprendizados diretamente com o design e desenvolvimento do produto. 

E não é só isso, muitas vezes toda essa linha de frente é setorizada entre comercial, suporte e pós venda, contribuindo ainda mais para fragmentar e perder valiosas informações que para você seriam cruciais. 

E por fim essas pessoas estão mais preocupadas em vender, conduzir ao uso do produto ou serviço ou resolver rapidamente um problema. Elas tem uma meta de vendas, de quantidade de pessoas atendidas e até de tempo de atendimento para se preocupar; dificilmente irão anotar cada reclamação ou ideia que um cliente possa vir a dizer durante um atendimento. 

O time e o problema a ser resolvido 

Cheguei nas primeiras semanas do primeiro time que estava se organizando como um squad , ou seja, vários profissionais de habilidades complementares organizados 1 para atacar um único produto, neste caso o empréstimo consignado do banco. 

O time era quase todo novo, e estruturado inteiramente focado no desenvolvimento de software ágil , realizamos todas as cerimônias, como as daily scrum, sprint 2 planning, e depois começamos a renomear cada uma delas conforme fazia mais sentido por nós e também adaptando novas dinâmicas como algumas ferramentas do Design Sprint para geração e mapeamento de ideias. 3 

O produto que atuávamos era o empréstimo, é, uma modalidade de empréstimo onde basicamente você paga através de descontos na folha de pagamentos; exatamente por isso gera um risco menor para o banco que acaba se convertendo em menor juros, uma modalidade muito comum para aposentados, pensionistas e servidores públicos. 

De todo esse público como já citamos, a grande maioria são os aposentados, fazendo que um de nossos maiores desafios fosse o de desenvolver uma solução moderna, mas acessível para pessoas da terceira idade, muitas delas tinham pela primeira vez um smartphone e pouco ou nenhum contato com produtos digitais. 

Após uma etapa de pesquisa mais aprofundada, iniciamos nosso mínimo produto viável (MVP), uma primeira versão de software focado no usuário mobile que sintetizava todo um conjunto de hipóteses a serem validadas, com a menor quantidade de funcionalidades que entregam valor ao cliente. 

A primeira versão desse MVP era esteticamente excelente, digno de uma página no Dribbble (comunidade para designers), mas logo no primeiro teste com clientes, percebemos que era só bonito. Falamos com um, dois e no terceiro cliente veio a ideia meio diferente, de fazer todas as páginas sem scroll. 

Fazia sentido, já que 10 entre 10 clientes poderiam até não usar o Facebook, mas usava o WhatsApp, onde o scroll era automático. O resultado veio rápido, e percebemos que tinha muito mais a aprendermos; cada vez mais próximo de nosso público. 

O mais importante foi que cada conversa trazia alguma coisa, e cada vez mais elas foram se tornando mais constantes em nossa rotina. 

Conversas diárias, de um jeito ou de outro 

Em um dado momento, nosso MVP ganhou um pequeno botão de “ajuda" e lá os usuários podiam escolher utilizar o WhatsApp ou fazer uma ligação telefônica e foi dessa forma que as coisas começaram a ficar realmente divertidas, visto que o cliente começou a vir até nós. 

Tínhamos um telefone dedicado que tocava na minha frente e todos do time sabiam que quando aquele telefone tocava era um cliente do banco e quase sempre era com alguma dúvida ou reclamação, mas todas as vezes uma oportunidade única de aprendermos algo sobre nosso produto se ouvíssemos com a atenção devida. 

O produto era disponível apenas para parte da base de clientes do banco, e isso garantia suficientes ligações para gerar bons feedbacks, mas não a ponto de precisarmos de alguém dedicado para isso. Tinha um equilíbrio ideal, e com certeza estávamos no número certo. 

O Product Owner (PO) do time era uma figura sem igual, que na época tinha pouca 4 experiência de tecnologia, entretanto, possuía mais de uma década nos processos do banco e empatia com as pessoas. E entre outras coisas, ele dizia detestar o termo “usuário", pois isso remetia algo negativo e distante, e talvez por isso quando atendeu a primeira ligação que tocou naquele telefone, disse: 

ParanáBanco, bom dia, setor de experiência do cliente...

Pronto, sem perceber ele tinha batizado o nome que usamos dali por diante toda vez que falávamos com os clientes... E foi o exato momento que percebi que estávamos fazendo algo ligeiramente diferente. 

Resolvi, então, comparar tudo o que estávamos fazendo com o de pesquisas tradicionais, e cheguei na seguinte tabela: 

Dois ou três dias depois da primeira ligação eu atendia as ligações, e é óbvio que ainda não tinha conhecimento de todos os processos do banco e pedia auxílio para resolver problemas, mas já conseguia identificá-los e, classificá-los. 

Isso muda toda a dinâmica de feedback, não apenas na quantidade que pode aumentar muito, mas na qualidade, que pode gerar resultados em áreas até onde você não estiver procurando. 

Certa vez, durante uma dessas conversas, descobrimos uma falha que atingia somente usuários do navegador “Internet" que geralmente só telefones Samsung possuem como padrão, um navegador que nem conhecíamos e claramente não testávamos até aquele momento. 

O bug descoberto nem precisou se tornar uma história de desenvolvimento, foi resolvido em poucas horas e no dia seguinte já tivemos mudança instantânea na quantidade de pessoas que passavam através do chamado "funil de conversão". 

Algo que também surgiu naturalmente foi o processo de pedir permissão para o cliente para atendê-lo em viva voz, a ideia era tornar todo o time ciente de um determinado problema, e assim aumentar a empatia geral, puxando a responsabilidade para todo mundo ali. 

Essas ligações quase sempre gera alguma discussão depois, afinal, queríamos relacionar aquele porque com algum dado maior, saber quantas pessoas estavam vivenciando aquilo. 

Os problemas poderiam ser classificados em: 

1. Bugs a serem resolvidos;
2. Ajustes de usabilidade;
3. Insights de produto;
4. Novas funcionalidades. 

O fluxo de cada coisa: 

1. Bugs a serem resolvidos 

Todas as falhas que pudéssemos resolver rapidamente não entravam necessariamente na sprint, isso se fossem muito críticas ou muito rápidas para serem resolvidas, já se o esforço fosse maior ela seria mapeada na sprint semanal de acordo com sua criticidade. 

2. Ajustes de usabilidade 

Todo o restante era registrado em post-its e apresentadas ao time semanalmente como "Design Insights" antes da sprint planning, reunião em que alinhamos as demandas da próxima sprint. 

Os ajustes de usabilidade por exemplo eram parecidos com os bugs, podendo ir de coisas pequenas -como descrições - ou maiores - como a mudança de um elemento completo - e quase sempre se tornavam tarefa da próxima sprint. 

3. Insights de produto 

Sabe quando alguém te diz algo que te oferece uma luz diferente? É mais ou menos isso. Os insights eram basicamente novas formas de fazer algo: podia ser um fluxo mais curto, uma forma de comunicar algo de acordo com a própria descrição do cliente. Aqui tudo dependia muito da nossa percepção de ganho com o insight gerado, se fosse a mudança de um texto ou botão logicamente poderia acontecer no mesmo dia, já no caso de um fluxo poderia entrar no backlog de produto. 

4. Nova funcionalidade 

Esse era provavelmente o cenário mais raro de acontecer, até porque já tínhamos muita coisa mapeada no backlog, e aqui com toda certeza iria passar por uma etapa mais longa de discussão e até de ideação na qual por algumas usamos a dinâmica Crazy 8 que retirei do Design Sprint. 5 

Aliás não apenas ela, mas várias ferramentas do Design Sprint podem ser tranquilamente adaptadas para a realidade do desenvolvimento de software ágil, mas talvez esse ponto específico seja papo para outro livro. 

Conclusão

‍As conversas diárias geradas por essa mudança conseguiam mudar toda a percepção do time, isso nos tornou mais atentos ao que diferentes tipos de públicos tinham como necessidades e desejos, além da quantidade de feedback gerada pelo cliente que possibilita maior velocidade na melhoria de produto 

Já a abordagem como SAC garantiu feedbacks mais reais, afinal, foi se tornando cada vez mais claro que as pessoas suavizam falhas quando conversávamos como uma pesquisa, e tinham completamente outra postura enquanto SAC. 

Porém o maior de todos os ganhos em minha opinião foi na forma como todo o time passou a encarar tanto o problema, os clientes, com muito mais empatia e responsabilidade no valor gerado de cada funcionalidade, de cada elemento de design e cada linha de código implementada. 

Você passa a se importar muito mais se sabe que tem gente dependendo daquilo, enxerga essas pessoas, ouve essas pessoas e sabe que a vida delas podem depender de você, isso muda sua percepção do que faz. 

Você devia tentar também! 

Agradecimentos a Ricardo Porciúncula, por sua contribuição no desenvolvimento dessa abordagem, e ao presidente do Banco, Cristiano Malucelli por possibilitar a compartilhar esse aprendizado e claro ao Squad inicial do PB: 

Renatinho, Luan, João, Fábio, Bini, Kimura, Wagner, Meggy, Bruna e Eduardo. Vocês são foda! 

--

1 Caso você se interesse em entender mais sobre a organização em squads recomendo o texto "Scaling agile @Spotify with Tribes, Squads, Chapters & Guilds" escrito por Henrik Kniberg e Anders Ivarsson. 

2 Quase tudo que sei sobre ágil foi na prática, mas recomendo fortemente o livro "Scrum: A arte de fazer o dobro do trabalho na metade do tempo" escrito por Jeff Shutherland. 

3 O Design Sprint é uma metodologia para desenvolver uma hipótese, prototipar uma ideia e testá-la rapidamente com o mínimo de investimento possível em um ambiente tão real quanto possível, de forma colaborativa e com tempo restrito. 

4 O Product owner no time é a pessoa responsável por priorizar as funcionalidades que vão compor o produto, separando no que é prioritário, o que pode esperar e o que ficará de lado. 

5 O Crazy 8 é uma dinâmica do Design Sprint da fase de esboço que consiste em dobrar uma folha de sulfite em 8 espaços iguais e esboçar 8 ideias dentro de um intervalo de 8 minutos.