Organizando seus entregáveis de UX para focar no que realmente importa: resolver a dor dos usuários
Já parou pra pensar como o time de Design pode ajudar o time de Engenharia a alcançar esse objetivo?
Hoje se fala muito sobre times ágeis em empresas de tecnologia. Existem vários processos e ferramentas que nos ajudam nessa missão tanto na parte de design quanto na parte de engenharia durante o desenvolvimento.
O fato é que processos e ferramentas são essenciais, mas não garantem que a entrega final e o que vai pra mão do usuário é realmente aquilo que foi projetado visualmente ou na parte de experiência.
Se identificou? Mas por que isso acontece? Afinal, utilizamos o Figma para desenhar e compartilhamos tudo no Zeplin com o time de engenharia. Está tudo ali.
Como em design sempre partimos de um problema para começar o processo de descoberta, vamos começar falando dos problemas que enfrentávamos. Mas antes de seguir, é importante que você saiba que isso era uma dor pontual nossa e a ideia desse artigo é ajudar os times de design e engenharia que também passam por isso contanto como resolvemos esse problema.
Como você organiza seus entregáveis de UX?
Para entrarmos no problema é importante entender o cenário. O que é o produto, quem é o time, como trabalhamos e que ferramentas utilizamos.
O Produto: estamos falando de um produto mobile que na realidade é uma plataforma com alguns serviços acoplados nela.
Time: o time desse produto é formado por P.M., engenheiros e designers. Porém, por ser uma plataforma, temos iniciativas tanto do nosso time quanto de P.Os de outros times de produto que também criam coisas dentro da plataforma.
Ferramentas: o time de design usa o Miro, Figma e Zeplin desde o começo do discovery até os entregáveis finais no delivery para engenharia.
Entregáveis: apesar do time de produto e os designers trabalharem com suas ferramentas, o que realmente o time de engenharia acessava como entregáveis era o Zeplin — que, vamos combinar, é uma mão na roda — porém, como eu comentei antes, não resolvia todos os nossos problemas.
Como na Acesso Digital temos alguns produtos, a organização no Zeplin era feita da seguinte forma: cada produto no Zeplin é um projeto e os serviços ou funcionalidades são separados por sessões dentro dos projetos.
Tenha empatia pelos usuários, que nesse caso, é o seu próprio time
Agora que já fizemos uma imersão no cenário atual, vamos ao que fazemos de melhor que é partir para a descoberta dos problemas.
Fizemos um levantamento de todas as personas envolvidas no processo de desenvolvimento do produto e fomos conversar com elas para entender como trabalhavam, quais eram suas necessidades e maiores dores, que foram:
✏️ Designers
Como eu citei antes, nós designers, tínhamos a dor latente de não ter o controle do que estava subindo em produção. Em teoria, tudo o que desenhávamos no Figma, validávamos com o usuário e subíamos no Zeplin era para ir para produção, não? Bom, sim. Mas tudo o que? Na nossa cabeça estava muito claro, mas precisávamos entender como os engenheiros pensavam.
🔧 Engenheiros
Quando procuramos os engenheiros entendemos que na realidade a maior dor deles é que o projeto do Zeplin é muito extenso e com muitas telas. Vários ajustes e especificações passavam despercebidos ou os designers faziam alterações que impactavam todo o componente já desenhado e especificado para o nosso Design System e os engenheiros não faziam ideia de em qual momento fazer esses ajustes nos componentes. E aí existia um problema muito grande.
Lembra que disse que somos um time ágil? Assim como em muitos times de produto trabalhamos como uma esteira. Os engenheiros colaboram no definition dos designers e os designers também colaboram após o delivery para engenharia, porém nessa "passagem de bastão" percebemos que existia um gap de comunicação, porque nem sempre temos tempo de explicar o que queríamos que fosse desenvolvido, então os engenheiros interpretavam o que precisava ser feito com base nas telas que subiam no Zeplin.
📑 P.Os
Conversando com os P.Os, percebemos que eles também tinham uma dor que nem sabíamos que existia. Como o produto é uma plataforma e cada P.O é responsável por seus serviços, era difícil deles perceberem e entenderem o que realmente importava no projeto do Zeplin: as iniciativas por quais eles eram responsáveis e que eles demandavam para o produto e precisavam acompanhar.
Coloque o seus usuários no centro do problema e resolva com eles
Levando todas essas dores em consideração, fomos para a solução de forma que resolvêssemos os problemas de todas essas personas e juntos construíssemos algo que ao mesmo tempo mantivesse a agilidade do time.
Com o discovery feito, ficou claro que os maiores problemas estavam na organização e na documentação dos entregáveis. Então partimos para os seguintes objetivos:
Eu, como designer, quero que a solução desenhada seja desenvolvida exatamente como no projeto porque qualquer alteração pode afetar a experiência do usuário.
Eu, como engenheiro, preciso que o time de design e produto especifiquem exatamente o que precisa ser feito e quando para o resultado do desenvolvimento reflita exatamente o que a iniciativa exige.
Eu, como P.O do serviço X, preciso acompanhar a solução e os entregáveis de design com base na iniciativa criada para resolver o problema Y.
Para chegarmos na solução fizemos muito benchmarking, algumas ideações e, colocando tudo em uma matriz do que funcionária para o time com pessoas de skills diferentes, chegamos em uma solução ideal para todos e o mais legal: chegamos nela juntos.
A solução
Falando na solução, é necessário abrir um parênteses aqui e citar que ao mesmo tempo que estávamos trabalhando nessa iniciativa, o time de produto como um todo estava reformulando o processo de documentação e decidimos levar todos os entregáveis para a mesma ferramenta.
Escolha uma ferramenta que te dê flexibilidade na organização
A ferramenta escolhida foi o Notion. Primeiro que só ela poderia nos dar a flexibilidade de montar do nosso jeito tudo o que precisávamos documentar de forma fácil, onde um time de engenheiros, designers e P.Os pudessem consultar o que precisassem sem parar alguém do time para perguntar algo.
Documente de forma simples
Sabemos que a quantidade de documentação gerada pelo time do produto e principalmente pelo time de design é gigantesca. Estamos falando de iniciativas de produto que possuem: histórias de usuários, métricas, pesquisa com os usuários, fluxos, wireframes, interfaces, resultados de testes realizados, enfim… é bastante coisa. Portanto a organização desses documentos precisa ser simples e de fácil acesso.
Versione seus entregáveis por iniciativa
Lembra que comentei que os entregáveis finais para engenharia ficavam todos no Zeplin em um mesmo projeto (produto), dividido por sessões e que os P.Os dos serviços também sofriam com essa organização? Então, resolvemos os problemas de todas as personas envolvidas versionando as telas por iniciativa.
Os engenheiros e P.Os, trabalham por iniciativa. Versionando os principais entragáveis de UX também por iniciativa, faz com que tanto os engenheiros quanto os P.Os, tenham um recorte do que realmente é importante e conseguem focar seus esforços em acompanhar e desenvolver o que é necessário naquele momento.
Além disso, essa organização nos ajudou na tarefa de componentização. É comum que durante novas iniciativas de produto sejam desenhados novos componentes para alimentar nosso Design System. O Zeplin tem uma função de organização de componentes e ele nos ajuda a organizar e especificar esses novos componentes que, após desenvolvidos pelo time de engenharia, vão para o Zeroheight, que é a ferramenta que hospeda nosso Design System.
Especifique o que você quer que seja feito
Versionar os entregáveis de UX por iniciativa faz com o que todo o time foque no que realmente importa. Mas lembre-se de que é muito importante que você especifique detalhes da experiência que não podem ser traduzidos apenas em telas ou apontar alguma melhoria feita em um componente existente.
É comum alterarmos alguns componentes criados anteriormente com base em novos testes de usabilidade que fazemos com nossos usuários e aproveitamos a nossa organização por iniciativa para deixarmos claro para o time de engenharia o que queremos que seja alterado ou feito em um ou mais componentes, assim resolvemos o problema do "quando" atualizar componentes novos que o time de engenharia levantou.
Especificar dentro de uma iniciativa o que queremos que seja melhorado nos dá liberdade de ir evoluindo aos poucos coisas já desenvolvidas sem atolar o time de engenharia pedindo para que eles toda hora fiquem mexendo no legado. Dessa forma, conseguimos trabalhar em novas iniciativas e ao mesmo tempo ir fazendo ajustes e isso permite que o produto seja melhorado continuamente e não só o time de engenharia, mas todos do time acabam tendo muita clareza dessas melhorias e quando elas devem ser feitas.
Teste sua solução
Como eu disse no começo do artigo, essa foi uma solução dada para resolver um problema pontual que tínhamos, mas é muito importante deixarmos claro que não acertamos de primeira.
Antes dessa solução começar a rodar, testamos outra ferramenta para fazer essa organização e percebemos que não iria funcionar. Além disso o modelo como nos organizávamos tinha ficado bem complexo no primeiro momento e percebemos que isso poderia nos prejudicar ao invés de ajudar. Portanto, testar a solução é tão importante quanto chegar nela. Lembra do "Se é para errar, erre rápido"? É exatamente isso. Fizemos um teste envolvendo os times e já logo percebemos que não ia dar certo, até que chegamos nessa solução apresentada que é a ideal para todas as personas.
Aprenda e continue evoluindo
Você deve estar pensando: "Poxa, legal. Todos os problemas foram resolvidos". Bem, sim e não. Por hora os problemas realmente foram resolvidos, mas ainda estamos testando essa solução e qualquer momento pode ser que entrem mais personas no processo, ou que seja necessário acrescentar mais ferramentas, ou até mesmo podemos perceber que ainda tem algo que precisa ser ajustado.
Lembre-se: testar sua solução antes de implementá-la não significa que você não terá que ajustar nada após o lançamento com uma nova descoberta. Mas como você é designer, ou alguém que trabalha com produto você já deve saber isso né? 😁
E na sua empresa como é?
Se você passa pelo mesmo problema na sua empresa ou por algum problema parecido, espero que esse artigo tenha ajudado.
Independente disso, como é na sua empresa? Como vocês organizam seus entregáveis de UX para que todos tenham acesso a eles e isso dê agilidade e assertividade para o seu time no dia a dia?
Deixe um comentário nos contando. Afinal, não existe certo nem errado e sim o modelo que melhor se aplica a nós.
E falando em nós, quer trabalhar dessa forma organizada, tendo o controle dos seus entregáveis e junto do time de engenharia, fazer melhorias constantes nas quais você acredita para o produto? Estamos com vagas. 🚀
—
Renato Kassabian é UX Lead na Acesso Digital.
