Construindo uma plataforma de Chargeback (antes da Black Friday)
Esse foi o meu segundo projeto como Designer de Produto na Dextra (atual CI&T). Quando estava sendo escalado, o Squad Leader passou a seguinte missão:
“Precisamos melhorar os processos de Chargeback do cliente e adaptar alguns fluxos para uma nova plataforma. O prazo é antes da Black Friday.”
Faltavam 2 meses.
Objetivos do projeto
Como o propósito do projeto era criar uma plataforma do zero, não haviam muitas métricas numerais a serem atingidas com o piloto. Mas, é possível listar alguns motivadores:
- A empresa em questão quer se tornar referência em Chargeback no Brasil;
- Não existia mão de obra com essa expertise no time interno, por isso fomos contratados;
- É esperado que o número de e-mails trocados entre a empresa e seus clientes reduza consideravelmente; além de unificar os processos de análise, com todo o foco na nova plataforma.
- Diminuir em 30% o número de Pedidos enviados para a Mesa Classificadora (uma forma humana e manual de classificação)
Resolvi aceitar o desafio. O início foi bem tranquilo, só foi preciso saber contexto do que já tinha sido feito, já que eu estava substituindo um Designer, também da Dextra. Por isso dizemos que a parte mais importante da função de Designer de Produto é investigar, como bem diria o Bruno Vaz no seu artigo
Ele resume bem esse papel investigativo, dizendo:
“Muita coisa se passa antes de podermos soltar a mão e desenhar uma nova tela, de fato. A parte inicial do projeto é quando precisamos investigar os detalhes e aprender tudo o que podemos sobre o nosso cliente e seu negócio, sobre como os usuários se comportam e quais são suas necessidades. É quando fazemos as entrevistas com o público e stakeholders, estudamos o objetivo do produto, buscamos referências e, assim, que essa história começa a fazer mais sentido na nossa cabeça.
É justamente esse o momento que eu uso para entender o projeto e ganhar propriedade sobre o conteúdo e sua estrutura. Conhecendo bem a proposta do produto e o contexto no qual ele está inserido fica muito mais fácil de traduzir isso em uma experiência única, que faça sentido na cabeça dos usuários.”
Então, nessa etapa de detetive, me aprofundei em conversas com alguns dos stakeholders para entender o objetivo do projeto e qual o valor nós precisávamos entregar para a época mais concorrida no varejo brasileiro.
Somente após esse entendimento eu pude começar a trabalhar nos principais fluxos da plataforma, que tem os seguintes usuários:
Entidade (ou Loja)
São os clientes da empresa. Toda compra feita nessas lojas é registrada e analisada; caso haja alguma fraude, a Entidade pode solicitar reembolso e iniciar um processo de análise mais apurado.
Analista
É a pessoa responsável por analisar Solicitações de Reembolso ou Reclassificação.
Analista Comercial
É a pessoa que solicita a abertura de uma Exceção.
Esses 3 usuários, diariamente, fazem uso dos seguintes fluxos:
Solicitação de Reembolso
Esse fluxo é a principal funcionalidade da solução: É por meio dele que as Entidades poderão ser ressarcidas em casos de fraude.
Mesmo depois de refinar o fluxo, eu ainda não tinha conseguido fazer testes de usabilidade. Decidimos então que o piloto seria testado em um ambiente de homologação.
Ambiente de homologação é usado para fazer testes e ver o produto rodando, sem afetar diretamente uma versão que já esteja de fato online.
Mas eu não podia esperar esse dia, que estava um pouco longe, pra confirmar se estava fácil de compreender. Resolvi então fazer um teste pelo Maze com os outros designers da Dextra. Eu o dividi em 6 missões, que seriam todas as etapas para uma Entidade concluir o processo.
No total foram 29 testadores. Apesar de não serem, necessariamente, o usuário alvo da solução, ainda assim consegui alguns insumos interessantes:
Na etapa de Abrir uma solicitação 28% dos testadores concluíram a etapa por um caminho indireto. No sistema, não existe um caminho fixo para abrir as solicitações e, na verdade, pode acontecer de ter mais de 1 solicitação de reembolso por pedido.
Esses testadores abriram a solicitação após navegar para a tela de Detalhes do Pedido. Isso abre espaço para o questionamento: Será que devia estar mais evidente o caminho para solicitar reembolso?
Quando chegou o momento de associar os documentos anexados aos tipos corretos 85% dos testadores concluíram por um caminho indireto.
Apesar de discrepante a diferença, notei que na verdade isso se deu por conta de um comportamento do Maze que considerou o componente pop-over como uma nova tela.
Meu ponto de atenção aqui é na duração da missão. Enquanto alguns demoraram entre 14 e 17 segundos, outros demoraram de 30 a 70 segundos.
Isso me fez pensar “O que fez esse tempo ser tão longo? Será que o protótipo estava demorando pra carregar? O esforço cognitivo da tarefa estava alto?”
Como se trata de um processo muito específico. Resolvi levar esses questionamentos para o dia de testar o piloto com uma das Entidades.
Análise de Solicitações
Esse foi o fluxo mais simples de se trabalhar, pois já estava bem redondo. Meu único esforço (até então) para concluir essa etapa foi criar uma conversação antes de aprovar ou recusar uma solicitação.
Quando cheguei no projeto, as telas pra esse fluxo já estavam construídas, então eu não precisava, de fato, dedicar tempo a rever a arquitetura de informação nelas, correto?
Resposta: Errado!
Como nem tudo são flores e um produto digital está evoluindo constantemente, nós percebemos que cabiam e faziam muito sentido algumas mudanças na forma de apresentar as funções do Analista nessa tela.
Antes, quero mostrar como estava a tabela de validação de documentos em um primeiro momento:
A princípio nada de errado: O Analista precisa definir um status para o documento avaliado; em caso de recusa, deve escolher uma justificativa; e para visualizar ou baixar os documentos ele clica nos 3 pontinhos à direita. Mamão com açúcar.
Mas, durante uma sessão de refinamento com os devs, percebemos alguns problemas de usabilidade e de desenvolvimento.
Falando de desenvolvimento, da forma que estava, era preciso guardar as alterações de todos os documentos para só após a Recusa ou Aprovação da solicitação como um todo, enviarem os dados dessas mudanças para o sistema, tornando a aplicação pesada.
Já na questão de usabilidade, os problemas estavam nas áreas destacadas na imagem acima. Então decidimos fazer alguns ajustes na arquitetura da informação e o resultado foi esse:
Reclassificação
Complicado e Perfeitinho, você me apareceu! 🎶
Eu perdi as contas de quantas sessões de refinamento usamos para falar sobre esse assunto. Quando eu entrei no projeto, ele já havia sido trabalhado, mas não estava redondo ainda; então constantemente os stakeholders precisaram voltar nesse assunto até o processo estar claro tanto para nós da Dextra como para o cliente.
A regra de negócio por trás da Reclassificação é bem simples, no fim das contas. Todo esse processo vai substituir uma quantidade considerável de e-mails que são enviados para a empresa avaliar essas contestações.
Agora tanto a Entidade quanto o Analista vão fazer toda a sua jornada dentro da aplicação, sem precisar ter maior esforço cognitivo ao navegar para o e-mail e voltar.
Exceções
Esse foi um dos fluxos que eu mais gostei de trabalhar. Quando cheguei no projeto, ainda não haviam discussões em volta da abertura de Exceções — precisávamos fazer um Discovery.
Foi aí que vi a oportunidade de 3 pontos chave: usar a metodologia da Matriz CSD (Certezas, Suposições e Dúvidas); trabalhar em conjunto para definir o que era a Exceção em sua essência e também desenhar o fluxo para que ficasse documentado.
Depois de validar todas as Suposições e Dúvidas, conseguimos construir o fluxo da funcionalidade em formato de Ficha de Serviço (ou Blueprint) e a partir daí, fizemos os primeiros rascunhos da tela. Usamos como base a funcionalidade de Aprovação em Lote, que tinha uma estrutura de componentes semelhante e que iria servir para esse caso. Afinal, pra que reinventar a roda, não é mesmo?
Porém, o entendimento sobre como deveriam funcionar as Exceções estava defasado e o fluxo estava se tornando muito mais complexo que o previsto; portanto, resolvemos reordenar o escopo do projeto.
Por questões de sigilo, não posso me aprofundar em nenhum dos fluxos por enquanto.
Em paralelo à construção dessa plataforma, eu também estava ajudando a equipe de Monitoramento no redesign dos gráficos indicativos usados para analisar métricas.
Basicamente estávamos adaptando gráficos com padrão de Excel para uma dashboard moderna e intuitiva; então passei a compartilhar meus conhecimentos de heurística e padrões de design cognitivo e acompanhar, na prática, os ajustes sendo feitos na ferramenta de Power BI.
Quando me apresentaram a dashboard, percebi que ela apenas cumpria o seu papel: mostrava dados em forma de gráficos. Comecei então um trabalho de consultoria em Interfaces de Usuário e, com base em estudos, mostrei a importância de facilitar a visualização de dados.
Usei como referência dois artigos aqui do Medium, que apareceram justamente no momento em que eu precisava de endosso.
A consultoria foi bem produtiva e em poucos dias, recebi uma devolutiva com todos os pontos que eu abordei e foi muito bom perceber que eles foram acatados, sinal de que fazia sentido para eles.
Outro ponto de atenção foi o fato de a primeira versão estar em Tema Escuro. Seguindo os padrões de aplicativos e programas que já estamos acostumados, o ideal é seguirmos com o Tema Claro, para melhor contraste e apresentação dos dados. Deixamos a versão escura (minha preferida, aliás) para momentos futuros.
Ao final desse período de ajustes conseguimos chegar em um resultado consistente e agradável que foi considerado nosso Mínimo Produto Viável (ou v1.0) — para o Monitoramento.
Voltando para as Solicitações e Análises, foram alguns dias tensos, que requisitaram grande esforço da equipe para apagar pequenos incêndios até eu poder voltar a falar de testes de usabilidade.
Já que a data de entrega dos fluxos de Solicitação de Reembolso e Análise de Solicitações foi alterado e haviam questionamentos se “Vocês validaram essas telas com a entidade?” decidi voltar ao Maze para fazer meus testes. Então, recriei as missões com as tarefas necessárias, agora com novos ajustes em cada fluxo.
Essa foi uma oportunidade de ouro, pois descobrimos que não havia a cultura de fazer testes de usabilidade dentro da empresa e nós como consultores, usamos esse espaço como um entregável de valor. Parti então para fazer uma apresentação de venda do meu argumento (o famoso pitch de negócios) dos motivos para fazer a contratação de uma licença profissional do Maze e os benefícios que viriam. Deu certo! Apesar de uma certa resistência e a empresa ainda não se dispor a custear uma licença Empresarial, conseguimos implementar a gestão de testes de usabilidade de forma mais madura.
Porém, uma coisa que não compartilhei com vocês antes: devido a uma série de mudanças internas e no escopo do projeto, tivemos que adiar o lançamento do piloto e não pudemos fazer a entrega a tempo da Black Friday. Também demorou um pouco para começar a colher dados com o Maze, então ainda não posso trazer resultados dos testes. Mas esse que é o legal do Design de Produto, poder fazer parte da constante mudança e evolução de uma solução para o dia a dia de pessoas com rotinas muito diversas!
Futuramente eu volto com uma nova versão dessa postagem para contar o que definimos e implementamos após o replanejamento das entregas.
