UX/UI Design: Implementação, handoff e otimização contínua com IA

A arte da documentação de handoff - Apresentação

Apresentando o instrutor e sua experiência

Olá, bem-vindo. Meu nome é Rodrigo Lêmes e atualmente sou diretor de escritório e designer principal. Trabalho como designer de produto há quase 30 anos e, ao longo desse tempo, acumulei muitas experiências. Tive a oportunidade de trabalhar com startups, bancos, empresas de tecnologia dentro e fora do país, e também com empresas que sempre precisaram de profissionais de design que vão além de uma interface bonita. Essas empresas necessitam de pessoas de design que compreendam o produto, falem a linguagem da equipe e, claro, consigam demonstrar o valor do que estão criando.

Durante esse tempo, aprendi algo que mudou completamente a forma como trabalho: o design só terá valor quando puder transitar entre engenharia, desenvolvimento, produto, e QA (etapa de verificação de qualidade), chegando até o usuário final e mantendo sentido em um processo contínuo. Para que isso ocorra, precisamos de um processo consistente e estruturado, não baseado em inspiração, mas em repetição e estratégia. Essa é a ideia que quero transmitir aqui.

Introduzindo o curso e sua estrutura

Gravei um curso anterior a este, que é praticamente o primeiro passo, onde fomos desde o dado bruto até um protótipo testável. Nele, apresentei uma base sobre UI Kit, coleção de peças visuais, fluxo de telas, evidências, entre outras coisas. No entanto, não é necessário fazer esse curso, pois são independentes. Minha ideia agora é transformar o que você pode aprender lá em um produto real aqui, que pode ser levado à produção. Se você chegou diretamente a este curso, não há problema. Vou contextualizar tudo o que você precisará ao longo do caminho, então não se preocupe em pensar que precisa fazer os dois. Aqui, seguimos outra lógica e ideia, mas estão conectados, se você desejar.

Discutindo o conceito de Design System

Vamos começar discutindo sobre Design System. O que é um Design System? Trata-se de um conjunto de regras visuais compartilhadas que garantem que a equipe fale o mesmo idioma, o mesmo linguagem visual. Precisamos entender como funciona o Design System, e em breve revelaremos o segredo por trás disso.

Explorando o processo de Handoff e QA visual

Na segunda parte, abordaremos o famoso Handoff. O que é o Handoff? É o processo de entregar o design para a engenharia e desenvolvimento de uma maneira que ninguém precise adivinhar nada, como, por exemplo, qual é a cor ou onde está determinado arquivo. Um Handoff bem feito elimina esse tipo de problema.

Em seguida, passamos para o QA visual, que é a avaliação de qualidade. Nesse momento, verificamos se o que foi implementado pela equipe de desenvolvimento realmente corresponde ao que a pessoa de design projetou e desenhou.

Iterando com base em sinais reais de produto

Depois, avançamos para uma visão no módulo 4, onde aprendemos a iterar com base em sinais reais de produto. Estudaremos como usar dados de comportamento do usuário para melhorar a experiência de maneira contínua, semana após semana, iterando constantemente.

Conectando métricas de negócio e inteligência artificial

No final, encerramos essa visão no módulo 5, fechando o ciclo completo ao conectar métricas de negócio diretamente às telas e componentes do produto. E aí vem o grande truque, a cereja do bolo: queremos fazer tudo isso utilizando inteligência artificial, que é uma ferramenta indispensável. Exploraremos o Gemini, Figma Make, FigJam, entre outras ferramentas que podem surgir ao longo do caminho para contextualizar e manter todos atualizados.

Não é para substituir o pensamento ou raciocínio de uma pessoa de design, mas para acelerar o trabalho, que antes poderia levar dias ou horas, e agora conseguimos realizar de forma muito ágil. Estamos ansiosos para mostrar isso.

Apresentando o produto Pix Parcelado

