Por feedbacks de design mais significativos

Como melhorar sua produtividade com feedbacks mais eficazes

Inconsistência de estilos tipográficos, margens que variam de uma tela para outra, quebra de hierarquia de informação e termos diferentes entre telas são alguns dos pontos que provavelmente toda equipe de design já recebeu de feedback quando seu trabalho chega aos desenvolvedores. Como você faz para saber o que sua equipe de design mais erra para poder capacitar adequadamente?

Apesar de nossos esforços em comunicação interna, como cada designer trabalhava em um projeto, era muito comum esses mesmos erros serem cometidos em diferentes projetos, às vezes até superando as horas previstas de Design. Como evitar retrabalho, identificando o que a equipe mais erra?

Uma das alternativas foi adotar o conceito de Design System para a empresa, que pudesse ser adaptado para cada projeto. Porém, assegurar que a equipe de design passará a seguir um Design System específico não é uma tarefa tão fácil. Por isso, rodadas de feedback são tão importantes.

Aqui na Taqtile, o feedback é muito valorizado como forma de aprendizado e oportunidade de crescimento. Ele é fundamental para compartilhar conhecimento, gerando crescimento pessoal e profissional.

Queríamos construir feedbacks mais significativos e eficazes: mais humanos, com conversas produtivas, construindo empatia e colaboração entre as diversas áreas da empresa.

Revolução do Freehand

Com o lançamento do Freehand, nossas antigas reuniões de Design Critique viraram digitais, mais rápidas e dinâmicas. Antes, fazíamos uma reunião presencial para que uma equipe multidisciplinar avaliasse a entrega de design daquele Sprint. Agora, o designer lança as telas direto do Sketch para um link do Freehand e as pessoas do time entram rapidamente para comentar.

Parecia perfeito, mas ainda estávamos vivenciando alguns problemas…

• Muitas vezes, a pessoa que comentava não entendia bem o contexto e o fluxo do que estava sendo apresentado;
• No mundo ideal até os clientes poderiam comentar o Freehand, mas como trabalhamos com grandes corporações geralmente os links são bloqueados ou o cliente não tem tempo para isso;
• O designer esperava um bom tempo até partir para as melhorias, porque algumas pessoas demoravam para comentar;
• Era difícil entender o que exatamente a pessoa disse, ou entender o que quer dizer aquele feedback vago: “essa cor não está adequada";
• Não se tem um dado quantitativo preciso sobre o que a equipe está mais errando e o que precisa ser reforçado em termos de capacitação;

Quem já não se deparou com a bagunça que fica o Freehand depois que toda a equipe comenta?

O Freehand faz maravilhas para feedback pontuais, apontar pontos e comentar. Porém, feedback é também um processo importante de aprendizado e a ferramenta não estava enriquecendo o diálogo entre as áreas e o cliente, já que não é muito conversacional.

Testes cruzados

Para resolver esse gap, nos inspiramos em como os devs já controlavam os testes cruzados de aplicativos e criamos um processo:

1. Durante o Sprint, o designer continua compartilhando com a equipe as telas que está fazendo pelo Freehand e diariamente verifica os pontos que estão sendo apontados, também lembrando a equipe de comentar;
2. No mínimo 3 dias antes da entrega, fazemos um teste cruzado: 1 designer e 1 dev se reúnem com o designer autor por 30 minutos no máximo para testar um protótipo navegável das telas, assim os testers tem noção clara do fluxo e de como o aplicativo funcionará nos smartphones;
3. No teste, o autor explica o contexto em que o protótipo e o projeto se situam para entender que tipo de feedback que é exigido dos testers naquele momento.
4. Eles analisam o protótipo junto com o Styleguide, procurando primeiro questionar o autor sobre suas escolhas de design para depois apontar pontos de melhorias, exemplo: “Por que você colocou esse texto específico como H3 e azul?”. Assim, o aprendizado se faz por questionamentos em vez de apontamentos e ao reconhecer um possível erro, os testers explicam o por quê de sê-lo e oferecem sugestões;
5. As dúvidas sobre aquele feedback são tiradas na hora e o designer autor anota tudo o que foi comentado em uma planilha, categorizando seus erros e contabiliza e categoriza os erros para todos terem noção de quais erros são os mais comuns.

Nossos últimos erros contabilizados e categorizados: estilos tipográficos precisam ser melhor trabalhados que cores nas nossas capacitações

Por que isso é bom

• Cria empatia com os devs, convidando um dev para apontar problemas mais técnicos para implementar aquela solução de design proposta;
• Feedback em profundidade, mais humano, conversacional, e com um tempo definido para acontecer;
• O registro na planilha mostra graficamente os pontos fracos da equipe que precisam ser reforçados durante a capacitação

Mas isso não atrasa o processo?

Pelas nossas experiências, entregar um design com esses erros faz gastarmos o dobro do tempo para arrumar depois. Ao minimizar estas falhas, podemos aproveitar o tempo para focar em outras melhorias para o produto, como interações memoráveis, transições únicas, entre outros. No fim, é trazer mais valor para a experiência do usuário.

Construir aplicativos e sites é construir sistemas, não apenas um conjunto de páginas. A entrada de novos designers sempre pode acontecer e por isso é preciso capacitá-los para reduzir a chance de erros. Nossos pontos de melhoria ficam registrados em uma planilha e categorizados justamente para sabermos onde a equipe está errando mais e podermos focar a capacitação das pessoas nessas áreas.

Acha que esse tipo de feedback ajudaria você também? Como você dá feedback para a equipe? Deixe seu comentário.

Referências

Invision — How to Give Designers Better Feedback

A List Apart — Design Criticism and the Creative Process