Quais ferramentas de design estão erradas?

Designers têm mais ferramentas de design digital do que nunca. No entanto, alguns problemas-chave permanecem.

Ferramentas de design moderno – tanto o vetor quanto o tipo de código – são peças surpreendentes de software que nos últimos anos transformaram a profissão de design, mas nenhuma delas parece realmente entender o contexto para o qual projetamos atualmente. Os remanescentes de dimensões fixas ainda são visíveis, e as ferramentas não estão nos ajudando com as considerações e compensações que os designers precisam fazer em seu trabalho. Aqui estão alguns dos recursos que minha ferramenta de design ideal suportaria nativamente.

BIBLIOTECAS DE DESIGN DEVEM FUNCIONAR PARA DESIGNERS DE AGÊNCIAS

Bibliotecas em aplicativos como Sketch, Figma e Adobe XD funcionam bem para designers de produtos, mas muito menos para designers de agências.

Para entender por que, deixe-me explicar a diferença entre designers de produtos e agências. Designers de produtos são pessoas que trabalham em um único ou em alguns produtos que sua empresa cria. Pense na equipe de design do Airbnb ou mesmo em empresas como o próprio Sketch. Esses designers podem ter um único sistema de design ou guia de estilo do qual trabalham, com um único ou dois projetos construídos sobre esse sistema de design.

Os designers da agência, por outro lado, são os designers que trabalham em agências web, onde a qualquer momento eles podem estar trabalhando em projetos para meia dúzia de clientes, cada um com um sistema de design diferente ou guia de estilo e diferentes níveis de maturidade do design. Esses designers alternam entre os projetos com frequência e podem até mesmo entregar os ativos a um novo designer, dependendo do planejamento do projeto.

Para designers de produtos, a implementação atual de bibliotecas de design funciona bem. Eles podem ter apenas uma ou duas bibliotecas de projetos (Web e dispositivos móveis, por exemplo) que compartilham seu estilo geral. Como todas as bibliotecas de design estão disponíveis para todos os arquivos de design, isso funciona bem.

Os designers da agência, por outro lado, podem ter 10 ou 20 bibliotecas diferentes. Alguns serão projetos atuais, mas alguns serão projetos que eles terminaram recentemente, mas podem ter que trabalhar novamente em uma próxima revisão. Por causa disso, eles precisarão ser constantemente diligentes no uso de símbolos apenas do sistema de design correto ou devem ativar e desativar consistentemente as bibliotecas de design ao se movimentarem entre os projetos. Como você pode imaginar, esta não é uma experiência agradável.

Muitos designers de agências não usarão nenhuma biblioteca de design ou usarão bibliotecas genéricas de design, como as ferramentas UX Power, para dar suporte ao trabalho de design do sistema, o que leva a designs mais genéricos para seus clientes.

Acoplar bibliotecas de design a projetos específicos seria um primeiro passo para tornar as bibliotecas de projetos mais úteis para os designers de agências.

O outro problema é criar essas bibliotecas de design. Os designers da agência se beneficiariam muito com a disponibilidade de bibliotecas de design, mas nem todos os clientes as têm, e as agências geralmente não têm tempo ou orçamento para criar uma para cada projeto.

Como um designer de agência particularmente motivado, você pode criar uma biblioteca de design em conjunto com o design em que está trabalhando, mas a alternância contínua entre um arquivo de design da Web / móvel e um arquivo de sistema de design é incômoda. Ser capaz de “enviar componente para projetar biblioteca” enquanto você está projetando tornaria a criação de uma biblioteca de design uma atividade de atrito muito menor, tornando-a acessível a muito mais pessoas.

BIBLIOTECAS DE DESIGN DEVEM SE TORNAR BIBLIOTECAS DE TOKEN DE DESIGN

As bibliotecas de design também são limitadas no tipo de coisas que elas compartilham: apenas componentes ou símbolos. Isso funciona muito bem se todo o seu trabalho de design for apenas clicar em novas telas com os mesmos componentes, mas qualquer novidade verá designers clicando em componentes e copiando coisas como cores, variantes de fonte e verificando o espaçamento apenas para copiar isso em novos componentes. Quando você copia as coisas, invariavelmente você comete erros (afinal somos apenas humanos).

Se as bibliotecas de design oferecessem uma interface do usuário para escolher, bem como os símbolos fornecidos, a criação de novos componentes em seu design seria mais rápida e menos propensa a erros. O que me leva ao próximo ponto:

LIMITAR OPÇÕES PARA PROJETAR TOKENS

O problema mais importante da interface do usuário para isso é o seletor de cores. Por padrão, seu seletor de cores da ferramenta de design favorito permite escolher cores de todo o espectro RGB. O mesmo para fontes e o mesmo para espaçamento (um número literal infinito de opções lá). Isso coloca o ônus de manter a consistência totalmente no designer. Isso é loucura, porque os computadores estão longe, muito melhores nisso.

Minha ferramenta de design ideal começa com a definição dessas coisas como tokens de design e, em seguida, fornece essas e apenas essas como opções em potencial. Eu quero alternar entre as minhas duas fontes escolhidas, não percorrer as 2.000 que tenho instalado na minha máquina. Eu estou bem escolhendo entre nove gradações da cor primária, mas eu não quero checar, verificar e checar se estou usando # 042d3d em todo lugar e não # 042d3e.

