UX/UI Design na Prática — Interagindo com Profissionais de Desenvolvimento e QA em Times Ágeis
Se existe algum(a) designer (de interação ou de interfaces) que já teve seu projeto aprovado pelo cliente, e pelo time de desenvolvimento e/ou de QA, logo de primeira, levante a mão por favor! Quero saber a mágica que você utilizou.
Não, esse não é um artigo sobre tendências de visual, regras de interface ou boas práticas de usabilidade em interfaces digitais, muito menos um guia de processos em design. É um artigo sobre Design Constraints e de como conviver de forma sadia e harmoniosa com as pessoas em times ágeis. 😃
Imagine…
Você designer, acaba de concluir os layouts de um projeto, faz um protótipo de altíssima fidelidade, com todas as transições de telas, animações e efeitos maravilhosos que você sempre sonhou e pensou como solução para facilitar a vida de quem usa o seu produto. Testou com usuários(as) e todos acharam lindo, bem intuitivo e fácil de usar o seu produto; mostrou para o(a) cliente e, por incrível que pareça, se encantou de primeira. Te elogiou bastante e disse até, que o seu trabalho era digno de entrar para o Awwwards, onde só tem referências e tendências dos melhores sites da web.
E é com essa alegria toda, pensando que o seu trabalho tivesse concluído e que agora seria somente "passar a bola", você apresenta o seu belíssimo trabalho para o time de desenvolvimento e de QA (Quality Assurance) do projeto, e...
Com a leveza de um chumbo, são lançados a você dezenas de questionamentos, dúvidas, críticas, sugestões, restrições, e argumentos que acabam com a sua alegria e te geram uma certa frustração, pois o trabalho que você tanto gostou e se orgulhou em ter feito está sendo alvo de críticas e apontamentos.
Quem nunca passou por uma situação parecida como essa não é mesmo?
Pois bem amigo(a), não precisa se frustrar, ficar triste ou entrar em desespero por saber que sua interface não é viável ou factível de ser desenvolvida ou implementada. Isso é normal! O fato de terem feito dezenas de questionamentos não quer dizer que o seu trabalho está ruim. Esses questionamentos fazem parte do trabalho dessas pessoas pois precisam entender TODO o funcionamento do produto e da interface para poder construir o que foi projetado, e como foi você quem projetou, você é quem acaba sendo o centro dessas informações.
Nesse artigo, espero te ajudar dando algumas dicas de algumas coisas que venho aprendendo com pessoas que desenvolvem o que eu projeto e com analistas de testes que garantem a qualidade daquilo que projeto. São coisas que devem fazer parte do seu processo, projeto e entrega de design para minimizar o estresse que você acaba tendo com o retrabalho, por não ter levado em consideração aspectos relevantes do projeto e do time, e as chamadas Design Constraints.
Para começar, o que danado é Design Constraints? 🤔
Bem, Design Constraints são aquelas restrições ou limitações que devemos levar em consideração antes de projetar algo em design. Essas restrições e limitações são impostas pelas condições do projeto ou do cliente e você não pode controlá-las, como restrições comerciais, de requisitos (funcionais e não-funcionais), de conformidade, de estilo (restrições de cores ou determinadas fontes tipográficas, por exemplo), de usabilidade, de integração, de design sensorial e aquelas relacionadas aos princípios (seja do projeto, da organização, do cliente, ou de quem for).
Portanto, o trabalho de design (tanto de UX como de UI), dentro de um time ágil, não termina na construção de uma interface e num conjunto de interações que resolvam o problema do(a) usuário/cliente. Faz parte do nosso trabalho também, o estudo das premissas e restrições do time, do projeto, do cliente/usuário e da organização, a fim de integrar e criar conexões funcionais e eficientes entre os interesses e limitações de todos esses envolvidos.
E como é trabalhar em times ágeis?
Um projeto de desenvolvimento de softwares de time ágil, geralmente, é composto por frentes de trabalhos (equipes). De forma breve, são elas:
- a equipe de Gestão: GP (Gerente de Projetos), PO (Product Owner), subgerentes, etc… Ou seja, os profissionais responsáveis por gerenciar e monitorar todo o projeto e combinar coisas com o cliente, como entregas de funcionalidades, prazos, prioridades, entre várias outros assuntos.
- a equipe de Desenvolvimento: Programadores(as) — front-end e back-end, responsáveis por desenvolver, implementar e manter o sistema rodando perfeitamente.
- a equipe de QA (Quality Assurance): Analistas de testes, responsáveis pela asseguração da qualidade do sistema, prezando pelo aspecto funcional e utilizável do produto.
- a equipe de Design (UX/UI): Designers que são responsáveis por transformar as necessidades do(a) cliente e do(a) usuário(a) em requisitos para o produto, ou sistema e assegurar as melhores abordagens de interação e usabilidade.
Então, nós designers geralmente trabalhamos com sprints à frente do time de desenvolvimento e de testes. Isso quer dizer que, enquanto estamos trabalhando em algumas atividades, o pessoal está desenvolvendo e testando entregas que fizemos anteriormente. Funciona mais ou menos assim:
Bem, com isso, nem sempre temos disponíveis ao nosso lado pessoas de desenvolvimento e/ou de QA para nos ajudar no projeto que estamos criando. Ou seja, nem sempre dá para co-criar com esses profissionais, embora, sempre que for possível, devemos consultá-los para tirar dúvidas e obter respostas quanto a viabilidade técnica de requisitos e detalhes de UX ou de UI. Esta forma de "chamar" o time (ou pessoas-chaves de cada equipe) para perto, como suporte no momento de criação, faz parte da abordagem do Little Design Upfront (Adikari et al., 2009), em que "é fornecido apenas detalhes suficientes das informações de design (UX/UI) para apoiar a análise popular JIT (Just-in-Time) para que a perspectiva do UCD (User-Centered Design) possa ser considerada sem sobrecarregar as práticas ágeis existentes."
Convivendo com PESSOAS em projetos ágeis
O manifesto ágil postula 12 princípios e destaca 4 valores que devem ser seguidos em projetos de desenvolvimento de software e que devem andar juntos, harmonicamente, entre as equipes do projeto. Dentre os princípios, os que mais estão ligados diretamente, ao trabalho do designer são: o 2º (a aceitação de mudanças de requisitos, mesmo no fim do desenvolvimento) — é mais normal do que parece, então é bom ir se acostumando; o 9º (a contínua atenção à excelência técnica e bom design, aumentando assim a agilidade); e o 10º (a simplicidade como a arte de maximizar a quantidade de trabalho que não precisou ser feito). Dentre os valores que fazem parte de sua essência, talvez o mais importante e o que precisa ser levado mais em conta, principalmente por nós designers, seja o 1º:
Indivíduos e interações mais que processos e ferramentas.
Isso quer dizer que "devemos entender que o desenvolvimento de software é uma atividade humana e que a qualidade da interação entre as pessoas pode resolver problemas crônicos de comunicação. Processos e ferramentas são importantes, mas devem ser simples e úteis."
Então é com base nesse pensamento que devemos ter em nosso cotidiano essa interação constante com as pessoas que desenvolvem e garantem a qualidade do nosso produto, e que essa interação seja sempre baseada em uma comunicação e relação amistosas fomentando a harmonia e o respeito mútuo entre o time.
Para ter esse tipo de relação, devemos construir nossas operações baseadas em três pilares: Empatia, Colaboração e Sistematização, que devem andar sempre juntos.
Empatia 💙
Calma! Não vou te explicar o que você já sabe. E outra, por que explicar algo desse tipo se eu mesmo não acredito que exista um design empático? 👀(Norman, 2019).
Infelizmente, essa palavra tornou-se clichê e uma buzzword no nosso meio. São frequentes os discursos sobre empatia com usuário em processos de Design, em UX, em UI, etc… E realmente precisamos entender que nós (não só como designers, mas como seres humanos) temos que aprender e praticar cada vez mais.
Porém, defendo aqui que não devemos praticar a empatia APENAS com usuários. Não usemos a empatia APENAS como ferramenta ou etapa (parte) de um processo de design, como no design thinking por exemplo.
Vamos ser empáticos(as) na vida, com nossos familiares, com as pessoas as quais trabalhamos diariamente, sejam colegas de trabalho ou nossos(as) chefes, com as pessoas que nos ensinam de alguma maneira, com pessoas desconhecidas que encontramos no dia-a-dia, enfim… com todos(as) ao nosso redor. 😄
Empatia não é uma habilidade, é uma questão de caráter. Mas que dá pra se condicionar e aprender evoluindo, sendo apenas mais humano.
Em times ágeis, portanto, devemos ter empatia: ouvindo as críticas e os questionamentos das equipes e colegas, tentando compreender os mais diversos ponto de vista; ouvindo mais seu/sua gerente (e vice-versa, claro); sendo paciente ao ensinar alguém (seja mais novo no seu projeto, na área, enfim…); documentando de forma clara, simples e objetiva os requisitos do seu projeto de design, numa linguagem acessível para todos; tentando compreender os anseios e interesses do(a) cliente, mesmo que não sejam o que você quer ouvir, etc…
Empatia em times ágeis tem muito a ver com paciência, tolerância, respeito, humildade, pacificidade, compreensão e acessibilidade atitudinal.
Colaboração 🍻
Outro clichê que conhecemos bem é o famoso: "estamos todos no mesmo barco."
Em alguns contextos essa frase torna-se uma falácia, mas aqui, se tratando de agilidade em projetos, é pura verdade.
Nesse tipo de projeto, o trabalho de uma equipe implica diretamente no resultado da outra, e consequentemente, no resultado do projeto.
Portanto, nós designers temos que projetar e fazer o nosso trabalho levando em consideração, cada vez mais, as opiniões do restante das equipes. Temos que trabalhar o Design como um grande Facilitador no projeto, proporcionando praticidade e agilidade ao time como um todo.
A Colaboração nada mais é do que a Empatia coletiva.
Em times ágeis, portanto, devemos ser colaborativos e facilitar os trabalhos do time: buscando referências (seja em bibliotecas, em sistemas terceiros, em seu repertório, etc…) e consultando as equipes do projeto sobre determinado tipo de comportamento ou interação que inserimos no projeto; projetando junto com o time; validando com o time a viabilidade técnica (tanto de desenvolvimento como de implementação) de requisitos, etc…
Colaboração em times ágeis tem muito a ver com co-criação, ajuda mútua, altruísmo, empatia, solidariedade, fraternidade, amizade e companheirismo.
Sistematização ♻️
A palavra que talvez seja menos clichê das três é a mesma que representa a parte mais técnica para construir uma relação mais amistosa e harmoniosa com equipes ágeis.
Como vimos, essa relação é baseada integralmente em comunicação. Então todos do time precisam "falar a mesma língua" para que haja o mínimo de entendimento e sinergia para a engrenagem do projeto girar.
Então, nós designers precisamos pensar além da interface ou da interação que estamos projetando (como se já não fosse o bastante né?), temos que pensar em "tudo".
Precisamos ter uma ideia do que nossas ações e requisitos vão impactar no sistema, ou seja, precisamos ter noções, embora que mínimas, sobre performance e desempenho, dados e integrações, entre outras coisas, para que na hora de projetar, possamos levar em conta todo o fluxo de informações (de onde vêm, como, onde e quando são processadas, e para onde vão).
Sistematização é a capacidade de organizar e gerenciar as complexidades que envolvem o funcionamento do produto.
Em times ágeis, portanto, devemos pensar de modo sistematizado: englobando e considerando todos os fatores e variáveis que podem implicar (direta e indiretamente) no sistema, e consequentemente, na decisão do(a) usuário(a); sabendo priorizar as atividades de acordo com atributos que entregam valor; padronizando processos e entregas; pensando e projetando cenários alternativos que não fazem parte, necessariamente, do caminho feliz (Golden Path) da proposta; pensando em comportamentos de interface e usabilidade em cenários de erro, em cenários de carregamento de dados (como loadings, empty state e as Skeletons Pages, por exemplo), em cenários com base de dados vazia (primeiro acesso ao sistema, por exemplo), em cenários com uma quantidade máxima de dados; pensando nos mais variados perfis de usuários(as) que irão utilizar o sistema e suas respectivas permissões; pensando em todas as macro e microinterações do sistema e todos os mecanismos de feedbacks possíveis; versionando os arquivos e tendo um histórico de todas as alterações que foram sendo realizadas ao longo do projeto, e claro, sempre mantendo coerência e atenção para que o design corresponda às clássicas Heurísticas de Nielsen.
Um ótimo exemplo de sistematização, em Design, é o Design System, que mapeia e organiza todos os elementos, componentes, aspectos, funcionalidades, regras, princípios e valores de um projeto.
Sistematização em times ágeis tem muito a ver com organização, padronização, amplitude, visão geral, lógica, raciocínio, mapeamento, conexões, relações e implicações.
Considerações finais
A mudança só ocorre de dentro para fora. Então não adianta você começar sistematizando todo o processo, sem antes, praticar empatia e pensar coletivamente nas pessoas e em suas atividades. Primeiro é preciso trabalhar o seu mindset para não levar as críticas para o lado pessoal, e a Empatia é um dos melhores meios de aprender isso, compreendendo e tentando entender a perspectiva da outra pessoa. E, a partir disso é que é possível fazer do projeto um espaço de Colaboração entre os indivíduos, uma espécie de empatia em rede. E só então, com todos compreendendo as diferentes visões e dificuldades do projeto e do time, é que é possível realizar uma Sistematização, a fim de facilitar os trabalhos das pessoas e fomentar o principal aspecto desse tipo de projeto: a agilidade.
Então, para concluir, depois de levar muitos "nãos dá" de algumas pessoas com quem trabalhei, e trabalho, por não ter condições de fazer aquilo que projetei, posso dizer que sou grato por cada um deles, pois me fizeram compreender que a principal lição disso tudo é o aprendizado e a melhoria contínua (do sistema — o produto, do time — as condições de trabalho, e como indivíduo — do conhecimento e pela prática da empatia) ou seja, ter conhecimento da jornada tecnológica à jornada das pessoas.
Ouvir mais do que contestar. E aprender mais do que trabalhar. Sempre!
