Double Diamond na prática: como redesenhei uma plataforma interna de registro de ponto sob a perspectiva do design
Processos, vivências, problemas enfrentados, algumas dicas e +
Pandemia. Trabalho remoto. Novos modelos mentais.
O desafio do negócio era repensar a aplicação interna de registro de ponto dos colaboradores, deixando a plataforma mais dinâmica e fácil de dar manutenção. Porém, nosso contexto era um pouco mais complexo do que isso.
Meu objetivo inicial havia sido claro: transformar uma aplicação antiga em algo novo e mais fácil de usar, resolver alguns problemas e atuar, como UX Designer, na experiência dos usuários, sendo eles colaboradores, gestores ou área apoio.
Em design existe um framework para resolução de problemas, criado pelo British Design Council, que fala sobre o processo de design, suas convergências e divergências, chamado Doble Diamond:
É nesse framework que baseei todo o desenvolvimento que vou mostrar para vocês.
Primeiro passo: entender o desafio
Essa é a primeira parte do diamante, no qual o objetivo é entender o problema que estamos tentando resolver. Como mostra a imagem, descoberta diz respeito a abrir o leque e buscar informação, encontrar os problemas e levantar suposições. As ferramentas aqui são diversas, como entrevistas, desk research, benchmarking, análise de dados, etc.
Meu objetivo principal nessa fase foi buscar entender os comportamentos comuns dos usuários junto com a aplicação de ponto já existente. Um dos focos era estudar a jornada por completo, incluindo a parte em que o colaborador faz fisicamente nas máquinas de coleta de digital. E é bem aqui que entra o pulo do gato do Double Diamond.
CONTEXTO: 2020, lembra? Pois então. Essa primeira fase do diamante se iniciou lá pela metade de junho, quando o escritório da firma estava fechado e os funcionários já estavam há quase 2 meses em regime de home office. A empresa já havia se movimentado fazia tempo sobre trabalho remoto, tanto que já existiam colaboradores e projetos sob esse regime antes mesmo da pandemia; porém não era uma realidade consolidada e 2020 veio para mudar isso.
Mas então, como cargas d’água eu vou conseguir definir meu desafio, sendo que toda a empresa está mudando sua forma de trabalho?
E como John Dewey já falou, o problema:
Qual era a minha situação? Tomei o trabalho remoto como situação first.
E para tentar driblar esse pequeno degrau no processo, onde eu não sabia direito dos comportamentos (nem mesmo os usuários sabiam), foquei todas as minhas forças em falar com a maior quantidade de pessoas possível sobre sua jornada de registro de ponto, procurando conversar mais profundamente com colaboradores que já faziam o uso de ponto remoto da empresa, entendendo suas dores, suas frustrações e suas preciosas soluções. Para isso, segui alguns princípios da pesquisa em Design:
- Neutralidade: a ideia aqui é buscar pontos de vista. Foram mais de 3 semanas marcando reuniões e fazendo encontros, com pessoas que eu nunca havia nem visto, mas que foram de um valor que até hoje não consigo medir. Essas reuniões aconteceram remotamente, a maioria pelo famigerado Zoom e, em grande parte das vezes, levavam mais de 1 hora. Perfis de gestão consumiam um pouco mais, pois além de verificar a jornada como colaborador, a rotina da gestão envolvia avaliações, exportação de relatórios, acompanhamentos de custos, entre outras coisas.
- Confiabilidade: se não é confiável, não vale. Nesse quesito, eu armei cuidadosamente minha munição, pois era imprescindível que eu passasse (e recebesse) confiança e credibilidade. Estamos falando de rotina entre colaborador-empresa, muitas vezes uma relação sensível e que poderia, nesse caso, me retornar informações imprecisas. Citar aquelas famosas frases, como: “o que você faz não está errado”, “estou trabalhando para entender como poderíamos melhorar a aplicação”, me ajudou muito. Outra coisa que externei e que me foi de grande valor, foi explicar os motivos da entrevista, os envolvidos e os desafios.
- Generalização: a solução precisa ser de todos. Ponto é uma aplicação que envolve todos, né? E uma prática que se tornou recorrente nessa fase foi validar problemas relatados por outros entrevistados, o que fazia com que o meu roteiro e minha lista de perguntas fosse aumentando a cada reunião.
- Empatia X Alteridade: estudar o contexto. Esse pilar ficou (e ainda está) diluído nas etapas, pois a cada novo passo que dou, repenso no conhecimento que reuni até aqui. Primeiramente, buscava deixar o ambiente o mais descontraído possível, tentando entender onde estava a pessoa, observava seus pontos sensíveis, tentava absorver um pouco da essência do colaborador. Perguntas como “onde você mora?”, “costuma ir como para o trabalho?”, “tenho dois gatos, tem pets também?”, “a rotina de horários com eles fica complicada né, como você lida com isso?”, etc. Cada encontro era uma nova surpresa e isso me fazia ficar mais conectada com os problemas relatados.
Então, como resultado dessa primeira fase, entendi que era a hora de ressignificar o problema e reorganizar as abordagens que deveria focar daqui para frente:
- Preciso trabalhar cenários, sendo um deles focado na jornada do pré-pandemia, um no durante-pandemia e outro no pós-pandemia.
- Preciso acompanhar os comportamentos imediatos, já que o home office generalizado é uma situação que poderá ser normalizada no pós-pandemia.
Segundo passo: definição
Essa é a parte do foco, onde a ideia é analisar as informações coletadas, identificar oportunidades e redefinir o problema a ser resolvido. O principal objetivo aqui é conseguir visualizar os insights da etapa de descoberta, através de demandas, potenciais cominhos ou até priorização de pontos de ataque, já que o desafio em questão é bem complexo.
Existem diversas ferramentas aplicáveis aqui, sendo a mais valiosa, na minha opinião, a definição de personas.
A criação de personas auxilia a visualizar quem irá se beneficiar das melhorias propostas, ajudando a entender se aquilo que estamos em mente faz sentido ou é apenas algo para dar tamanho ou dar “wow sem valor” (é legal? É. Mas as vezes não tem muito valor).
Depois do apanhado de insights e percepções da fase anterior, comecei a fazer um processo que chamamos de Clusterização, que funciona como uma “grande parede de post-its”. Utilizei o Figma como ferramenta e o objetivo foi conseguir separar mentalmente o que era repetido/relacionado, então o que era possível e impossível de se resolver e, por fim, os problemas que geravam mais valor caso resolvidos. E foi aqui que as coisas começaram a tomar um pouco mais de forma e a nuvem começou a se dissipar.
E para dar continuidade, três pilares importantes do processo de design que me ajudaram no desenvolvimento de ideias:
- Centre sua priorização nas pessoas
- Explore soluções
- Priorize de acordo com o valor entregue
Terceiro passo: desenvolvimento
Com base nos dados recolhidos até aqui e no direcionamento que definimos, essa é a terceira fase do framework e ela diz respeito a geração de ideias/soluções.
Antes de começar a pôr a mão na massa, reservei um espaço de tempo para estudar o que havia recolhido até aqui. Revisei e anotei insights, revisitei algumas pessoas, revi exemplos de soluções parecidas, etc.
Existe um pensamento comum que fala sobre pôr tudo e qualquer ideia “para fora” com o objetivo de conseguir dar espaço para ideias novas, e foi exatamente isso que fiz. Retirei um dia para desenvolver e prototipar todos os insights com alguma relevância e que foram priorizados na fase anterior, fazendo opções e testando fluxos. Esse exercício me fez enxergar que algumas coisas não faziam sentido quando colocadas uma ao lado da outra, me fazendo entender que às vezes precisamos nos desapegar de ideias apaixonantes para que o real valor da funcionalidade apareça.
É louco pensar no quanto a gente produz quando está empolgado. De uma hora para outra vi meu espaço de trabalho no Figma ficar confuso e, para resolver, acabei criando uma página chamada “Trash” e outras com o “- old”, onde eu guardava todas as versões da ideia; tudo para entender o que deveria ser deixado de lado naquele momento. Vai que eu precise daquilo mais tarde, né?
Eu também deixava minha produção o mais explicativa possível, usando cores, números, palavras, frases, ícones, etc. A ideia aqui foi usar minha área de trabalho como um “cérebro”, onde eu deixava guardado todo e qualquer insight. Como um grande repositório de memórias de curto prazo.
E nunca se esqueça: TESTE. TESTE. TESTE. As vezes o que é fácil e real para uma realidade, não é para a outra.
Quarto passo: os entregáveis
Essa é a última parte do Diamante, onde a minha atenção foi focada em organizar o conhecimento que havia construído até agora. Foi o momento de me aproximar mais da equipe, verificar como era o método de trabalho, as necessidades dos envolvidos, as ferramentas que usavam.
Style guide e componentes, fluxogramas, comportamentos, descrições de funcionalidades, organização de arquivos.
Componentizar tudo. Usando o Figma, foi muito tranquilo fazer a componentização dos elementos da interface, já que existem diversas formas para isso. O que me ajudou aqui foi ter tido uma iniciação no assunto (o que me deixou apaixonada pelo recurso) e também já ter trabalhado na organização de uma aplicação: eu já entendia o que funcionava melhor, como descrever alguns comportamentos, sabia de alguns hacks.
Como descrever fluxogramas de uma forma fácil e que faça sentido para o desenvolvedor? Ah, e que o carregamento do Figma não ficasse pesado. Separei junto com a QA do projeto o sistema em USs, dentro do DevOps. Nessa parte, auxiliei a QA no entendimento das minhas ideias, as vezes alterando uma coisa ou outra. Com esse trabalho finalizado, comecei a organizar os arquivos para inserir nas USs de uma forma mais detalhada.
Me deparei com um obstáculo: Figma free. Para quem não sabe, na versão Free, não conseguimos publicar bibliotecas de componentes. Para resolver esse meu pequeno problema, tive que organizar os códigos das USs em páginas, dentro de um único arquivo.
Para auxiliar no entendimento dos fluxos, usei um Plugin chamado Autoflow.
E para me auxiliar na explicação de comportamentos, criei um tipo de post-it, que inseri nos arquivos pontualmente.
Mas para que tudo isso?
É importante entender que o framework que trabalhei, o Double Diamond, é um ser vivo e que deve ser revisitado sempre que houver necessidade. Por isso a utilização de tantas ferramentas de indexação. Para a aplicação, separamos um projeto no DevOps e um projeto no Figma, que precisam andar juntos. Façam a relação, não deixem links perdidos, salvos nos favoritos de uma única pessoa ❤
Acabamos de iniciar o desenvolvimento da aplicação e é louco pensar que a existência de um produto as vezes passa por todo um processo que não se costuma enxergar. O conhecimento foi imaginado e depois construído, envolveu muitas pessoas, tempo, dedicação.
Coisas que aprendi
Entender os desafios e deixá-los paralelos no processo inteiro faz muita diferença. Foco no desafio, foco no problema. Foco nas pessoas.
Envolva todos os setores que poderiam fazer sentido na discussão. As vezes é melhor ter questionamentos demais do que ver que alguém relativamente importante não participou do processo.
Documente todas e quaisquer decisões tomadas. É mais comum do que você imagina definir algo e depois cair no esquecimento o que foi acordado.
Deixe claro para a equipe que o projeto é um ser vivo, que sofre mudanças a todos os momento e que talvez essa semana ele seja diferente do que discutimos semana passada (e está tudo bem).
Não pressuponha que algumas informações são óbvias: peque pelo excesso de explicações, mas nunca pela falta delas.