Vamos continuar usando uma ideia de outro curso, que é o mesmo produto. Falaremos sobre um produto chamado Pix Parcelado, que será uma funcionalidade de banco digital que permitirá pagar em parcelas transações de Pix. Explicaremos isso e traremos o conjunto de dados para acompanhar esse produto do início ao fim, do Design System à Launch Review, que é a parte de revisão de lançamento.

Encorajando a aprendizagem e início do curso

Outro ponto importante a alinhar é que não é necessário ter experiência em nenhuma dessas ferramentas. O que realmente precisamos é vontade de aprender, inclusive de aprender uma forma nova e talvez mais ágil de trabalhar. O que acham? Vamos começar.

A arte da documentação de handoff - Dataset do projeto

Alinhando a visão do produto

Antes de começarmos, é importante alinharmos uma visão do produto no qual queremos trabalhar, que é o PIX Parcelado. Já possuímos uma série de dados previamente construídos para nos ajudar a estabelecer uma visão mais realista, pois é difícil criar um produto sem dados. Já estipulamos tudo aqui para que possamos alcançar esse objetivo.

Vamos agora analisar o dataset, que é um conjunto de informações onde podemos ter uma visão exata dos detalhes. Por exemplo, ao observarmos a tela, temos este dataset, que é muito importante alinhar novamente. Se alguém acabou de chegar, aqui está a informação.

Analisando o dataset e suas métricas

O que é este dataset? São dados que já organizamos com a IA e que continuaremos a organizar. Ele indica que há um funil de captura de dados de 30 dias. Temos 48.200 usuários que visualizaram o banner do PIX Parcelado, o que é importante sabermos. Em seguida, 12.900 pessoas clicaram, resultando em um CTR de 26,7%. Destas, 6.300 iniciaram uma simulação, 2.400 chegaram à tela de confirmação e 860 finalizaram. Isso nos mostra uma taxa de cliques e uma queda principal, que podemos chamar de "Drop Principal", na tela "Entenda as Taxas", com um abandono de 38%. Esse índice é alto.

Além disso, capturamos em 30 dias 1.140 tickets mencionando o PIX Parcelado. São pessoas que abriram um ticket de alguma forma. Os termos mais citados que capturamos são: juros, taxa, não aprovado, limite, cadastro e confuso.

Coletando feedback dos usuários

Outro dado relevante é que também temos comentários feitos dentro do aplicativo, uma amostra de NPS disso. Aqui estão os comentários dos usuários: "No momento de confirmar, apareceu uma taxa que não entendi e desisti." "Queria pagar a prazo para fechar o mês, mas tive medo de que se tornasse uma bola de neve." "Não ficou claro por que não fui aprovado." "Parece uma armadilha, primeiro mostra o valor e depois muda." "A tela tem muito texto, eu só queria saber quanto vou pagar por mês." "Usei, mas depois não encontrei onde seguir as parcelas." "O botão desaparece, fica deslocando, parece que trava."

O limite parece diferente em cada tela, e o serviço de atendimento não sabe explicar o motivo. Pagar parcelado deveria ser simples, mas isso é uma burocracia digital. Se tivéssemos um resumo final, como uma fatura, haveria mais confiança. Queremos pagar parcelado, mas sem custo adicional.

Extraindo insights das entrevistas

Além disso, temos dados que são fragmentos de uma simulação, claramente de possíveis entrevistas com usuários. São vários comentários fundamentais. Quando pensamos em ter esse tipo de feedback, é extremamente valioso. Se todo produto tivesse feedback dessa forma, estaríamos em um cenário ideal. Portanto, aproveitemos que temos dados como esses.

Das entrevistas que capturamos, percebemos que, ao ver os juros, muitos não entendem e preferem não arriscar. A sensação é de que as informações estão sendo ocultadas, e há um desejo por transparência. As pessoas querem saber por que não foram aprovadas; sem essa informação, sentem-se rejeitadas. Algumas aceitaram, mas depois ficaram ansiosas, sem saber quanto ainda faltava. Não há confiança quando o valor muda no meio do processo. O texto é longo e parece um contrato, o que leva a pular partes e depois se arrepender.

