Reestruturação de jornada
Um case real realizado no Banco Itaú
Introdução
Este case conta sobre os processos realizados para implementar a cultura de design numa squad responsável por uma área estruturante de um produto financeiro. Algumas informações e processos não serão revelados pelo fato do projeto ter informações sigilosas.
​
Trabalho utilizando um conceito com base no design thinking, chamado triple diamond. Este conceito oferece uma abordagem mais completa, assegurando que as soluções sejam continuamente refinadas e validadas com base no feedback real dos usuários. Isso resulta em uma experiência do usuário mais aprimorada e um ciclo de desenvolvimento mais eficaz, reduzindo riscos e melhorando a qualidade do produto final.
​
Primeiramente, busquei entender as demandas do projeto para definir os primeiros passos de intervenção.
Primeiros desafios
Após um período de observação e aprofundamento, identifiquei as principais dores existentes para realizar as primeiras intervenções com base no triple diamond.
Jornada construída sem suporte do design system
A jornada existente estava utilizando uma tecnologia desatualizada que não permitia a utilização dos componentes disponibilizados pelo design system.
Nenhuma documentação de protótipo
Não existiam documentações de protótipo sobre o conteúdo que já estava em produção, ou seja, disponível para o usuário final.
Nenhuma pesquisa anterior disponível
Não existiam documentações de pesquisas anteriores, nem de levantamentos realizados sobre o conteúdo que já estava em produção.
Muitas demandas definidas com curto prazo
O time estava habituado a realizar entregas rápidas e sem o aprofundamento necessário para realizar os processos de design corretamente.
Primeiros passos
Entender a dinâmica e momento da squad
Ao fazer parte da squad, passei por um período de análise para compreender a dinâmica do ambiente, das pessoas e do produto.
Entender o funcionamento estrutural da empresa
Além de conhecer a squad, utilizei uma visão holística do ambiente, compreendendo a empresa como um todo.
Conhecer as API`s e funcionamento técnico
Realizei um levantamento das informações e funcionalidades disponibilizadas pelo time de tecnologia.
Analisar dados já existentes
Fiz um levantamento histórico sobre o produto e das informações que estavam ao meu alcance, como regras de negócios, OKR's, dados do Tableau e Google Analytics.
Identificar o perfil dos clientes
Com a análise de dados existentes, busquei identificar o perfil de comportamento dos usuários que contratam o produto.
O que esperavam de mim
Após os primeiros passos, identifiquei na squad uma baixa maturidade em design. Não era esperado a realização de pesquisas ou dinâmicas de discovery que garantissem a qualidade das entregas. Esta identificação é importante para propor as primeiras negociações.
.png)
Primeiras negociações
Explicar os processos de discovery
Aos poucos, realizei conversas com o time, educando-os sobre os conceitos de design e a importância de cada etapa de discovery.
Explicar a importância de uma visão holística
Também expliquei sobre a necessidade da completude do produto e os impactos de uma visão mais ampla da jornada.
Negociar prazos e possíveis backlogs
Iniciei discussões sobre prazos, e possíveis soluções para garantir a qualidade das entregas.
Traçar um plano evolutivo
Construí uma ideia de plano evolutivo para definir uma previsão adequada dos futuros avanços do time, de acordo com sua realidade.
Primeiras intervenções
Realizar entregas emergenciais
Alinhei com a pessoa de negócios sobre as demandas mais urgentes, afim de, estrategicamente, entrega-las mesmo que sem a qualidade necessária, porém cumprindo os prazos exigidos, desde que todos estivessem de acordo com os impactos de uma entrega mais superficial.
Aumentar o backlog da squad
Ao entregar as demandas mais urgentes, aumentei o backlog da squad e assim, pude planejar com a pessoa de negócios os prazos necessários para realizar os processos de discovery corretamente.
Introdução das primeiras dinâmicas de discovery
Com os prazos negociados, iniciei com o time as primeiras dinâmicas necessárias para prosseguir com o projeto.
Análise de benchmark
Realizei uma análise de mercado para compreender como é a jornada do produto feito pela concorrência, aprofundando assim meu entendimento.
Documentar necessidades difíceis de resolver
Apesar das negociações, existem fatores que dificultam a resolução de algumas dores. Por conta disso, documentei essas necessidades para que aos poucos eu pudesse levar estas pautas para discussões.
Oportunidade - Figma para leigos
Muitas pessoas da squad não estavam ambientadas com o Figma. Porém, o Figma é a plataforma oficial da empresa para a realização dos trabalhos com design. Em meio a esta dor, encontrei a oportunidade de realizar workshops sobre as ferramentas básicas do Figma. Desta forma, as pessoas passaram a ser menos resistentes com a plataforma e passaram a utilizar com menos dificuldades.
Evoluções de discovery
A reestruturação da jornada do produto exigia um longo caminho, as regras de negócio são complexas e demandavam várias entregas. Ao longo do percurso utilizei algumas dinâmicas para o processo de discovery de acordo com o que era necessário aplicar.
Avaliação heurística segundo Jacob Nilsen
Utilizado para rever a jornada em produção. Feito em conjunto com a squad, sinalizamos os pontos que cumpriam ou não os 10 princípios de usabilidade de Jacob Nilsen.
Análise de dados de comportamento
A cada necessidade, realizava um estudo mais específico e aprofundado sobre as dores e comportamentos do usuário. Consumi dados do Tableau, Google Analytics, reclamações da central de atendimento e do Bacen.
Wireframes
Após o levantamento dos dados, era possível a construção de wireframes para alinhar as expectativas referentes ao projeto com o time, além de iniciar uma análise dos componentes disponíveis pelo design system.
Alinhamento técnico
Com a construção dos wireframes, realizei reuniões para alinhar o que era possível ou não dentro da realidade de tecnologia. Caso precisasse fazer uma nova construção de API, este ponto devia ser levado em consideração para a contagem do prazo de entrega.
Prototipação de média fidelidade
Após o alinhamento de expectativas e alinhamento técnico, realizei uma prototipação inicial para ser levada em rodadas de critique.
Método MoSCoW
Em situações mais complexas, utilizei o método MoSCoW para categorizar o que tinha que ser feito, o que deveria ser feito, o que poderia ser feito e o que não seria feito naquela entrega.
Matriz esforço x impacto
Para o desenvolvimento de um MVP ideal para suprir as principais dores e alcançar os melhores resultados, realizamos uma matriz de esforço x impacto para determinar quais iniciativas eram as mais adequadas para serem realizadas no primeiro momento.
Matriz CSD
Antes dos testes, utilizei a matriz CSD com o time para documentar nossas certezas, suposições e dúvidas. Desta forma, o time determinada quais eram suas principais dúvidas e hipóteses para serem validadas em testes com o usuário.
Teste exploratório
Nesta fase é realizada entrevistas qualitativas com 6 clientes de acordo com o perfil necessário para o projeto. Os testes exploratórios são utilizados para verificar o real valor do produto e a usabilidade da jornada. Neste momento validamos o quanto as soluções construídas fazem sentido para o usuário.
Debriefing do teste exploratório
Durante as entrevistas documentamos todas as percepções do usuário, essas anotações nos permitem realizar o debriefing da pesquisa, afim de entender quais foram os aprendizados e quais são nossas limitações, riscos e ideias.
Segunda rodada de prototipação
Após o debriefing, temos informações o suficiente para realizar alterações no protótipo de acordo com as percepções do usuário. Então, encaminhei essas alterações para momentos de alinhamento e critiques.
SUM
Caso os testes exploratórios tenham validado que o projeto realmente faz sentido para o usuário, realizamos mais uma rodada de testes, porém, desta vez utilizando o SUM - Single Usability Metric, afim de adquirir uma nota de usabilidade para o projeto. A nota mínima necessária para prosseguimento dos processos é de 90%.
Debriefing do SUM
Após a aplicação do SUM, realizei um momento de debriefing, afim de reunir todas as informações coletadas no teste, como mapas de calor, tempo de jornada, desvios e acertos de cliques, a satisfação do usuário e comentários.
Teste A/B
Em algumas situações foi necessário realizar testes A/B, com o propósito de comparar hipóteses diretamente com os usuários para entender qual teve a melhor performance.
Mapemaneto de riscos
Após coletar vários insumos, chega o momento e tomar decisões. Precisa-se entender se o projeto irá prosseguir para desenvolvimento e para isso construo um mapeamento de riscos para coletar problemas, hipóteses e os riscos de algumas decisões.
Consumo de materiais
Este projeto de reestruturação faz parte de uma grande estrutura, com vários times atuando em projetos vizinhos. Por conta disso, consigo adquirir mais informações avaliando testes de outros projetos, personas definidas pelo time de pesquisa, acompanhamento de projetos em andamento e demais estudos feitos pelo time de pesquisa.
Protótipo de alta fidelidade
Caso o SUM alcance a nota de 90%, construo o protótipo de alta fidelidade. Ele passa pelo último refinamento e é levado para validação técnica, de acessibilidade e com o jurídico.
Documentação
Após terminar o protótipo de alta fidelidade, chega o momento de documentar as especificações do projeto. Esta documentação defini a quebra de entregas, evoluções do MVP, descrição de cenários e regras e registro de alinhamentos. Além disso, passa pela aprovação de negócios, de tecnologia e acessibilidade, afinal esta documentação é utilizada por todos.
Estudos e entregas realizadas
Ao longo do processo de reestruturação foram realizados vários processos e dinâmicas.
04
Testes exploratórios
02
Testes SUM
01
TesteA/B
03
Avaliações heurísticas
07
Critiques
12
Entregas/
Documentações
O que foi evoluído
Após um processo de introdução da cultura de design e muitas negociações, foi possível colocar em pratica quase todo o processo do triple diamond, faltando apenas a etapa de revisão. Para isto, ainda é necessário evoluir as negociações, porém é importante reconhecer a evolução já adquirida.
.png)
Resultados
Após a fase de reestruturação, começam a aparecer os primeiros resultados.
Algumas informações não foram relatadas por terem conteúdo sigiloso.
Modernização da tecnologia
Toda a reestruturação teve modernização na tecnologia utilizada, que permitiu o aumento da performance de sua utilização e a possibilidade de utilizar design system disponível, o que diminui o tempo de desenvolvimento.
Mais detalhes de taguemento
A nova jornada teve um maior detalhamento de informações a serem coletadas nas plataformas de dados, podendo desta forma, realizar levantamentos mais assertivos de aprofundados do comportamento do cliente.
Valorização de informações relevantes para o cliente
Em toda a reestruturação, as principais informações ficaram mais evidentes para o cliente, informações menos relevantes foram inseridas dentro de accordions ou modais para que a quantidade de informações não aumentassem o esforço cognitivo do usuário, ajudando no foco e na tomada de decisões.
Jornada com writing e componentes mais consistentes e padronizados
No projeto antigo, as terminologias não tinham padrão nem consistência. Com a nova jornada todos os termos foram padronizados e muitos foram unificados, de forma que ficasse mais prático e simples para o usuário.
Maior controle e liberdade para o usuário
Com a nova fornada, o cliente pode navegar pelas configurações do produto com mais praticidade e sem carregamento de tela.
Mais detalhes para o cliente, sem perder o foco no mais importante
Foram incluídas informações que já estavam disponíveis na API, mas que não estavam sendo exibidas para o usuário. Desta forma, o cliente pode verificar mais informações do produto. Para não aumentar a carga cognitiva do usuário, estas informações adicionar foram incluídas desde de que o cliente clicasse num accordion ou modal.
Componentes reaproveitáveis para o front-end
Ao manter o padrão de consistência das terminologias e da lógica das tarefas, os desenvolvedores puderam utilizar componentes reaproveitáveis, diminuindo assim o o tempo de desenvolvimento.
Redução de cliques na jornada
A nova jornada permite que o cliente conclua a tarefa em menos cliques na tela, o que torna a navegação do cliente mais rápida, pratica e simples.
Previsão de aumento na conversão do funil
Com uma jornada mais simples, prática e intuitiva, a previsão é que mais clientes consigam contratar o produto.
Previsão de maior satisfação do cliente
Nos testes realizados os clientes relataram que a conclusão da tarefa foi simples e satisfatória. A previsão é de que os clientes se sintam mais satisfeitos ao utilizar a nova jornada.
Evoluções necessárias
Muitas melhorias foram conquistadas, porém ainda existem vários pontos a serem evoluídos que fazem parte do aumento da maturidade de design na estrutura da empresa. Algumas informações não foram relatadas por terem conteúdo sigiloso.
Prosseguimento da modernização do produto
Boa parte do produto foi modernizado, porém mais projetos precisam ser realizados para garantir 100% da jornada modernizada.
Evoluir na completude e consistência entre jornadas
Tudo o que foi reestruturado passou por um processo de consistência nas terminologias e lógica de usabilidade, porém esse ponto precisa ser evoluído entre projetos próximos que fazem parte de uma estrutura maior.
Intervenção nas APIs
Novas APIs precisam ser construídas para que o cliente tenha mais informações e possibilidades de usabilidade.