Entrevista — 11
“Não precisa codificar, mas tem que entender” — Rayana Verissimo
Mesclando design e programação, a pernambucana que atua na GitLab nos contou sobre os processos de trabalho e as diferenças culturais entre o Brasil e a Holanda, onde vive atualmente
Unir o conhecimento em programação à área de design é o que motivou, desde o início, a trajetória profissional de Rayana Verissimo. Entender como as coisas funcionam sem deixar a parte criativa de lado foi um desejo que tem rendido bons frutos, dentro e fora do Brasil.
Formada em Design pelo Instituto Federal de Pernambuco (IFPE), Rayana conseguiu unir o gosto e a facilidade para programar ao conhecimento sobre design adquirido ao longo do curso para transitar, com fluidez, entre as duas áreas. Nessa versatilidade entre dois mundos que parecem opostos, ela encontrou um caminho para se destacar enquanto profissional.
Rayana começou a carreira em agências digitais do Recife e passou pelo Centro de Estudos e Sistemas Avançados do Recife (Cesar) antes de levar o sotaque pernambucano para fora do país. Na Holanda, o primeiro trabalho foi em uma fintech e, desde 2018, Rayana atua na GitLab, empresa Open Source e 100% remota.
Apesar dos desafios sociais, o campo profissional parece ter o espaço que Rayana precisava para se sentir à vontade, colocando em prática as habilidades do design e do desenvolvimento, com a chance de aprender ainda mais sobre essas duas áreas ao ocupar os cargos de Staff Product Designer e de Acting Product Design Manager na Gitlab.
- Como é o trabalho em uma empresa Open Source? O que muda em relação aos métodos?
"Acho que, por ser Open Source, isso forçou a gente a se organizar ao redor da colaboração e comunicação. Eu, como designer de produto, tenho acesso a tudo. Não existe a barreira física, de ter uma sala de reunião, onde eu não possa ver o que está acontecendo, nem existe uma barreira entre eu e os usuários."
"A comunidade é aberta, tenho acesso às pessoas que usam a GitLab, posso entender os pain points delas. Posso ter acesso ao insight desse tipo de usuário."
"Não existe barreira entre um product designer e um engineer manager. Você trabalha muito em conjunto, tem acesso à informação, vê as tasks das pessoas, revisa o código."
- Como foi a adaptação no exterior?
"Eu senti muita diferença na questão cultural. A gente tem aquela questão de passar oito horas no escritório com a galera, de ser amigão de quem você trabalha, e aqui achei mais separado. E às cinco da tarde, é incrível: cada um vai para a sua casa. Eu senti uma separação entre a vida pessoal e a vida profissional e acho que no Brasil, é meio emaranhado."
- Como são os processos de trabalho?
"Tem uma série de rituais assíncronos, que não são com todo mundo trabalhando na mesma área, e outros síncronos. O UX showcase é uma das formas pra gente mostrar o que está rolando em diversas áreas do departamento de UX, mostrar resultados de pesquisa ou features que a gente vai construir, ou coisas que a gente descobriu no último mês. Cada designer vem com 15 minutos, faz uma apresentação ou chega para dar um insight no que está rolando e criar oportunidades de colaboração."
"A gente tem o pair designers, em que você se junta com um outro design de um time lá do outro lado, e aí você é um buddy, marca ligações uma vez por semana para fazer design critique, ou para falar sobre processos, melhorias no seu time, challenges que você tem ligados ao trabalho. A gente usa como métodos os scorecards, em cima dos jobs to be done, pra conseguir validar a maturidade do produto."
"É um processo feito junto com os product managers, seguindo os frameworks. Tem uma página inteira no handbook falando sobre heurística, todos os processos, e technical writers. A maioria das coisas são assíncronas."
- Como é feita a parte de research dentro da empresa?
"A gente chega nas pessoas através de conversas para entender os pain points desse consumidor, o framework deles, entender onde que a empresa dele está indo e como aquele nicho se encaixa no roadmap da gente. O pessoal de UX Research tem um número de frameworks, jobs to be done, tem UX showcase, tem scorecards, além das coisas normais de usabilidade, de teste de usuário, eles entram em contato direto com os consumidores e é muito fácil."
"Eu fico muito impressionada, porque não tenho dificuldade de pensar como vou conversar com um cliente ou uma pessoa da comunidade, porque eles vêm até a gente, é incrível. Eu sou bem mimada nessa questão."
"A gente tem um portal chamado GitLab First Look, onde você se inscreve e diz “sou um DevOps engineer”, faço tal coisa e nosso time de pesquisa filtra e tenta entender se essa pessoa se encaixa nas nossas iniciativas. Nunca tive problema achando gente com opinião para dar."
- Por ter essa visão de colaboração, os times também têm vez dentro desse processo de pesquisa?
"A solution validation vai rolar com consumidores externos e com consumidores internos. A gente não pode pensar em não influenciar muito o roadmap porque a gente sabe demais do produto e ignorar o conhecimento técnico dos nossos desenvolvedores. Não rola isso."
"Tem uma gama de frameworks que a gente usa no time de design pra que, quando a gente valide nossas propostas, tem que ter uma baseline. Além das personas, do número de usuários, quais são os cenários que a gente tá testando, qual a maturidade dessa feature hoje e daqui a três meses, quando a gente for revalidar de novo, com personas internas ou externa."
"Meus desenvolvedores têm o direito de influenciar porque eles usam a nossa aplicação no dia a dia, eles têm que ser ouvidos tanto quanto as pessoas que estão pagando pra usar produto. Mas a gente entra já para tirar aquela dúvida: “será que as propostas estão sendo influenciadas apenas pela questão técnica?”
"Por isso que o design de produto, nesse momento, não é apenas criar o visual, mas conversar com o mercado, com os usuários e adicionar o input dos nossos desenvolvedores nas propostas. Isso é bem diferente de outras empresas em que eu trabalhei."
- Como são os entregáveis?
"Se eu estiver trabalhando numa task em que eu tenha que entregar uma interface de uma feature x, o entregável vai ser um issue, que é a task em si, a descrição do que a gente vai construir, a interface, se você for mudar ou não."
"Tem muita feature que eu trabalho que eu só escrevo o que vai rolar, porque acontece tudo no back end. A gente está falando de integração com API. Eu tenho que dizer “quando puxar tal coisa da API, vai ser no formato dia/mês/ano/hora”. E aí, no próximo release, vou trabalhar na UI e vou mostrar a data formatada do mesmo jeito que eu disse que ia acontecer no backend."
"Tem os designers que são muito mais focados no visual, que entregam em Figma, e aí tem os fluxos, o trabalho com UI mais granular. No meu caso, estou muito perto do backend. Pra mim, o entregável é uma user story. É dizer qual componente do Design System que a gente vai usar em tal interface, porque ela já está construída. Só preciso dizer o que se encaixa naquele âmbito. Mas isso não quer dizer que não existem entregáveis visuais, isso rola muito, ainda."
- Quais são os desafios que existem no trabalho e na comunidade?
"Acho que um dos desafios contínuos que vejo muito rolando na comunidade de Design é a adoção, e também o Design System não só como entregável de design visual. Acho que um dos challenges maiores é que como os designers não têm a capacidade técnica pra implementar certos aspectos do Design System, rola muito essa dependência do desenvolvedor, tende a priorizar as features dos componentes."
"Acho que se a gente tivesse mais designers empoderados que conseguissem se desenrolar e construir as interfaces gráficas, a gente poderia ter uma conversa mais conjunta entre design e desenvolvimento em relação ao Design System."
- Isso é desenvolvido na GitLab? Como?
"A gente tem um time dedicado a isso, o Foundations. Tem uma líder de design, um ou dois front-ends, um design visual e um design de produto. Eles são meio que gatekeepers, estão ali pra ajudar a gente a construir standards, validar acessibilidade, validar cores."
"Mas os designers de produto de cada time têm o ownership do Design System. Então se eu estou construindo um protótipo, estou usando uma parte do Design System, que é a library do Figma. Se eu estou escrevendo um critério de aceitação no meu issue, eu tô usando uma guideline de documentação do Design System. E os engenheiros estão usado a UI, a parte codificável."
"Pra chegar nesse nível de maturidade, tem que ter um investimento da organização em design muito grande, porque é um compromisso. Não é dar oportunidade, mas entender que não é apenas fazer deliver de software que importa. O que importa são standards, a usabilidade e a reusabilidade do produto. É bem desafiante entrar em uma empresa que não tem essa maturidade, ainda."
Referências
—
—
