E quando a empresa não precisa de um designer?

(Mesmo que temporariamente)

Photo by Syed Ali on Unsplash

Prólogo Este texto foi escrito em 2024, mas por diversos motivos não me senti confortável em publicá-lo na época. Foi mais uma forma de processar o que eu estava passando e sentindo. Acontece que com o tempo e conversando com outras pessoas vejo, hoje, que ele pode ser útil para alguém que esteja passando por algo parecido.

Já pensou em estar trabalhando em um lugar onde de repente seu cargo e suas funções não são o que a empresa necessita naquele momento? Pode parecer estranho, mas imagino que em maior ou menor escala muitas pessoas também tenham passado por algo similar: ter de abdicar de suas funções para assumir outras responsabilidades.

Olá, eu sou o Andre Hiro, Product Designer, e durante boa parte da minha jornada fiquei responsável por realizar atividades esperadas de um designer: pesquisar, falar com usuários, entender problemas, desenhar e testar soluções.

Porém, de 2023 para 2024, a empresa em que eu trabalhava passou por um momento de grande reformulação, que exigiu muitas mudanças de escopo, prioridades e comportamento de toda a equipe.

Motivos da reformulação

Necessidade de melhorias na gestão de códigos, processos e tecnologias

Chegou um momento em que era necessário realizar reestruturações e reescrita de muitas partes do código por diversos motivos: atualização de tecnologias, correções de bugs e necessidade de mais desempenho da aplicação. Itens estes que estavam se tornando gargalos sérios que impediam o produto de avançar com inovações.

Outro ponto foi aplicar melhorias em relação ao fluxo de trabalho com melhores práticas de gerenciamento de branches, PRs e testes com o objetivo de aumentar a qualidade do código.

Faltavam documentações técnicas sobre diversos pontos do sistema

Até então, os desenvolvedores não tinham certeza de onde, como e quais as consequências de alterar determinadas coisas no código. Além de faltarem documentações sobre várias regras de negócio, o que dificultava a criação de testes assertivos.

E quais foram as mudanças?

• Melhora da gestão de código: Fluxos bem definidos de passagem de cards para aprovação de PRs, testes e deploy;
• Criação de uma documentação global de todas as regras de negócio dentro do sistema e levantamento de pontos de melhoria;
• Aumento da cobertura de testes automatizados e melhoria dos padrões de testes em QA, com melhor definição dos critérios de aceite e documentação dos resultados;
• Mudança no modelo de gestão das tarefas de desenvolvimento.

Mas cadê o design nestas mudanças?

Percebe que não apareceu nenhum ponto de mudança voltado a processos ditos de design? Não é que não fossem necessárias melhorias, mas não era um ponto crítico. Naquele momento meu escopo dentro da equipe começava a mudar.

Bora documentar

Num primeiro momento, fiquei encarregado de documentar no Notion todas as regras de negócio e funcionalidades do produto com seus diferentes parâmetros, objetivos, ações e resultados esperados no uso.

Também foram relacionados arquivos do Figma, boards no Miro, linhas de código mais relevantes, cards do Jira, casos de testes, indicações de bugs e melhorias, fazendo com que esta documentação se tornasse um hub de tudo relacionado a cada função do sistema.

Para poder documentar, foi necessário testar todas as funções, das mais básicas até as mais complexas e pouco usadas. Isto também permitiu recolher insights de melhorias e ajustes, além de documentar locais com mau funcionamento no sistema. Estes ajustes e correções foram documentados em uma tabela específica e cada item foi linkado com a documentação da função. Desta página de ajustes é que surgiram muitos itens que não estavam ainda mapeados no backlog.

Mudança de gestão de desenvolvimento

A troca de gestão foi uma decisão tomada pela empresa no início daquele semestre para se adequar às novas prioridades, e enquanto a empresa buscava por uma nova pessoa para a função, assumi temporariamente algumas das demandas de Produto como PM/PO, sendo auxiliado pela PM de outro produto e pelo CTO.

O primeiro passo foi despriorizar tudo o que era tarefa de novas funções e melhorias no sistema e focar nos itens de correção de bugs e melhorias de performance, seguido de entender e documentar com mais detalhes cada problema já conhecido, através de muitos testes, e trazer os novos itens de correção que não estavam mapeados. Ah, e o backlog de design e pesquisas foi congelado.

Na hora de passar para os Devs, priorização ia de acordo com:

• Criticidade da funcionalidade: o quanto a função em questão estava afetando o uso dos clientes, qual a porcentagem de clientes que a usam e com qual frequência.
• Validação técnica: da complexidade e do tempo de resolução esperados para cada item.
• Correlação de erros: O quanto uma correção dependia de outras e quantas estavam mais isoladas.

Durante 5 meses estive à frente das tarefas de gerenciamento de backlog, detalhamento das tarefas e priorização, passando o bastão para a nova Product Manager em dezembro. Durante o período tivemos a entrega de cerca de 40 itens de melhorias e correções de bugs.

Aproximando das áreas de Suporte e Sucesso do Cliente

Foi necessário também aumentar minha interação com estas duas áreas por alguns motivos:

• Era necessário comunicar sobre as correções para os clientes, desde o que foi corrigido até o que estava na sequência da fila com mais clareza.
• Coletar melhor as evidências de problemas relatados pelos clientes.
• Conseguir acompanhar com mais assertividade o resultado das correções e da percepção dos clientes.

