Design

O que esta categoria cobre

Ferramentas para desenhar interfaces e os sistemas por trás delas: telas, componentes, variáveis, documentação e a entrega a quem constrói. Alguns produtos param no desenho, outros se estendem a protótipos, pesquisa e fluxo de conteúdo.

Fluxos clicáveis feitos para testar uma ideia ficam em prototipagem. Tudo o que visa saída de vídeo ou animação pertence a vídeo e gravação de tela.

A colaboração mudou o que essas ferramentas são

O software de design costumava ser um aplicativo individual que produzia arquivos. Hoje é, na maior parte, um espaço de trabalho compartilhado, e essa mudança decide qual produto serve a uma equipe.

A edição simultânea importa menos do que o tráfego ao redor: comentários que se resolvem, versões com histórico legível, links que sempre mostram o estado atual e permissões que deixam um cliente externo olhar sem quebrar nada.

Os produtos que funcionam primeiro no navegador ganham em acesso e perdem em trabalho offline e arquivos pesados. Os baseados em arquivos invertem os dois. Nenhum é melhor em geral, e a resposta depende de como a sua equipe realmente trabalha, e não de qual é mais novo.

Os sistemas de design são o produto de verdade

Passando de um punhado de telas, o valor sai dos desenhos e vai para o sistema por baixo deles.

Veja como os componentes lidam com variantes, estados, aninhamento e substituições, e depois quão penosa se torna uma atualização quando um componente aparece em duzentos lugares. Depois veja as variáveis ou tokens: cores, espaçamentos, raios e tamanhos de texto nomeados uma única vez, com modos para temas e densidades.

A ligação com o código é onde os sistemas mostram valor. Pergunte se os tokens podem ser exportados num formato que um build consiga consumir e se os nomes dos componentes no arquivo correspondem aos do repositório. Quando os dois se afastam, todo mundo deixa de confiar no arquivo e passa a perguntar diretamente ao designer.

A documentação merece um lugar no mesmo espaço de trabalho. Um sistema sem regras escritas vira quarenta variantes do mesmo botão em um ano.

Entrega e o que os desenvolvedores realmente precisam

• Medidas e espaçamentos legíveis sem abrir uma licença de editor.
• Tokens nomeados em vez de valores hexadecimais colados num ticket.
• Recursos gráficos exportáveis nas escalas e nos formatos certos, inclusive o que a sua plataforma exigir.
• Estados para vazio, carregando, erro e conteúdo longo, que é onde os designs costumam falhar.
• Um link atual, para que ninguém construa a partir de uma captura de tela colada no chat no mês passado.

Esse quinto ponto causa mais retrabalho do que qualquer recurso ausente. Seja qual for a ferramenta escolhida, a verdade compartilhada precisa estar num só lugar ao alcance de todos.

Arquivos, desempenho e as restrições chatas

Os arquivos grandes são onde esses produtos se separam. Um documento com centenas de quadros, imagens incorporadas, componentes aninhados e uma década de histórico mostra a diferença entre uma ferramenta rápida e uma lenta em um minuto.

Confira a profundidade do histórico de versões, já que os planos de entrada costumam guardar uma janela curta e as decisões de design são discutidas meses depois. Confira a disponibilidade de plugins se o seu fluxo depende de um. Confira o que acontece com os links compartilhados quando um plano expira.

Licenças, visualizadores e o que uma equipe realmente custa

O preço é por editor em quase todo lugar. Quem comenta e quem visualiza é gratuito ou muito mais barato. Essa estrutura recompensa decidir quem realmente edita.

Desenvolvedores, gerentes de produto, executivos e clientes geralmente precisam ler e comentar, não desenhar. Comprar para eles licenças completas é a forma padrão de esta categoria custar o dobro do que deveria.

Observe também as fronteiras entre planos: bibliotecas compartilhadas, ramificações, login único e permissões avançadas tendem a ficar acima do nível de entrada, e um deles costuma ser o motivo pelo qual uma equipe em crescimento faz upgrade. Padrões semelhantes no mercado estão expostos em o que as páginas de preços escondem.

Antes de se comprometer, leve um projeto real para dentro. Não um arquivo de exemplo, mas um ao vivo, com camadas bagunçadas e um cliente que comenta no lugar errado.

Trabalhar com quem não faz design

A maior parte do atrito nesta categoria vem das pessoas ao redor da equipe de design, e não da ferramenta.

Os desenvolvedores precisam de medidas, tokens e um link atualizado. Os gerentes de produto precisam comentar sem quebrar nada. Os executivos precisam de uma imagem, não de um arquivo com quarenta pranchetas.

Monte isso de propósito. Uma única página por projeto com as telas atuais, mantendo a exploração em outro lugar, evita a pergunta recorrente sobre qual versão é a real.

A mesma disciplina vale para os nomes. Arquivos chamados final, final dois e final aprovado são sintoma de uma convenção ausente, e nenhum produto resolve isso. Combine para onde o link compartilhado aponta e mantenha todo o resto fora do caminho de quem não está procurando por ele.