Design-QA: Ponto de contato necessário entre UX e Desenvolvimento

Uma proposta para melhorar o fluxo de trabalho entre designers, desenvolvedores e QAs.

Construir um produto digital, seja qual for o enquadramento, contexto ou necessidade, não é uma tarefa fácil. Desde o início, entender a visão que o product owner ou gerente de produto deseja realizar e identificar as correlações com as necessidades dos públicos pode ser uma tarefa extremamente complexa. Se acrescentarmos a isso a necessidade de definir a estrutura tecnológica mais adequada para garantir o desempenho ideal, o desafio se multiplica. Portanto, cabe a nós, designers e desenvolvedores, encontrar um processo flexível e rigoroso (por mais contraditório que pareça) de forma a garantir que o que foi projetado seja executado durante o desenvolvimento com o mais alto nível de fidelidade e precisão possível, mantendo e explorando ao máximo os insights e benefícios para os usuários. Nosso trabalho é exatamente esse, encontrar o ponto exato para que a tecnologia atenda a necessidade do usuário da melhor forma possível.

Para isso, surge um conceito-chave que nos acompanha em cada trabalho, e é o QA, ou Quality Assurance, um papel central que se encarrega de garantir o correto desempenho do que foi desenvolvido.

UX Dívida, um problema nas sombras

Entre as muitas virtudes do design e desenvolvimento através da implementação de metodologias ágeis, destaca-se a priorização e rapidez no lançamento de novos produtos ao mercado através do adiamento de recursos ou funcionalidades que, embora benéficas para o produto, acabam sendo um bom -to-have que não limita nem reduz a possibilidade de sucesso, o que significa um investimento que nos faz perder um tempo valioso. Em teoria, lindo. Na verdade, complexo. Quem define o que é bom ter e como? Não faltam teorias sobre isso, o problema aparece quando, na pressa de entrar em produção, são adiadas inconsistências entre o que é desenvolvido e o que é projetado, o que em alguns casos pode afetar a valiosa primeira impressão do usuário. É aí que surge a terrível UX Debt, que basicamente implica que os custos relacionados à entrada no mercado com uma versão incompleta do lado da experiência do usuário implicam em uma longa ida e volta para resolvê-la com custos mais altos do que o esperado. foram priorizados e resolvidos em primeira instância.

Por que isso está acontecendo? Por muitas razões, incluindo ignorar o teste do usuário, estilos de marca ausentes e diretrizes estéticas, desalinhamento com as metas de negócios e teste de controle de qualidade insuficiente.

QA vs. QC. Onde entramos?

Antes que o pessoal do controle de qualidade nos mate, não se preocupe, não estamos fazendo uma leitura superficial. Entendemos a diferença entre QA e QC, e como é importante, por um lado, definir as técnicas e atividades necessárias para atender aos padrões de qualidade e, por outro, a implementação de atividades sistemáticas que serão implementadas para garantir a qualidade. (ISO 9000. Reduzir UX Dívida precisa das duas frentes. QA e QC, processo e produto, proatividade e reatividade, prevenção e identificação. O problema é que, muitas vezes, essa sistematização de processos e implementações não contempla a consideração de acessibilidade, usabilidade, funcionalidade e desempenho.

Agora, quem deve cuidar para que o que é desenvolvido coincida com o que é projetado? Quem deve garantir o cumprimento de todos os detalhes visuais e interativos alinhados tanto com as necessidades estratégicas do negócio/produto quanto com a visão do designer? Existe uma função de Design QA?

Controle de qualidade do projeto. fluxo de trabalho tradicional

Na minha experiência trabalhando com diferentes clientes e projetos, encontrei uma infinidade de maneiras de implementar um processo de verificação de conformidade estética do que foi desenvolvido.
Tanto ao nível da ferramenta de comunicação como da metodologia de integração, a única coisa que tem caracterizado todas as situações é a falta de concordância ou coerência transversal. Por exemplo, podemos listar os seguintes exemplos:

• Designer de produto ou UX/UI com papel de QA. O designer trabalha em conjunto com a equipe de desenvolvimento para levantar os aspectos em que o produto desenvolvido não tem consistência com o que foi projetado. Esse retorno é feito depois de totalmente desenvolvido, não se envolvendo em sprints ou processos de desenvolvimento. A documentação geralmente é informal e adiciona mais uma tarefa à UX/UI.

. Designer de produto ou UX/UI fornece critérios para QA. Há exemplos em que o designer, ao entregar o que vai ser desenvolvido, estabelece critérios pelos quais a QA se rege ao avaliar o que foi implementado pelo desenvolvimento. Nesse tipo de projeto, o designer não é quem devolve as coisas para serem melhoradas, mas educa o QA sobre os pontos essenciais que devem constar no que é avaliado. Essa orientação pode ser informal, mas nos casos que vimos em nossos projetos foi na plataforma de bilhética que é usada para lidar com as tarefas.

Por que é que? Por que uma tarefa que todos concordamos que deveria ser fundamental no processo de trabalho não é formalizada? As razões podem ser várias, desde a falta de especificações claras e detalhadas sobre como o design deve ser implementado (uma transferência “in extremis”), falta de rigor no processo de QA implementado a nível visual, falta de envolvimento da equipa de design na verificação de qualidade, e muito mais, mas em suma, pode-se pensar que os pontos de contato entre perfis e diferentes especialidades são sempre conflitantes. Afinal, ninguém gosta de dizer quem deve fazer o quê e quem não deve.

Mas esse não deve ser necessariamente o objetivo. O objetivo é criar um processo colaborativo que permita manter os melhores interesses do negócio e complementar o trabalho de desenvolvimento. Estamos aqui para isso.

Então… precisamos de “um” Design QA?
Na minha opinião, não precisamos da função de uma pessoa que seja Design QA, porque essa função já existe. É o controle de qualidade. Contemplamos e almejamos um controle de design colaborativo e iterativo como parte do processo de controle de qualidade. Nosso trabalho como designers, neste caso, é complementar o seu trabalho e promovê-lo. Sistematizá-lo e padronizá-lo para que seja replicável em diferentes contextos e garanta uma boa conexão entre os atores. E se isso acontecer no início de um projeto e com uma boa comunicação sobre as tarefas e processos a seguir no seu desenvolvimento, na minha opinião será muito melhor.
Colocar um papel específico dentro da equipe de design para executar ações de QA levaria à sobreposição de tarefas, além de tirar o foco do designer de outras tarefas onde seu valor agregado é maior. Os designers precisam estar mais envolvidos no processo de desenvolvimento, com um processo claro e padronizado.

Mostre seu apoio

• Siga-me no Medium para mais artigos sobre Design Centrado no Usuário / Tecnologia / Marketing / Transformação Digital / Fintech / e “outras ervas” Em inglês, espanhol e português. Eu também gosto de música, fotografia, jiu-jitsu brasileiro, capoeira e filmes, então espere encontrar artigos interligados sobre esses tópicos. 😉
• Siga-me no Behance para poder avaliar e ver meu trabalho 🎨
• Siga-me no LinkedIn para mais dicas de música 🎷🎸
• E se quiser conversar sobre mais coisas, este é o link da minha ADPlist 💻