Contextualizando o trabalho anterior e próximos passos

Essas informações são fundamentais. Como comentado, no outro curso trabalhamos com esses dados para chegar a um protótipo. A ideia foi mostrar como, através da IA, poderíamos construir um produto usando e extraindo informações, organizando tudo com a IA. Foi um enfoque mais técnico, centrado em métodos. Como mapeamos as partes interessadas? Como mapeamos o usuário? Como conseguimos extrair um insight, uma ideação? Usando esses dados que estão aqui.

Estou trazendo isso para contextualizar o que foi feito no primeiro diamante, para que possamos avançar agora. Vamos falar sobre o sistema de design. A partir de agora, começaremos a construir um produto de verdade. Vamos gerar o sistema de design dos componentes e elementos necessários para ter um produto. Já fizemos parte disso no curso anterior, mas agora é uma continuação de forma diferente, para nos estabelecer em processos estruturados. Lembremos disso.

Este é o dataset com a informação importante para que possamos seguir. Queria muito registrar isso aqui para dar contexto ou para relembrar o que já discutimos antes. Então, é isso. Vamos passar para o próximo curso. Nos vemos lá. Vamos em frente.

A arte da documentação de handoff - Componentes

Discutindo erros comuns em produtos digitais

Vamos discutir um erro que gera muito retrabalho em um produto digital. O designer faz seu trabalho e entrega o componente perfeito para o estado padrão, quando tudo está funcionando bem. No entanto, quando o usuário abre o aplicativo e a conexão com a internet cai, o limite não estará disponível em um aplicativo como o nosso do PIX em parcelas, e então o valor muda. Não há nenhum estado visual projetado para isso, e a engenharia improvisa. O produto falha e o usuário pensa que é um problema do aplicativo.

Quando falamos do estado de um componente, referimo-nos a como o bloco visual se comporta quando as condições mudam. Em nosso aplicativo do PIX em parcelas, as condições mudam constantemente. O usuário simula um valor, o sistema calcula, demora, responde, não aprova ou aprova com uma condição diferente. Cada um desses momentos precisa de um estado visual projetado.

Listando estados fundamentais para componentes financeiros

Vamos listar os estados fundamentais que todo componente de um produto financeiro, como o nosso, precisa ter, ou que se aplicam a outros produtos. Primeiro, temos o estado padrão, que é o que geralmente começamos a desenhar. Segundo, o loading (carregando), quando o sistema está processando. Um erro clássico aqui é não deixar claro o que está sendo carregado, fazendo o usuário acreditar que o aplicativo travou. Terceiro, o erro, quando algo falha; deve haver uma mensagem e um próximo passo, pois sem um próximo passo o usuário abandona o fluxo completamente. Quarto, o vazio (empty), quando ainda não há dados para mostrar. Quinto, em um aplicativo como este do PIX em parcelas, podemos falar do estado "não aprovado", que é o estado mais sensível dessa ideia do PIX em parcelas. Sem explicação e sem uma alternativa oferecida, esse estado se transformará em um rejeição total, e o usuário sairá sem entender o que aconteceu.

Dominando conceitos técnicos no Figma

Dois conceitos técnicos que precisamos dominar no Figma são: variante, que é uma versão do mesmo componente com propriedades distintas; por exemplo, ter o mesmo botão em versões diferentes, como o padrão, o loading, o erro e o desabilitado, tudo organizado em um só lugar. Assim, quando a engenharia implementa, tem o componente completo, e não pela metade. O outro conceito é o auto layout, que é uma função do Figma que faz com que o componente se adapte automaticamente ao conteúdo, sem ajustes manuais. Em um produto financeiro, como nossa ideia aqui, onde o texto muda conforme o valor, a parcela e a aprovação, um componente sem auto layout se torna um problema ao ser implementado.

Definindo estados críticos para o PIX em parcelas

