Mudança visual de quebra nos sistemas de design

Respeitamos as APIs de código. Mas e quanto à cor, tipo e espaço?

No 4 de 6 da série Releasing Design Systems:
Saídas | Cadência Versões Quebrando | Dependências Processo

Os sistemas de design estabelecem um estilo visual de linha de base que é uma dependência essencial. Essas opções - cor, tipografia, espaço e muito mais - são especificadas com robustez e espera-se que alterem de maneira estável e previsível o lançamento a lançamento. Quando um adotante atualiza, um sistema de design não deve quebrar suas coisas inesperadamente.

Então, pergunte-se ...

Os adotantes podem atualizar para uma versão secundária confiante de que a interface do usuário não será interrompida devido a alterações visuais do sistema?

O Semantic Versioning (SemVer) oferece critérios claros para comunicar as mudanças entre as versões, usando designações principais, secundárias e de patch. Todos os sistemas de design que encontro usam o SemVer e monitoram as alterações na interface de programação de aplicativos ou API de seus pacotes. Este é um território familiar para desenvolvedores que codificam adereços JavaScript e marcação HTML. Quebre sua API e sua próxima versão deve incrementar a versão para uma próxima versão principal, como 1.4.0 a 2.0.0.

A especificação de uma interface para o estilo visual composicional nos ilude. É muito difícil definir regras simples e claras para monitorar as mudanças de estilo. Os fabricantes de sistemas lutam para articular o que ou por que "Alterar esse estilo quebra a interface do usuário de um adotante" versus "Alterar esse estilo não". Poucas equipes do sistema documentam esses critérios. Pergunto: “Quais tipos específicos de alterações visuais acionam uma versão principal para você?” A resposta deles: ¯ \ _ (ツ) _ / ¯.

Neste artigo, proponho que pelo menos Cor, Tipografia e Espaço justifiquem critérios que constituam quebra de mudança. Existem outras propriedades a serem consideradas também. Um sistema de design pode definir, documentar e comunicar esses critérios para que os adotantes possam atualizar a liberação por liberação com confiança.

Breaking Color

A maioria das equipes de sistema se sente segura ao ajustar a cor de fundo de um botão principal. Talvez a motivação deles seja melhorar o contraste em relação a um rótulo de texto geralmente branco. "Vamos escurecer um pouco a cerceta", dizem eles. "Melhoraremos o contraste de cores acessível do botão de uma classificação AA para AAA".

Ajustando a cor de fundo de um botão principal

Certamente, a adoção de equipes não deve substituir a cor de um botão principal padrão. A substituição de uma opção do sistema rompe a conexão com um sistema. Nesse ponto, um adotante está por conta própria. Portanto, o ajuste da tonalidade da cor de fundo do botão principal é seguro e não é uma mudança de última hora.

No entanto, a mudança de cores em outros lugares pode colocar em risco os adotantes. Considere os seguintes cenários.

Exemplo: texto do sistema em fundos personalizados

Imagine uma equipe do sistema ajustando o azul interativo para melhorar o contraste das cores. O azul interativo da v1.4.0 estava acessível em um fundo branco, mas falhou no fundo do carvão vegetal.

Verificação de contraste de cores via contrast-grid.eightshapes.com

Portanto, para a v1.5.0, a equipe ajustou o azul interativo a um tom mais claro e saturado que funcionava tanto em branco quanto em carvão.

Ajustando a cor do texto de uma etiqueta de botão fantasma em fundos imprevisíveis

No entanto, um adotante havia usado o botão Ghost dependente dessa cor em um plano de fundo cinza claro. Após a alteração do sistema, o contraste da cor do texto da etiqueta fica inacessível. Seu sistema quebrou o produto deles.

Exemplo: Plano de fundo do sistema com texto sobreposto personalizado

Da mesma forma, imagine um sistema que escurece a cor de fundo do componente Cartão. A área de conteúdo do cartão inclui uma zona "segura" de contêiner de conteúdo, onde os usuários inserem o conteúdo e a marcação que desejam.

Ajustando a cor de fundo de um cartão que permite conteúdo personalizado contido

Nessa zona presumivelmente segura, um adotante adicionou um texto secundário que, embora sutil e moderado em cinza, passou no teste de contraste de cores. Após a alteração do sistema, o contraste da cor não fica mais acessível. Seu sistema quebrou o produto deles.

Imagine que a versão secundária do seu sistema incluísse esses ajustes. Compatível com versões anteriores, você disse? Não há risco na atualização, eles confiaram? Não! Seu sistema quebrou o produto deles!

