Como escolher entre cards e listas no design de interfaces

Escolha cards quando a pessoa precisa reconhecer e explorar itens distintos. Escolha uma lista quando precisa percorrer atributos consistentes, localizar um item conhecido ou trabalhar em sequência. Se precisar comparar muitos valores entre registros, talvez uma tabela seja a escolha mais honesta.

Esse é um ponto de partida útil para escolher entre cards e listas em interfaces. Não é uma regra de que produtos com muitas imagens sempre precisem de cards ou aplicações de negócio sempre precisem de linhas. Uma mesma coleção pode atender a várias tarefas, e o melhor layout depende de qual delas a tela atual deve facilitar.

Considere uma biblioteca de projetos de sites. Um designer procurando uma direção visual pode reconhecer o projeto certo pela miniatura. Um gerente procurando uma revisão atrasada precisa de responsável, status e prazo. Eles estão olhando os mesmos dados, mas fazendo perguntas diferentes. Mudar o arredondamento do card não resolve essa diferença.

Identifique o que a pessoa procura

Comece com uma ação, não com um componente. “Explorar projetos” deixa coisas demais em aberto. “Encontrar um projeto cujo estilo visual combine com um cliente de hotelaria” e “Encontrar a revisão que vence hoje” dão prioridades informativas diferentes e uma maneira de avaliar o layout.

A primeira tarefa ganha com uma prévia reconhecível. Um título grande, sozinho, talvez não revele se o projeto usa fotografia, tipografia contida ou ilustrações coloridas. A segunda precisa de datas e status confiáveis em posições previsíveis. Uma miniatura decorativa pode ocupar espaço sem ajudar na decisão.

Anote a primeira pista que a pessoa provavelmente usará. Pode ser imagem, nome, categoria, responsável ou data. Depois identifique a segunda pista necessária para confirmar. Elas devem aparecer sem abrir o item. Se for preciso abrir todos os candidatos apenas para identificá-los, a visualização da coleção está fazendo pouco.

A discussão do Nielsen Norman Group sobre cards distingue a capacidade de agrupar conteúdo misto do percurso previsível de uma lista. Também observa que cards ocupam mais espaço e podem tornar a ordenação menos explícita. Use essas observações como custos a examinar, não como prova de que um padrão sempre vence. Nielsen Norman Group sobre cards de interface.

Pinterest e um exemplo de rastreamento ocular mostram custos diferentes

A interface do Pinterest documentada no artigo do NN/G agrupa imagens, títulos e informações de apoio em contêineres de alturas variadas. Isso combina com uma coleção em que a imagem é uma pista de reconhecimento e os itens têm quantidades diferentes de material. A captura abaixo registra aquela interface histórica.

O artigo também inclui uma sessão de rastreamento ocular em que uma pessoa procurava uma notícia interessante em cards. O traçado mostra movimentos repetidos entre candidatos. O NN/G relaciona esse comportamento a um layout sem sequência ordenada evidente e com posições inconsistentes para informações comparáveis.

Os exemplos expõem dois trabalhos diferentes. Se alguém escolhe uma imagem que parece certa, explorar faz parte da tarefa. Se um operador procura o registro atrasado mais recente, buscar a data em cada card repetidamente é esforço adicional. Chamar as duas atividades de “navegar” esconde a distinção que deveria determinar o layout.

Faça um teste de informação antes de um teste de estilo. Cubra as miniaturas da grade proposta. Se a tarefa principal ficar impossível, as imagens provavelmente carregam evidência necessária. Se ficar mais fácil porque datas e status passam a chamar atenção, elas talvez estejam competindo com o trabalho.

Decida o que deve aparecer antes de abrir um item

Para comparar as alternativas, use os mesmos registros, filtros e ações disponíveis. Peça a uma pessoa que encontre um item atrasado e a outra que reconheça uma direção visual, alternando qual layout aparece primeiro. Registre seleções erradas, visitas desnecessárias à página de detalhes e perda de posição ao voltar. Preferir a tela mais bonita é um feedback útil sobre aparência, mas não responde qual layout atende melhor à tarefa.

Leia o conteúdo antes de escolher o contêiner