Como designer, eu já interagia com estas equipes para entender pontos de melhoria e coletar feedbacks de clientes, mas agora eu estava mais dentro do dia a dia deles, inclusive conseguindo entender quais eram os gaps de comunicação entre as nossas áreas. Isto depois seria refinado com a chegada da nova gestão de Produto que, a partir da constatação destes gaps, melhorou processos de comunicação, documentação de chamados de suporte e recolhimento de feedbacks.

Testar, testar e testar

Para reforçar a qualidade dos testes de QA, passei a realizar também testes junto dos desenvolvedores de todas as funções que iriam ser lançadas (e sim, não tínhamos uma pessoa QA dedicada, até então eram os próprios desenvolvedores que realizavam os testes), bem como a ajudar nas investigações de bugs ainda pendentes.

O primeiro passo foi listar todos os testes base para as funcionalidades. Então, ao mesmo tempo que fazia a documentação, fui estruturando uma lista de testes com os critérios de aceite, casos de uso e relação da função testada com outros pontos do sistema. Assim, criamos uma base para smoke tests e check-list dos testes automatizados.

Outro grande aprendizado que tive foi aprimorar meu conhecimento sobre código em geral. Não aprendi a codar, mas consegui melhorar meus diagnósticos a partir das análises das chamadas e payloads enquanto realizava ações no sistema, além de aprender a usar ferramentas como o New Relic e Crashlitcs para monitoramento. Então conseguia informar qual chamada não estava funcionando como esperado e quais as respostas acusadas. Isto foi essencial no entendimento de diversos bugs.

Também percebi que para ser um bom testador é preciso um pouco de criatividade. Como eu ia saber que poderia quebrar o sistema se clicasse 23 vezes no botão, estando abaixo do trópico de Capricórnio, enquanto tomo um coado, ouvindo Cidade Negra com um fone de ouvido em que o lado direito não funciona mais? E sim, se fosse um café expresso, nada quebrava.

E como estamos?

No momento em que escrevo este texto, em julho de 2024, o foco ainda está na reestruturação/reescrita do código, correções e melhorias. A percepção em relação ao produto melhorou muito, constatada através de feedbacks internos e de clientes.

Algumas novas funcionalidades foram inseridas neste meio tempo, e tivemos pouco ou quase nenhum problema depois do lançamento, muito por conta da implementação dos testes automatizados, da melhor documentação sobre as regras de negócio e da qualidade dos testes em QA. Isto é um indício de que, com os novos processos adotados, quando voltarmos a implementar inovações no produto, elas serão entregas de qualidade a longo prazo.

Mas o que tudo isto tem a ver com ser designer?

No final, todo este processo me ajudou a evoluir em alguns aspectos que estão relacionados ao meu trabalho de design de um jeito ou de outro:

• Conhecimento muito mais profundo sobre o produto. Isto me trouxe muito mais segurança em propor mudanças, pois temos uma clareza maior sobre os outros lugares que determinada mudança vai afetar, diminuindo o risco de funcionalidades deixadas com pendências. Quem nunca adicionou um campo novo de informação e esqueceu que deveria referenciá-lo na subpágina da página escondida e tinha um cliente que ia usar o campo exatamente lá?
• Fazer tantas documentações me fez perceber muitas melhorias que posso levar para as documentações de design, além de aprendizados para aprimorar os handoffs para os desenvolvedores, tais como: indicar diferentes tipos de validações e retornos do sistema e traduzir isto para a interface, deixar regras de negócio documentadas e onde se aplicam dentro dos fluxos, relacionar as regras entre si, entre outros. Tive feedbacks positivos sobre a melhora da qualidade dos meus handoffs depois deste processo todo.
• A comunicação aprimorada com meus pares de Desenvolvimento, Produto e Suporte. Não só entender de jargões técnicos específicos, mas também entender que muita coisa do design está alinhada às tomadas de decisão destas áreas também.

Não ter muitas atividades relacionadas ao design, e por tanto tempo, dá sim um enorme sentimento de estagnação e frustração, mas em outras valências tive boas evoluções. Foi um teste de resiliência, flexibilidade e adaptação, qualidades importantes para qualquer profissional em muitas situações, pois nunca sabemos o que o mercado pode exigir em um momento de crise ou oportunidade.

Me sinto bem em ter conseguido desempenhar funções fora do meu escopo de designer com feedbacks muito positivos por parte das lideranças. Sei que não tive a mesma pressão por resultados que pessoas especialistas nestas áreas teriam (e seria estranho se eu tivesse), mas acabei conseguindo elevar o nível da qualidade de testes, documentações e outros processos. No final, constatar que as melhorias continuam sendo aplicadas na equipe é algo de que se orgulhar.

Mas claro, tudo é uma questão de entender o momento da empresa, do mercado e do seu momento como profissional. Em empresas menores, é mais provável entrar em um movimento destes de fazer outras funções do que em empresas maiores com equipes mais estruturadas. Fazendo sentido e não sendo algo que te tire do caminho que queira trilhar como profissional, é um aprendizado válido; senão, é refletir se uma mudança destas faz sentido e por quanto tempo é válida e sustentável.

Agora, o quanto fez sentido e se foi sustentável para mim, posso contar em outro momento.