Nosso trabalho agora é definir os estados do componente mais crítico da nossa ideia do PIX em parcelas. Por exemplo, estou pensando no componente: o card resumo de custo. Este componente aparece em quase todas as telas do fluxo em que estamos trabalhando. Se tiver todos os estados bem definidos, a maioria dos problemas visuais do produto estará completamente resolvida de alguma forma.

A ideia é ir ao Gemini para que possamos trabalhar nisso, como podem ver na tela. Começamos no Gemini e pedimos uma lista completa de estados por componente do nosso fluxo. Não queremos inventar estados, queremos que a inteligência artificial nos mostre o que os dados do produto já indicam que acontecerá. Isso nos ajudará a trabalhar de forma ordenada e agilizar um tipo de pensamento que depois passará por revisão. Assim, é tranquilo para nós fazer esse tipo de coisa. Vamos usar o Gemini. O Gemini já está aberto para que possamos trabalhar de algum modo.

Utilizando o Gemini para listar estados de componentes

No Gemini, pensamos em seguir com um prompt mais ou menos assim: queremos dar um contexto, obviamente, que é o PIX em parcelas em um banco digital, onde temos o objetivo de ser mobile first, ou seja, o foco é a aplicação móvel. Dizemos para seguir o dataset, aquele que já mostramos, que são essas informações. E então pedimos: para os seguintes componentes, queremos que liste os estados necessários. No vídeo anterior, mencionamos os nomes: Card Resumo Custo, Call to Action Primário, Detalhes e Camadas, Input Simulação. Depois, pedimos: para cada estado de cada componente, queremos um nome do estado, que facilite a criação disso, para não perdermos tempo pensando nesse tipo de coisa. O que dispara esse estado, o que é bom porque já pode nos dar uma visão de variantes. Qual é a microcópia, qual é o texto, qual é o texto da etiqueta, como chamamos, se houver. E o risco se esse estado não for projetado, para que possamos cobrir possibilidades. Pedimos que baseie os estados em evidências do dataset, e se não houver evidência direta, marque como hipótese, para não inventar coisas que não existem. Isso é interessante para que possamos revisar depois se isso funciona ou não.

Ao dar Enter, o Gemini gera informações sobre isso. Para garantir o design system do PIX em parcelas, resolve as fricções de confiança e de usabilidade identificadas. Ele nos dá, no card resumo de custo, o ancoramento do fluxo; traz o nome do estado: padrão, o gatilho: entrada na tela, o usuário entrou. A visualização: card destacado, com o valor da parcela. Qual poderia ser o texto, microcópia: parcela fixa de X reais, risco se não for projetado ou abandono por falta de clareza imediata. Isso coincide com o dataset; até indica qual foi o NPS de reclamações registrado. E assim por diante; fala do stick fixado, que é o scroll para baixo quando o usuário desloca a tela; é um card, e indica o texto breve que terá. Atualizando, é a mudança do número de parcelas, ou seja, um efeito nos valores, que é recalcular, encargos, taxas e divergência, ou divergente, que é um alerta. Faz o mesmo para o call to action primário, e descreve o mesmo: entrega uma lista exatamente com o nome do estado, o gatilho, a visualização, a microcópia, o risco se não for projetado. O detalhe em camadas, o mesmo; o input de simulação e o estado não aprovado. Isso é interessante porque já nos cobre dando a informação necessária, não só para visualizar quais são as variantes que precisamos trabalhar em nosso componente, mas também mostra que, se não implementarmos isso corretamente, o risco de não projetá-lo, por exemplo, no caso negativo temporário do estado não aprovado. Haverá uma sensação de rejeição e isso coincidirá com o dataset registrado aqui, até mesmo a sigla que aparece no dataset. Isso é interessante porque nos dá uma visão completa de uma documentação para que possa encaixar em um backlog, nas tarefas que vamos fazer; então haverá que fazer isso, isso e isso, e revisar com a equipe.

Criando variantes no Figma com base nos estados listados

O bom aqui, quando temos essa lista de estados em mãos, é que podemos ir agora ao Figma. Sim, podemos ir e criar esse card resumo de custo com as seis variantes. As variantes, de fato, foram sugeridas: o padrão, o loading, o expandido, o erro, o empty state e o não aprovado. Pode até parecer muito, mas cada variante é uma proteção contra um tipo de erro que pode ser diferente.