Use uma amostra pequena de registros reais, inclusive os incômodos. Na biblioteca, podem ser título curto, título longo, miniatura ausente, projeto arquivado e projeto sem responsável. O conteúdo diz mais sobre o layout adequado que uma tela cheia de retângulos idênticos de exemplo.

Uma coleção com conteúdo muito variável pode ganhar com cards, porque cada item forma um resumo coerente. A repetição dos mesmos campos em todos os itens favorece uma lista. Nenhuma observação decide sozinha, mas ambas dizem o que o design precisa acomodar.

Preste atenção à falta de mídia. Se a maioria dos registros não tem imagem significativa, a grade costuma virar uma galeria de placeholders repetidos. O layout promete reconhecimento visual, enquanto o conteúdo entrega consulta textual. Considere uma lista centrada em texto ou miniaturas opcionais menores em vez de fabricar variação decorativa.

Por outro lado, uma lista que reduz um portfólio visual a nomes de arquivos pode retirar informações necessárias. “Project 14” e “Project 15” podem ser nomes corretos, mas pistas ruins de reconhecimento. Acrescentar uma prévia útil pode importar mais que aumentar o número de linhas na tela.

Exemplo: uma biblioteca, duas vistas iniciais

Imagine seis projetos fictícios: Cedar Lodge, Harbor Rooms, Studio North, Maple Clinic, Archive House e Lumen Shop. Cada registro tem miniatura, responsável, status de revisão e prazo de revisão. Nenhum desses campos muda quando muda a apresentação.

Para exploração visual, destaque a miniatura e coloque o nome logo abaixo. Adicione uma categoria breve e um status discreto. O responsável pode continuar visível com menor ênfase se ajudar a saber quem contatar. Não preencha o card com todos os metadados só porque os dados existem.

Para gerenciar revisões, comece com uma linha compacta. Coloque nome e talvez miniatura pequena no início, depois status e prazo em posições consistentes. Uma ação específica, como abrir a revisão, pode ficar visível. Uma descrição decorativa do estilo visual é menos útil nesse contexto.

As duas vistas não precisam mostrar exatamente os mesmos campos. Precisam descrever consistentemente os mesmos objetos. Se um status se chama “Pronto para revisão” numa e “Pendente” na outra, as pessoas podem suspeitar que trocar a visualização mudou o estado do projeto.

A vista inicial deve combinar com o propósito principal. Uma página de descoberta pode começar com cards. Uma fila de revisão pode começar com linhas. Oferecer alternância não dispensa um padrão sensato, pois muita gente usará a primeira apresentação encontrada.

Faça cada vista servir à tarefa

Cards: estabeleça uma ordem interna clara

Um card precisa de um percurso de leitura. Decida qual elemento identifica o item, qual o explica e qual inicia uma ação. Quando miniatura, título, selo, autor, lista de tags e botão exigem a mesma atenção, o card vira um pequeno painel de controle em vez de um resumo útil.

Na versão da biblioteca voltada à exploração, a miniatura e o título devem estabelecer a identidade. A categoria ajuda na interpretação. Status e responsável são informações de apoio. Você pode expressar essa ordem por meio de escala, peso visual, proximidade e contenção, sem introduzir uma cor diferente para cada campo.

Mantenha fatos comparáveis em posições comparáveis. Mesmo em exploração, pode ser necessário checar o mesmo detalhe em vários candidatos. Coloque status na mesma região e use um formato consistente. Uma descrição um pouco menor costuma ser compromisso melhor que deixar metadados importantes mudarem de posição imprevisivelmente.

Faça a imagem justificar o espaço que ocupa. Uma captura pequena demais para revelar o layout não é necessariamente mais útil do que nenhuma imagem. Recorte em torno de uma característica que identifique o item, use uma proporção estável quando for adequado e evite misturar recortes arbitrários que façam a grade parecer mais carregada que os próprios projetos.

A ausência de imagem deve ser um estado previsto. Use uma alternativa discreta que preserve a identidade pelo título e pela categoria. Não dê tanto destaque a essa alternativa que os registros sem imagem se tornem os itens mais chamativos da coleção.

Cards também precisam de limites, mas uma borda pesada e uma sombra profunda em cada item podem ser desnecessárias. O objetivo é associar as informações ao respectivo item. Deixe o espaçamento e um tratamento discreto de superfície fazerem esse trabalho antes de adicionar mais decoração. Revise a coleção inteira, pois um tratamento que funciona bem em um card pode se tornar repetitivo em vinte.

