Design-to-dev: melhorando o processo de entrega entre times
Como abrir um canal de comunicação para construir um produto coeso e que entregue valor para os usuários?
por Daniel Granero e Carolina Barbosa Russi, do time da Sensorama Design
Assim como tudo na vida, projetos digitais também têm começo, meio e fim. E é sobre uma parte desse processo que queríamos comentar: a entrega das interfaces para o time de desenvolvimento.
Em julho de 2020, iniciamos o desafio de redesenhar uma solução para uma grande empresa de bebidas, um sistema interno, que ampara todo o processo de negociações com os clientes.
Em iniciativas como essa, para os UX/UI Designers existe o momento de entregar as interfaces para o time de desenvolvimento que vai programar essa solução. Isso é parte do curso natural de projetos digitais, sejam eles em uma empresa de tecnologia, numa startup ou num projeto de consultoria — como é o nosso. Esse é sempre um momento de atenção, pois tudo aquilo que o time de design criou (que vai muito além de telas) deve ser comunicado com precisão, para que os usuários tenham a melhor experiência possível, por isso é tão importante estruturar bem essa entrega.
Tudo correu bem, seguimos a metodologia de trabalho da Sensorama (entender-definir-realizar-validar) e conseguimos desenhar os módulos planejados dentro do prazo. Depois de passarmos por um momento de entregas muito agitadas, resolvemos dedicar um tempo pra rever nosso processo de entregas para o time de desenvolvimento, porque percebemos que estavam surgindo algumas dúvidas sobre os comportamentos de alguns componentes do sistema
Mapeando problemas
Como parte do nosso DNA de designers, começamos buscando entender o problema antes de começar a pensar em soluções. O primeiro passo foi reunir o time de desenvolvimento para uma conversa (nesse caso, eles eram os nossos usuários), para identificarmos quais eram os problemas (ou dores, como normalmente chamamos) e o que eles sentiram falta durante a transição para a próxima etapa. As dores mais comentadas foram: ausência de cenários extremos (aqueles que aparecem quando a tela está vazia, ou quando tem excesso de conteúdo), previsões e mensagens de erros, a ausência de uma descrição/demonstração mais elaborada de algumas interações e variações de status de componentes.
Depois de descobrirmos quais eram os problemas no fluxo de entrega, fomos atrás de referências e boas práticas, fazendo benchmarking, e investigamos como é o processo em outros ambientes, conversamos com designers que atuam em outras empresas para entendermos melhor como lidam com as mesmas situações.
Assim, descobrimos pontos importantes que na pressa das entregas estavam sendo menosprezados, como o quão fundamental é ter uma boa comunicação entre times, com conversas abertas e frequentes; a importância de manter os arquivos organizados, com nomenclaturas padronizadas e telas ordenadas; e também sobre o desenvolvimento e apresentação de fluxos, para que o time de desenvolvimento possa compreender melhor os caminhos do sistema e complementá-los durante a criação das histórias.
Com isso, finalmente chegamos na etapa de realizar e assim implementar as soluções que ideamos.
Aproximação com o time de desenvolvimento
Primeiro começamos organizando os nossos rituais de entrega. No começo de toda sprint, vamos apresentar tudo o que foi projetado naquele período para todo o time de desenvolvedores, com os seus respectivos objetivos, fluxos, feedbacks e interações. No processo anterior, apresentávamos apenas para dois analistas que ficavam responsáveis por passar tudo para a equipe, organizar as estórias das tarefas e calcular os prazos de entrega. Com a mudança dissipamos falhas de comunicação e aproximamos os times. Também organizamos semanalmente um encontro para que os desenvolvedores possam sanar dúvidas e apontar possíveis obstáculos técnicos, o que ainda permitiu que analisássemos o que estava sendo programado e evitamos correções na entrega para o time de design. Ao final da Sprint, é a vez do time de desenvolvimento apresentar para nós o que foi desenvolvido. Assim, acompanhamos o que já foi implementado e de quebra podemos planejar mais testes com os usuários.
Comunicação melhorada, agora vamos para a documentação. Dentro dos nossos arquivos implementamos algumas ações para facilitar essa transição:
Organização do arquivo e definição de uma nomenclatura padrão
Aqui na Senso, nossa ferramenta queridinha de desenho de interfaces é o Figma. Ele facilita muito o nosso processo de desenho, pois nele podemos criar fluxos, wireframes, protótipos e até elevar o nível das interfaces chegando aos layouts. É através dele que também fazemos a transferência de arquivos para o time de desenvolvimento.
Como todos os passos que desenhamos para os projetos ficam agrupados em um só local, a comunicação é facilitada, mas com tantas pessoas interagindo no mesmo arquivo é muito fácil que ele fique confuso e desconexo. Durante nossa reestruturação do processo de entrega, vimos o valor que tem um arquivo bem organizado e padronizado. Definimos um modelo de nomenclatura para as telas e para os elementos presentes no guia de estilos. Também realocamos as telas em páginas com classificações de acordo com sua função.
Isso ajudou o time de desenvolvimento a se localizar e saber onde encontrar os componentes das interfaces.
Comportamentos do sistema
Como dizia Steve Jobs: “The design is not just what it looks like and feels like. The design is how it works” (em tradução livre: O design não é apenas o que parece e o que se sente. Design é como funciona). Então comunicar bem os comportamentos do sistema, com todas as suas microinterações, feedbacks, casos de uso iniciais, ativos e extremos, é fundamental.
Decidimos, então, acrescentar a cada entrega uma seção de comentários explicativos sobre quais comportamentos são previstos para os elementos que compõem a tela. Comentamos o limite de caracteres permitidos dentro de um espaço de preenchimento, ou quais opções ficam disponíveis no campo de seleção, deixando mais compreensíveis as alternativas que usuário terá para interagir na interface.
Assim os desenvolvedores têm visibilidade da complexidade de cada elemento que compõe a interface que terão que programar, o que melhora projeção do prazo de entrega e evita futuras correções.
Atualização do guia de estilos e melhor visibilidade
Antes de revermos o processo de entregas, o nosso guia de estilos estava estagnado, com os componentes originais que criamos no início do projeto para desenhar as primeiras telas. Ou seja, boa parte dele estava desatualizada.
Depois da nossa iniciativa de alteração do processo de entrega, decidimos reorganizar e atualizar o guia de estilo, com maiores especificações e previsões de comportamentos diversos dos componentes. Assim, o time de desenvolvimento pode ter visibilidade de todos os estados dos elementos das telas. Isso os auxiliou a minimizar erros e estimulou o desenvolvimento modular dos componentes.
Protótipos de alta fidelidade e entregas mais precisas
Já produzíamos protótipos de alta fidelidade antes de revermos o processo de entregas, mas fazíamos somente com as telas que passavam pela etapa de validação com usuários em testes de usabilidade. Percebemos que para melhorar nossas entregas e facilitar a criação dos fluxos e histórias para o time de desenvolvimento, prototipar as próximas telas a serem programadas e suas micro-interações poderia ajudar. Então, tomamos a decisão de fazer isso antes da validação com os usuários. Assim, o time vai ter total visibilidade dos caminhos viáveis pelo sistema e quais interações são possíveis.
Com todos os aprendizados adquiridos, conseguimos concluir que a base de um time promissor, no fim das contas, é a comunicação simples e clara. Ter um canal aberto para trocas de feedbacks e interação para juntos construirmos um produto coeso e que entregue o valor para os usuário. Por enquanto, os feedbacks foram todos positivos, houve melhora na comunicação com os desenvolvedores e as validações da equipe de qualidade também foram beneficiadas.
Entregamos um produto mais aderente ao projetado pelo time de design, que entrega mais valor para o time de negócios e soluciona as dores dos usuários finais.
Demos passos importantes. E, assim como tudo no design, temos a certeza que nada nunca estará verdadeiramente pronto. Pensando nisso, estamos implementando este processo em outros projetos para avaliar os efeitos e evoluí-lo constantemente.
E você, já teve alguma experiência parecida com a nossa? Conta pra gente nos comentários.
*This article is also available in English. Follow this link and check it out. :)
