O que é composição de componentes (e por que isso muda a forma de desenhar fluxos)
Composição de componentes é a prática de construir interfaces complexas a partir de peças menores, estáveis e reutilizáveis, combinando-as de forma previsível. Em vez de criar “telas” como artefatos isolados, você monta estruturas com blocos que já carregam decisões de comportamento, espaçamento, estados e regras de uso. O resultado é um fluxo de produto mais consistente, mais rápido de iterar e com menos divergência entre design e implementação.
Na prática, composição significa pensar em camadas de construção: elementos básicos (como ícones, textos e botões) formam componentes simples; componentes simples formam componentes compostos (como um item de lista com ícone, título, descrição e ação); e componentes compostos formam padrões de fluxo (como um formulário completo, um checkout, um onboarding ou um “empty state” com ações).
O ponto central é que o valor não está apenas em reutilizar “componentes visuais”, mas em reutilizar “soluções de interação” recorrentes. Um fluxo de cadastro, por exemplo, não é apenas um conjunto de campos: ele tem validação, mensagens, estados de carregamento, progressão, confirmação, recuperação de erro e caminhos alternativos. Composição bem feita transforma essas decisões em padrões reutilizáveis.
Composição vs. variação: quando usar cada uma
Mesmo sem entrar em detalhes de propriedades e variantes (já cobertos em capítulos anteriores), vale a regra prática: use variação quando o componente é o mesmo “tipo” e muda apenas parâmetros (ex.: tamanho, tom, estado). Use composição quando você está montando uma estrutura maior com múltiplas partes e responsabilidades (ex.: um “Card de Produto” que inclui imagem, título, preço, selo, avaliação e CTA).
Outro sinal de que você precisa de composição: quando você começa a copiar e colar grupos de componentes para formar uma seção inteira (ex.: “Resumo do pedido” + “Método de pagamento” + “Endereço” + “Botão final”). Isso indica que existe um padrão de fluxo, não apenas um componente isolado.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Tipos de padrões reutilizáveis em fluxos de produto
Para organizar o raciocínio, pense em padrões reutilizáveis em três níveis, do menor para o maior. Essa classificação ajuda a decidir o que vira componente composto, o que vira “template” de seção e o que vira “blueprint” de fluxo.
1) Padrões de microinteração (nível de componente)
Entrada + feedback: campo com label, hint, contador, erro e sucesso.
Ação + confirmação: botão que abre confirmação, ou ação destrutiva com aviso.
Carregamento e skeleton: versão “placeholder” do mesmo componente para estados assíncronos.
Seleção e persistência: chips, toggles, radio/lista com estado selecionado e desabilitado.
2) Padrões de seção (nível de layout funcional)
Header de página: título, descrição, ações primária/secundária, breadcrumbs quando aplicável.
Lista com filtros: barra de busca, filtros, ordenação, resultados, estado vazio e paginação.
Formulário com agrupamento: seções com títulos, campos, ajuda contextual e validação.
Resumo lateral: painel com totais, itens, custos, CTA fixo e mensagens de confiança.
3) Padrões de fluxo (nível de jornada)
Onboarding: passos, progressão, permissão, confirmação, fallback.
Checkout: carrinho, endereço, pagamento, revisão, confirmação, erro.
Criação guiada (wizard): etapas, validação por etapa, salvar rascunho, revisão final.
Recuperação: esqueci senha, verificação, redefinição, sucesso, reenvio.
O objetivo é que o time consiga montar um fluxo novo combinando padrões já conhecidos, em vez de “inventar” a cada demanda. Isso reduz inconsistência e acelera decisões.
Princípios práticos para compor componentes sem virar um “Frankenstein”
Defina responsabilidades claras para cada camada
Um componente composto deve ter um propósito único e previsível. Exemplo: “Item de Lista de Produto” pode ser responsável por exibir informações e ações relacionadas a um produto em contexto de lista. Ele não deve decidir regras de navegação do fluxo inteiro, nem conter lógica de validação de formulário. Quando um componente começa a “fazer tudo”, ele fica difícil de reutilizar.
Prefira composição por slots (áreas substituíveis)
Pense em componentes compostos como estruturas com “slots”: área de mídia, área de conteúdo, área de metadados, área de ações. Assim, você reutiliza a estrutura e troca o conteúdo conforme o contexto. Em Figma, isso se traduz em subcomponentes bem definidos dentro do componente maior, permitindo substituições sem quebrar alinhamentos.
Evite dependências rígidas entre componentes
Se um componente composto só funciona com um tipo específico de botão, ou com um texto com tamanho específico, você cria acoplamento. O ideal é que o componente aceite diferentes conteúdos mantendo a estrutura. Um “Card” deve funcionar com ação primária, com duas ações, ou sem ações, sem exigir duplicação.
Crie padrões para estados de fluxo, não só para estados visuais
Fluxos têm estados recorrentes: carregando, vazio, erro, sucesso, bloqueado por permissão, sem conexão. Se você compõe telas apenas para o estado “feliz”, o time volta a improvisar quando surgem exceções. Transforme estados em padrões de seção e de fluxo.
Passo a passo: criando um padrão reutilizável de “Seção de formulário”
Este passo a passo foca em um padrão muito comum em fluxos: uma seção de formulário com título, descrição opcional, campos e área de ações/ajuda. A ideia é que essa seção seja reutilizável em cadastro, perfil, endereço, pagamento e configurações.
Passo 1 — Liste os elementos invariáveis e variáveis
Antes de desenhar, escreva o que quase sempre existe e o que muda conforme o contexto.
Invariáveis: título da seção, espaçamento entre blocos, alinhamento, área de campos, comportamento de mensagens (erro/ajuda), separação entre seções.
Variáveis: descrição (pode existir ou não), quantidade de campos, presença de campos condicionais, ação secundária (ex.: “Cancelar”), ajuda contextual (tooltip/link), aviso de segurança.
Essa lista evita que você crie um componente “fechado” demais ou “aberto” demais.
Passo 2 — Modele a estrutura em blocos (slots)
Estruture a seção em quatro áreas:
Header: título + descrição opcional + ação contextual (ex.: “Editar”).
Body: stack de campos (cada campo já é um componente).
Feedback: área para mensagens gerais da seção (ex.: erro do servidor, aviso de dados incompletos).
Footer: ações (ex.: “Salvar”, “Continuar”) e links auxiliares.
Ao compor, mantenha essas áreas como grupos claros dentro do componente, para facilitar substituição e manutenção.
Passo 3 — Defina regras de uso (documentação dentro do próprio arquivo)
Crie uma pequena especificação textual próxima ao componente (ou em uma página de guidelines do sistema) com regras objetivas. Exemplo:
Descrição é opcional; quando ausente, o header mantém o espaçamento vertical padrão.
Feedback geral aparece acima do footer, nunca entre campos.
Footer pode ter 1 ou 2 ações; se houver 2, a primária vem à direita (ou conforme padrão do produto).
Se a seção tiver mais de 8 campos, considerar dividir em subseções com subtítulos.
Essas regras evitam que cada designer “interprete” a composição de um jeito.
Passo 4 — Crie exemplos reais (instâncias) para validar a flexibilidade
Monte 3 instâncias do padrão com cenários diferentes:
Perfil: título + descrição + 4 campos + botão “Salvar”.
Endereço: título sem descrição + 7 campos + aviso de entrega + botões “Cancelar” e “Salvar”.
Pagamento: título + descrição + campos condicionais (cartão vs. boleto) + mensagem de erro geral.
Se você precisar duplicar o componente para acomodar um cenário comum, o padrão ainda não está bem composto.
Passo 5 — Conecte a seção a um padrão de fluxo
Agora use a “Seção de formulário” dentro de um fluxo maior, como um wizard de cadastro. O objetivo é verificar se a seção se comporta bem quando combinada com header de página, stepper, barra de progresso e ações fixas.
Uma verificação útil: a seção deve funcionar tanto em página única (tudo em uma tela) quanto em múltiplas etapas (uma seção por etapa), sem precisar redesenhar a estrutura.
Passo a passo: compondo um padrão de “Lista + detalhes” para fluxos de gestão
Em produtos B2B e áreas administrativas, um padrão recorrente é “lista de itens” com um painel de detalhes (ou navegação para detalhes). Esse padrão aparece em usuários, pedidos, tickets, inventário, permissões, etc. A composição correta reduz muito o trabalho em novas telas.
Passo 1 — Separe o padrão em três partes reutilizáveis
Barra de controle: busca, filtros, ordenação, ações em massa, botão “Novo”.
Lista: tabela ou lista com linhas clicáveis, estados (carregando/vazio/erro), seleção, paginação.
Detalhes: painel com header (título + status), seções internas, ações (editar, arquivar), histórico.
Essas partes podem existir juntas (layout com split view) ou separadas (lista leva para tela de detalhes). A composição deve permitir ambos.
Passo 2 — Padronize o “Item de lista” como unidade semântica
O item de lista é onde a inconsistência costuma nascer: cada tela inventa colunas, alinhamentos e ações. Em vez disso, componha um “Item de lista” com slots:
Identificador (nome + ícone opcional)
Metadados (ex.: data, categoria, responsável)
Status (badge/tag)
Ações rápidas (menu, botão)
Assim, você consegue montar listas diferentes trocando metadados e mantendo o mesmo esqueleto.
Passo 3 — Defina estados do padrão (não apenas do item)
O padrão “Lista + detalhes” precisa de estados claros:
Nenhum item selecionado: painel de detalhes mostra instrução (“Selecione um item”).
Carregando: skeleton na lista e no painel.
Erro: mensagem com ação de tentar novamente.
Vazio: explicação + CTA para criar o primeiro item.
Quando esses estados viram parte do padrão, o time não precisa redesenhar mensagens e layouts a cada tela nova.
Passo 4 — Crie um “kit de montagem” para novas telas
Em vez de entregar uma única tela pronta, entregue um conjunto de instâncias organizadas como kit:
Layout com split view
Layout com navegação para detalhes
Variações de densidade (compacta vs. confortável) se o produto usar isso
Exemplos com 3 tipos de conteúdo (curto, médio, longo) para testar truncamento e quebras
Esse kit vira a base para qualquer novo módulo do produto.
Como transformar padrões de fluxo em artefatos reutilizáveis (sem virar “template engessado”)
Use “blueprints” de fluxo com pontos de decisão
Um blueprint de fluxo é uma representação reutilizável da jornada, com etapas e bifurcações comuns. Ele não precisa ser um protótipo completo; pode ser um conjunto de frames com anotações e componentes compostos. O segredo é explicitar pontos de decisão: “se falhar verificação, mostrar etapa X”, “se usuário já tem endereço, pular etapa Y”.
Exemplo de blueprint para recuperação de conta:
Etapa 1: identificar usuário (email/telefone)
Etapa 2: verificar (código)
Etapa 3: redefinir credencial
Estados: reenvio, expiração, bloqueio temporário, suporte
Ao compor com componentes e seções padrão, você reduz o esforço de criar fluxos semelhantes (ex.: verificação de dispositivo, confirmação de pagamento, autenticação em duas etapas).
Crie “padrões de conteúdo” junto com padrões visuais
Fluxos falham quando o texto e as mensagens não são consistentes. Um padrão reutilizável deve incluir diretrizes de conteúdo: tom, estrutura de mensagens, formato de erro e instruções. Isso não significa escrever todas as cópias, mas definir moldes.
Exemplos de moldes:
Erro de validação: “Informe {campo} para continuar.”
Erro de servidor: “Não foi possível concluir agora. Tente novamente.” + ação “Tentar novamente”
Sucesso: “Pronto! {ação} concluída.” + próximo passo
Quando o padrão inclui o molde de conteúdo, a composição de telas fica mais coerente e o handoff para desenvolvimento e conteúdo fica mais direto.
Checklist de qualidade para componentes compostos e padrões de fluxo
Reutilização real (não teórica)
O padrão foi usado em pelo menos 2 fluxos diferentes sem duplicação?
As variações necessárias foram resolvidas por composição (slots) em vez de cópias?
Resiliência a conteúdo e dados
Funciona com textos longos e curtos?
Funciona com ausência de imagem, ausência de metadados e estados vazios?
Tem comportamento definido para carregamento e erro?
Clareza de uso
Existe uma regra simples dizendo quando usar este padrão e quando não usar?
Os slots estão claros (o que pode ser trocado sem quebrar a estrutura)?
Compatibilidade com implementação
As partes do padrão correspondem a “blocos” que fazem sentido no código (seções, containers, itens)?
As decisões de estado (vazio/erro/carregando) estão explícitas e reutilizáveis?
Exemplo prático completo: compondo um fluxo de checkout com padrões reutilizáveis
Imagine que você precisa desenhar um checkout para um produto digital. Em vez de criar telas do zero, você compõe a partir de padrões:
1) Estrutura do fluxo (blueprint)
Etapa A: Identificação
Etapa B: Pagamento
Etapa C: Revisão
Etapa D: Confirmação
2) Padrões de seção usados em cada etapa
Header de página: título da etapa + indicador de progresso (se aplicável) + ação “Voltar”.
Seção de formulário: dados pessoais e dados de pagamento.
Resumo lateral: itens, subtotal, descontos, total, mensagens de confiança.
Feedback geral: erro de pagamento, falha de conexão, validação de cupom.
3) Componentes compostos recorrentes
Item do carrinho: imagem + nome + variação + preço + ação remover.
Bloco de cupom: input + aplicar + estado aplicado + remover + erro.
Seleção de método de pagamento: lista de opções + campos condicionais + ajuda.
4) Estados do fluxo que viram padrão
Carregando total: skeleton do resumo e desabilitar ações.
Erro de pagamento: mensagem clara + instrução + alternativa (trocar método) + tentar novamente.
Confirmação: recibo + próximos passos + CTA secundário (ver detalhes).
O ganho aparece quando um novo produto pede “checkout com assinatura” ou “checkout com trial”: você reaproveita o blueprint, troca algumas seções (ex.: termos de assinatura) e mantém o esqueleto. Isso é composição aplicada a fluxos.
Como manter a biblioteca saudável conforme padrões crescem
Evite criar padrões duplicados com nomes diferentes
Quando duas squads criam “Card de resumo” e “Painel de resumo” com estruturas parecidas, a biblioteca fragmenta. Um mecanismo simples é manter um inventário de padrões por categoria de fluxo (cadastro, pagamento, gestão, comunicação) e revisar antes de criar algo novo.
Promova padrões a partir de uso recorrente
Nem tudo precisa nascer como padrão oficial. Uma prática eficiente é começar com uma composição local (em um arquivo de feature), validar em 1–2 entregas e, quando o padrão se repetir, promovê-lo para a biblioteca como componente composto ou kit de seção. Isso reduz o risco de “padronizar cedo demais”.
Documente decisões de composição com exemplos de “faça/não faça”
Padrões reutilizáveis falham quando as pessoas não sabem como adaptá-los. Inclua exemplos de uso correto e incorreto. Exemplo:
Faça: usar o padrão de “Seção de formulário” e inserir ajuda contextual no header.
Não faça: inserir mensagens de erro gerais entre campos, quebrando a leitura e a consistência.
Esse tipo de orientação reduz variações acidentais e melhora a consistência do produto.
// Modelo de checklist para promover um padrão a “oficial”
- Repetiu em 2+ fluxos ou módulos?
- Tem estados: carregando, vazio, erro, sucesso?
- Tem slots claros e limites de responsabilidade?
- Tem exemplos com conteúdo longo/curto?
- Tem regras de uso e anti-exemplos?
- Pode ser implementado como bloco reutilizável no front-end?