Uma regra que sugerimos aqui é que o componente não saia da biblioteca sem todos os estados fechados. Não teremos tempo de fechar todos agora, mas é interessante ter isso em um documento que mostre tudo, e o que ficar de fora entra como o que chamamos de Deuda Técnica de Design, que é o nome dado a decisões que precisam ser tomadas, mas que ainda não foram implementadas.

Documentando componentes no Figma Make

Vamos ao Figma, agora ao Figma Make, para criar o quadro de documentação desses componentes, que é um painel que podemos construir para mostrar todos esses estados lado a lado. Podemos solicitar uma legenda, para que qualquer pessoa da equipe entenda sem necessidade de uma reunião; ou seja, vamos criar um documento abrangente que mostre exatamente o que é necessário ver a respeito disso. Vamos ao Figma Make agora para que possamos trabalhar.

No Figma Make, estamos no mesmo arquivo que criamos do Foundation do Design System, no vídeo anterior, onde as pessoas têm os padrões e tudo mais; podemos criar um documento novo, copiar e colar isso. Como temos o arquivo com esses padrões, podemos pegar esse frame, copiá-lo e colá-lo no Figma Make para garantir, como um frame, caso seja sobrescrito. Outra coisa que fizemos foi pegar o que Gemini criou aqui, de algum modo, copiamos todos esses textos e os colamos no Figma Make, e ele os trouxe como um arquivo de texto anexado.

Solicitando a criação de um frame de documentação

O que estamos pedindo ao Figma Make? Criar um frame de documentação de componente no Figma; queremos um componente com o card resumo de custo do PIX em parcelas; precisamos de uma grade que mostre os seis estados lado a lado, queremos uma legenda para cada estado: nome e o que o aciona; queremos as propriedades do componente listadas; queremos tokens aplicados, queremos campo de Deuda de Design para estados pendentes, e queremos campo de versão e data. Solicitamos um estilo de documentação claro, com alto contraste legível. Vamos anexar abaixo a informação para isso.

Aqui estão nossas instruções para o Figma Make, para que possamos gerar e ver o que será produzido. Vamos dar Enter e ver agora o que será gerado e como isso funcionará. Isso pode levar tempo, mas não se preocupe, não ficaremos aqui o tempo todo, pois avançaremos o vídeo para que possamos ver o que será criado. Não pense "nossa, que rápido está a máquina"; na verdade, precisamos ir rápido para ver o que será criado.

Analisando o resultado gerado pelo Figma Make

Para que tenham uma ideia, já começou a fazer tudo aqui, um "Work With" One File. Está trabalhando no arquivo que anexamos, e vamos ver o que nos trará a respeito disso. Podemos fazer essa convergência de mistura de arquivos, que é interessante, para que possamos ver, levar um dado a outro, e fazer esse intercâmbio mais rápido, e se formos a uma reunião, por exemplo, já teremos quase tudo definido para entregar às pessoas desenvolvedoras, à engenharia, à direção, ao produto, aos outros times de design, para que possam ver o avanço do trabalho.

Vamos ver o resultado que será gerado em breve. Muito bem, então aqui avançou, e disse: veja, criamos a documentação completa do componente do Card Resumo de Custo para o PIX em parcelas; a página apresentou os seis estados do componente em uma grade visual, com as legendas explicativas, conforme solicitado no prompt para Figma Make.

O que nos traz aqui? Traz exatamente isso: Card Resumo de Custo, onde temos os estados do componente, todos os estados e tamanhos; além disso, já mostra como se fosse um protótipo no canto: a parcela fixa e o recálculo de taxas. Mostra uma variação: o valor mudou devido à variedade de oferta, quando selecionado, quando está pendente ou não está funcionando. Aqui traz as propriedades, ou seja: State, Parcela, Total, Número de Parcelas, Tip, String, Padrão, Descrição, os Tokens; isso é muito importante, como já falamos: Bordas do estado Hover, o texto primário, o espaçamento, a tipografia e a deuda de design: definir o comportamento do tipo explicativo, prioridade alta, Divergente, para animação de transição, Média, e o Stick: definir o Breakpoint Mobile para o componente Stick, ou seja, também é alta prioridade para uma próxima release.

