A relevância do QA de Design em produtos digitais
Um tempo atrás, fiquei imaginando como seria se não existisse um padrão de qualidade para as coisas feitas em grande escala. Por exemplo: a fabricação de um mesmo modelo de carro. Já pensou se cada carro em sua linha de montagem saísse da fábrica com um volante diferente? Ou então, um pneu maior que o outro?
Essa ideia se aplica perfeitamente quando falamos de um produto digital. Um usuário jamais conseguiria navegar em uma aplicação totalmente inconsistente, com padrões de navegação e visuais diferentes. É por isso, que nós designers lutamos tanto por esse “padrão de qualidade” na entrega de um projeto.
“Não se trata apenas em entregar algo “bonitinho”, mas sim, em entregar algo que gere valor”.
Quando falo em "Design QA" não estou me referindo a um time de DesignOps ou então um Design System, Design Quality Assurance é uma etapa mais a frente, é realmente aquilo que será produzido e que o usuário verá no final das contas; todos os cenários possíveis, fluxos, padrões visuais e tudo que gera experiência ao usuário.
Mas então, por que as pessoas não utilizam o “Design QA” nos processos de design? Embora seja "meio" difícil de entender o motivo, listei aqui alguns dos principais deles:
- As empresas e times não enxergam o impacto que isso gera nos negócios;
- Velocidade e foco para entrega da Sprint;
- Falta de comunicação entre equipes;
- Velocidade versus qualidade.
Tá, mas e ai? Como fazer uma entrega consistente?
“Quality, is job one.” Henry Ford.
Esteja um passo a frente da produção.
Trabalhei em projetos que as Sprints eram divididas em duas etapas, a primeira etapa era em dual-track entre designers e devs, então tudo que descobríamos e desenhávamos era feito nessa primeira Sprint.
A segunda Sprint consistia na implementação de tudo aquilo que foi feito na primeira fase e é ai que mora o perigo. “Quando realmente o produto ia pra produção é que o Design QA entrava em cena para validação e de certa forma, as coisas andavam bem”. Conseguíamos ter entregas mais consistentes, a grosso modo ficaria assim:
Task > Discover > Prototype > Design > Development > QA Design > Test > Done.
Em termos de design, basicamente colocávamos mais um fluxo de validação após o desenvolvimento. Além de termos uma entrega consistente, tínhamos também uma evolução como equipe.
Trabalhe com desenvolvedores na etapa de design.
Sim, converse muito com seus devs. E não estou falando só pra você revisar o código com a UI. Eles e elas são pessoas muito legais e, quando designers e devs trabalham juntos, as coisas ficam muito mais fáceis. Aqui temos os dois lados da moeda, se por um lado o designer consegue deixar as coisas mais fáceis pro usuário, o desenvolvedor, com seu lado técnico, consegue dar o caminho das pedras para a experiência.
Diferentes pontos de vista podem resultar em grandes insights e até mesmo em ótimos feedbacks. Por isso, discuta os requisitos básicos e as limitações para codificar algo, veja se aquilo que está pensando realmente é apropriado para aquele projeto. Quando colaboramos juntos nos métodos de design, pode ter certeza, a experiência do produto final será muito mais agradável.
Por fim, crie empatia com o resto da equipe.
Embora trabalhar com os desenvolvedores seja algo primordial, não podemos descartar que Stakeholders, POs, SMs e PMs também fazem parte deste processo. Faça as coisas com calma, estude bastante antes de executar alguma tarefa, tenha argumentos para validar idéias com seu time e os stakeholders. Tudo isso é essencial para que o produto tome uma forma consistente.
Espero ter passado a mensagem.
See ya.