Portanto, avalie as propriedades de cores alteradas para determinar se um sistema foi alterado, como:

  • Cor do texto que pode aparecer acima da cor de fundo, imagem ou outra textura de um adotante.
  • cor de fundo na qual a cor do texto de um adotante é sobreposta.
  • cor de fundo, cor da borda, cor do texto, sombra da caixa ou outra propriedade composta ao lado, acima ou abaixo da borda ou do conteúdo de outro componente, para diminuir o contraste entre os elementos.

A acessibilidade levou esses exemplos. Também há risco estético, pois mudanças bem-intencionadas do sistema podem atrapalhar a harmonia colorida alcançada por um designer de produto. As interações de cores são abundantes em toda a interface do usuário que um designer de sistema não controla ou tem visibilidade.

Resumo: comece a interromper a conversa sobre alterações com os critérios de cores. É mais fácil transmitir riscos, é objetivamente mensurável e está ligado à acessibilidade que desperta paixões. Armado com alguns critérios, você pode passar para outras preocupações.

Quebrando a tipografia (envolto)

A tipografia é uma faceta central de qualquer estilo visual. As equipes querem acertar as coisas. E há muitos mostradores para ajustar: família de fontes, peso da fonte, tamanho da fonte, transformação de texto, altura da linha, espaçamento entre letras e muito mais.

Nem todas as experiências correm o risco de quebrar se um sistema ajusta a tipografia. Para experiências com conteúdo intenso, o conteúdo de cada elemento pode ser imprevisível, de tamanho variável e projetado para quebrar e responder a alterações na largura da janela de exibição.

Para interfaces mais densas, a tipografia deve ser precisa. Os designers trabalham por horas afinando a tipografia, organizando etiquetas para caber em áreas compactas. Se você ajustar a tipografia do sistema, seus elementos poderão ser agrupados ou cortados de maneiras inesperadas.

Exemplo: guias de quebra automática são péssimas

Imagine que seu sistema ajusta o peso da guia de peso normal para negrito.

Após uma atualização de versão secundária, as guias que não respondem são quebradas. Não é bom.

Atualizações de um adotante. Suas guias sem resposta existentes excedem o espaço alocado e, portanto, são agrupadas. Medonho! Seu sistema quebrou o produto deles.

Exemplo: Mayhem de espaçamento entre letras

As diretrizes da marca evoluem, gerando nova hierarquia e estilo de cabeçalho. Assim, seu sistema se adapta aumentando o espaçamento entre letras de cada cabeçalho.

Um adotante atualiza seu aplicativo denso de radiologia de página única, traduzido para 14 idiomas, composto por inúmeros painéis de controle, cada um repleto de elementos e títulos de formulário. Eles são atualizados e a interface do usuário é inundada com títulos imprevisivelmente cortados. Eles convocam uma reunião de crise. Eles convidam os engenheiros de dados de back-end, pelo amor de Deus! Seu sistema quebrou o produto deles!

Ajustar a tipografia do sistema pode ser perigoso. Para você, é uma evolução tipográfica refrescante implantada sem esforço em uma biblioteca. Para eles, o texto começa a se comportar mal. Eles te culpam. Talvez eles chamem você no canal # Slack de design de sistema. Ninguém precisa disso.

Resumo: Antes da 1.0.0, trabalhe diligentemente para experimentar, refinar e finalizar estilos de tipo adequados à variedade do cliente. Depois que o 1.0.0 for aprovado, mantenha uma base estável e considere a mudança com cautela. Considere reservar turnos perigosos para a próxima versão principal. Até lá, adicione gradualmente recursos contidos, como um componente Texto de formulário longo para estilizar apenas a cópia do artigo.

Espaço e tamanho de ruptura

Pelo menos você pode ver cores e tipografia. Espaço e tamanho? Essas são mais difíceis de definir como concretamente reutilizáveis, e muito menos monitorar a quebra de mudanças.

Em HTML, quando você altera as propriedades do modelo de caixa de um componente - preenchimento, margem, largura, altura, exibição, tamanho da caixa, posição, esquerda, direita, topo, parte inferior - corre o risco de afetar a composição do layout que organiza esse componente com outros elementos da página.

Exemplo 1: Removendo o espaçamento vertical

Sua equipe do sistema decide remover os controles de formulário aplicados com espaçamento vertical na forma de margem inferior. Isso afeta ,