Revisando e refinando a documentação gerada

É bom porque aqui temos um informativo; pode conter erros? Claro, sem dúvida; vale a pena revisá-lo depois e fazer uma revisão deste arquivo para verificar se está tudo certo, se falta algo e assim por diante. Vamos voltar ao nosso arquivo em que estamos trabalhando e em breve mostraremos outras coisas e colaremos este documento. Aqui temos o Foundations, que são as questões de cores, tokens, etc., que já vimos em vídeos anteriores e agora somamos com a especificação a respeito do Card Resumo de Custo.

Agora poderíamos solicitar, de todos esses componentes citados que geramos em Gemini, que os faça um por um. Apenas fomos pelo Card Resumo porque nos permite resumir e ver a ideia, mas poderíamos fazer isso para todos os componentes, todo esse tipo de aparato de informação. E antes de terminar, também é interessante que nos detenhamos a pensar o que acontece quando apresentamos este frame, esta informação, à engenharia. A conversa muda, porque já não é apenas "All Design"; agora, de alguma forma, estamos trabalhando com a ideia de que este contrato visual de como este componente deve funcionar, e um contrato, claramente, tem critérios e os critérios têm testes.

Protegendo contra erros e bugs com estados bem definidos

Quando falamos do estado de um componente, é uma proteção contra possíveis bugs. Sem estado de erro, por exemplo, a engenharia improvisará; sem qualquer outro estado, a engenharia improvisará. E sem um estado de loading, por exemplo, a pessoa usuária pensará que o aplicativo congelou. Uma variante no Figma é um mecanismo que agrupa todos os estados em uma única entidade organizada. E como já comentamos, o Auto Layout, quando trabalhamos com Auto Layout aqui, fará com que o componente se adapte ao conteúdo automaticamente. Assim, é essencial que observemos essas coisas, para qualquer produto e para nosso caso aqui também.

Além disso, é um produto onde os textos mudam constantemente. Precisamos ver e entender como isso funciona. E falando de Auto Layout, outro ponto: não sei se sabem, mas quando falamos ainda das funcionalidades do handoff relacionadas com DevMode; de fato, se não estivermos trabalhando com Auto Layout, geraremos também um problema técnico que deverá ser resolvido.

Automatizando processos com inteligência artificial

Tudo isso faz parte de um sistema de trabalho que conversa com o Design System e que, se somarmos, como vimos que fizemos neste vídeo, com a inteligência artificial, agilizamos muito o processo. Antes, tínhamos que desenhar toda essa documentação de componentes à mão. Ainda se desenha, mas não é necessário; podemos automatizar tudo isso. Obviamente, como já dissemos, pode conter erros; então vale a nossa revisão depois, mas gastaremos muito menos tempo do que se desenhássemos tudo à mão. Esse refinamento é totalmente viável, mas considere que passar por essas etapas como as que estamos seguindo e depois apenas fazer a revisão, reduzirá muito os prazos de trabalho.

Fica aqui, agora, esta ideia neste vídeo para mostrar como é o fluxo de pensamento a respeito de como agilizar um processo de construção de um Design System e a componentização e os documentos, etc. Nos vemos no próximo vídeo para aprofundar mais neste tema. Vamos.

Sobre o curso UX/UI Design: Implementação, handoff e otimização contínua com IA

O curso UX/UI Design: Implementação, handoff e otimização contínua com IA possui 227 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de UX Design em UX & Design, ou leia nossos artigos de UX & Design.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• A arte da documentação de handoff
• QA de UX e teste de implementação
• Ciclo de feedback contínuo
• Base do Design system
• Análise de métricas pós-lançamento