Listas: mantenha um percurso confiável

É fácil perder a vantagem de uma lista quando cada linha tem uma estrutura diferente. Mantenha o conteúdo identificador em uma posição estável e defina a ordem dos campos de apoio. A pessoa deve conseguir percorrer a coleção sem precisar reaprender a estrutura de cada linha.

Na fila de revisões, coloque o nome do projeto primeiro. Posicione o status da revisão e o prazo onde possam ser encontrados de forma consistente. Se a ordenação usar o prazo, mantenha essa data visível. Ordenar por um campo oculto faz o leitor procurar um padrão que não consegue ver.

Densidade é uma decisão sobre leitura e interação, e não uma disputa para colocar o maior número de registros numa tela. As linhas precisam de espaço suficiente para distinguir os nomes e usar os controles com conforto. Se o aumento de densidade fizer responsável e status se fundirem numa única linha cinza, os registros adicionais visíveis talvez não ajudem.

Use a segunda linha com intenção. Ela pode trazer uma descrição curta ou uma informação que diferencie registros, como o nome do workspace. Evite repetir o título com outras palavras. Numa biblioteca de projetos, “Projeto de site para Cedar Lodge” abaixo de “Site Cedar Lodge” acrescenta comprimento, mas pouco ajuda a identificar o item.

Listas podem incluir imagens. Uma miniatura pequena e significativa pode ajudar a reconhecer um registro, preservando a estrutura previsível da linha. A questão é se a imagem precisa dominar o item, e não se uma lista pode conter imagens.

Quando uma linha acumular vários campos alinhados que as pessoas comparam ativamente, considere se você desenhou uma tabela. Isso não é um fracasso. Uma tabela pode explicitar as relações com cabeçalhos e apoiar a comparação de forma mais direta. Chamar essa estrutura de lista não faz desaparecer as relações entre suas colunas.

Defina o clique antes de tornar tudo clicável

Um card pode abrir um item, mostrar um menu, incluir um controle de favoritos e exibir um link de categoria. Cada ação adicional complica a superfície. O designer precisa explicar o que acontece quando alguém seleciona a imagem, o título, o espaço vazio ou um controle secundário.

Use um destino principal claro. Se o título abre o projeto e a miniatura abre um visor, a diferença precisa de motivo e indicação compreensível. Senão, dois elementos visualmente ligados agem como links sem relação. O mesmo acontece em linhas cujo nome e fundo levam a telas diferentes.

O sistema de design do W3C documenta cards com links distintos e com link em toda a superfície, e lembra que níveis de título devem combinar com a página. Um card visual não impõe um único modelo de interação. Padrões de cards do W3C.

No exemplo, título com link e menu separado são um começo compreensível. Ao ampliar a área principal clicável, verifique que o menu continue independente e o texto possa ser selecionado quando necessário. Não aninhe links nem transforme cada fragmento em outra parada de teclado.

Selecionar difere de abrir. Escolher vários projetos exige seleção visível e uma forma clara de sair dela. Não faça o primeiro clique selecionar numa vista e abrir noutra sem mudança explícita de modo. A alternância deve mudar apresentação, não redefinir silenciosamente o comportamento básico.

Registre as expectativas de uso do teclado junto com o comportamento do ponteiro. Para onde vai o foco? Qual elemento abre o item? Como se chega ao menu secundário? Uma captura não responde a essas perguntas. Inclua-as na revisão da interação, em vez de presumir que uma hierarquia visual clara garante uma estrutura clara de controles.

Ofereça alternância só se ambas valerem a pena

A alternância entre cards e lista é valiosa quando o mesmo público realmente alterna entre reconhecimento e leitura sistemática dos campos. Ela acrescenta pouco quando uma visualização é apenas uma versão mais fraca da outra. Oferecer duas visualizações também dobra o número de estados de conteúdo e detalhes de interação que precisam de atenção.

Se incluir uma alternância, preserve os filtros, a ordenação e a coleção selecionada. Quem restringiu a biblioteca a projetos aguardando revisão não deve voltar a ver todos os projetos ao escolher a lista. A alternância muda a representação dos resultados, e não quais resultados satisfazem os critérios atuais.