Ao arrastar componentes ou elementos pelo meu quadro de arte, ele se encaixaria apenas nos valores que defini em uma escala de espaçamento. Ou melhor ainda, vamos garantir que sua ferramenta de design implemente um modelo de layout que faça isso para você (ferramentas de design baseadas em código mais modernas, como o Modulz, já fazem).

Isso vai um passo além do design linting , um processo para sinalizar possíveis problemas e uma ideia que é em si severamente subdesenvolvida. Embora o linting de design lhe diga que, depois do fato de algo estar errado, limitar seu design a opções definidas em tokens de design impedirá que você chegue ao “errado” em primeiro lugar.

SÍMBOLOS NÃO SÃO PODEROSOS O SUFICIENTE

Símbolos (ou quadros, ou componentes) foram ótimos para criar pacotes reutilizáveis ​​de design. Eles ainda não mapeiam bem as realidades do design web e móvel.

Por exemplo, um cabeçalho pode ser bem diferente entre móvel e computador: no celular, pode haver um botão de menu que abre um menu, enquanto na área de trabalho todo o menu fica visível. Apoiar ambos significaria ter dois símbolos para o que é, do ponto de vista semântico, a mesma coisa. Para fazer símbolos mapear bem para a realidade, eles precisam de três coisas:

• Variantes
• Estados
• Variantes responsivas

Variantes

Seu site pode ter alguns botões diferentes. Eles podem diferir apenas em cores ou preenchimento, ou alguns podem incluir um ícone e outros não. Todas essas variantes da mesma coisa idealmente viveriam em um único componente. Isso torna a atualização de suas propriedades compartilhadas mais fácil e, de fato, menos propensa a erros. Parte disso pode ser feito por meio de substituições ou por meio de alterações nas instâncias, mas isso só o leva até certo ponto.

Estados

A necessidade disso é mostrada mais facilmente com botões. Os botões têm alguns estados naturais: eles podem ficar ociosos, podem ser focalizados, podem estar ativos (pressionados ou clicados) e podem ser desativados. Estas são todas as instâncias do mesmo símbolo e devem ser tratadas como tal.

Variantes responsivas

Eu já mencionei a situação do cabeçalho acima. Meu símbolo ideal me permitiria definir diferentes designs e estilos, dependendo de quanto espaço disponível ele tem. Então, quando estou usando o símbolo, ele mudaria para a variante responsiva apropriada.

Como você pode ver, precisamos que os símbolos sejam editáveis ​​em algumas dimensões diferentes. Aplicativos como o Modulz e o UXPin estão bem encaminhados para isso, e espero que continuemos a nos aproximar da funcionalidade descrita acima.

GRADES SÃO INÚTEIS EM TODAS AS FERRAMENTAS DE DESIGN

O moderno design de interface do usuário para dispositivos móveis e web não pode contar com dimensões fixas, como o design de impressão pode. Por que, então, as grades nas ferramentas de projeto pressupõem que uma grade do canto superior esquerdo sempre será o que as pessoas querem? Ou um layout de largura fixa de colunas centralizadas?

O design para telas usa o alinhamento das bordas no centro ou a partir do centro. No entanto, nenhuma ferramenta de design que conheço permite definir grades como essa, dependendo de onde um elemento está posicionado, a grade é posicionada a partir de um canto ou posição diferente na tela.

Por exemplo, seu cabeçalho com um logotipo e um menu pode ser a largura total de sua viewport, e o logotipo seria 10 pixels da parte superior e 10 pixels da esquerda, com o menu alinhado à direita, novamente com margens de 10 pixels . O espaço entre esses dois elementos é completamente arbitrário, já que você não conhece a largura total do seu site quando está projetando. Isso significa que, se a sua grade funcionar no canto superior esquerdo, a navegação só será alinhada acidentalmente.

Uma ferramenta de design inteligente permitiria definir minha etapa de grade (como em 8 pontos) e fornecer feedback das bordas mais próximas e do centro vertical e horizontal.

OS PADRÕES DE ACESSIBILIDADE DEVEM SER ELABORADOS

É o trabalho de um designer levar todos os usuários em conta. Isso significa que eles precisam conhecer as diretrizes de acessibilidade e aplicá-las. Algumas dessas diretrizes de acessibilidade, como contraste de cores ou tamanhos mínimos de fonte, podem ser testadas por computadores. As ferramentas de design devem avisar ativamente os usuários quando suas cores de texto e de fundo não dão contraste suficiente, ou quando o tamanho da fonte escolhido é simplesmente muito pequeno para a tela em questão.

Para ser justo, essas coisas estão sendo implementadas lentamente em ferramentas de design. Ainda assim, para algo que é relativamente simples, é surpreendente que demorou tanto tempo para as ferramentas de design começarem a adotá-lo.

VERSÃO COMO CIDADÃO DE PRIMEIRA CLASSE

Existem várias ferramentas diferentes para versionamento, que permitem criar vários modelos do mesmo produto, como Avocode, Abstract e Plan. Todos eles precisam de algum tipo de ação manual para alterar a versão e mesclar. Na Figma já existem opções embutidas para versionamento e colaboração, e eu gostaria de ver isso se tornar o padrão. No meu mundo ideal, o controle de versão, a ramificação e a mesclagem seriam tão fáceis para o design quanto atualmente para o código.