Preserve a seleção quando fizer sentido e explicite qualquer limitação. Se as ações em lote existirem apenas na lista, explique isso em vez de descartar os itens selecionados sem aviso. Melhor ainda, considere se a ação pode continuar consistente nas duas apresentações.

Use um controle com rótulo e estado ativo visível. Ícones de grade e de linhas podem ajudar, mas sua forma, sozinha, não explica todos os layouts. Um rótulo curto, como “Cards” ou “Lista”, torna a escolha mais clara, especialmente quando os layouts ficam visualmente parecidos numa tela estreita.

Pense em quem volta. Lembrar a preferência pode ser útil no produto implementado, mas não deve sobrepor um contexto em que a tarefa muda. Fila de revisão e galeria pública não precisam necessariamente da mesma preferência global. Defina o escopo, em vez de deixar persistência virar comportamento acidental.

Preserve a tarefa numa tela estreita

Uma grade costuma se tornar uma coluna única no telefone. Isso não a transforma automaticamente numa lista útil. O card ainda pode dedicar a maior parte da tela a uma imagem, enquanto o campo necessário à tarefa permanece muito abaixo dela. Revise a hierarquia da informação depois que o layout mudar.

Na visualização de exploração, uma prévia generosa pode continuar adequada. Na fila de revisões, um resumo compacto com uma data legível pode ser mais útil. Não esconda o campo decisivo para a tarefa só porque ele estava na coluna mais à direita no desktop.

Permita que os campos secundários quebrem linha ou passem a uma segunda linha, numa ordem definida. Um status não deve virar um ponto colorido sem explicação apenas para economizar espaço. Se um campo precisar ficar atrás de um controle de expansão, decida se as pessoas ainda conseguem concluir a tarefa principal sem abrir todos os itens.

Nomes longos são especialmente reveladores. Use dois nomes realistas de projetos que comecem com as mesmas palavras e sejam diferentes perto do final. Se ambos forem cortados para o mesmo texto, o layout estreito perdeu a capacidade de identificar os registros. Ajuste a quebra de linha, a largura disponível ou o campo identificador visível antes de reduzir o tamanho da fonte.

Verifique a área de ações separadamente. Um botão de menu fácil de usar numa linha larga pode ficar apertado junto ao título ou à caixa de seleção. Um card com três controles pequenos pode ficar particularmente incômodo quando sua largura diminui. Retire as ações opcionais da superfície imediata quando isso simplificar a tarefa, preservando um caminho claro para acessá-las.

Compare lista e grade com buscas reais

Não pergunte apenas qual layout os revisores preferem. Dê uma tarefa com resposta observável. Na biblioteca de projetos, a exploração visual pode pedir um projeto com uma direção contida para hotelaria. A busca de um item conhecido pode pedir Archive House. A leitura administrativa pode pedir a revisão com a data mais próxima atribuída a uma pessoa específica.

Use conteúdo equivalente nos dois layouts. Se um deles tiver miniaturas melhores, textos mais curtos ou filtros mais úteis, você estará comparando mais do que o layout. Essas melhorias podem valer a pena, mas não devem ser confundidas com evidência de que cards ou listas são inerentemente melhores.

Observe onde as pessoas hesitam. Abrir itens repetidamente para descobrir um status que não aparece na coleção sugere um problema de conteúdo. Perder a posição ao voltar de um item sugere um problema de navegação. Pular a segunda fileira de uma grade pode sugerir um problema de sequência visual. Cada observação aponta para uma alteração diferente.

Inclua uma tarefa que desafie o design de sua preferência. Se você prefere cards, teste a busca por um campo que se repete em vários itens. Se prefere listas, teste o reconhecimento visual entre itens de nomes semelhantes. O propósito é expor o custo da escolha para decidir se ele é aceitável, e não coletar aprovação para a primeira proposta visual.

Você pode construir e revisar alternativas de layout HTML no OpenDesign, usar larguras predefinidas para inspecionar seu comportamento visual e anexar comentários a um card ou linha específicos. Mantenha os registros e os requisitos no contexto do design para que as alterações tenham uma base estável. Teste a busca, as preferências salvas e a persistência da seleção no fluxo implementado.