É realmente um sistema de design?
Nos últimos 15 meses, tenho trabalhado com minha equipe no Sistema de Design de nossa empresa. Somos uma equipe pequena com 3 designers e 9 desenvolvedores front-end e absolutamente nenhum de nós está trabalhando nisso em tempo integral. Ainda é um assunto muito importante e sobre o qual discutimos “apaixonadamente” durante todo o ano.
Muitos desses debates apresentaram variações da mesma linha: “este não é um sistema de design”. Freqüentemente, temos que reavaliar se o que está sendo sugerido ou o que foi construído é “digno” de um Sistema de design.
Por quê? Estamos todos trabalhando com diferentes definições do que é um Sistema de Design? Nós não deveriamos. Mesmo se não tivéssemos detalhado totalmente nossas necessidades desde o início (o que eu juro que fizemos), existem muitas definições convergentes por aí. A noção de um Sistema de design não é tão nova ou complicada, não é?
Então, vamos trabalhar para trás. O que estamos construindo quando não estamos construindo um Sistema de design? Além disso, não há problema em não construir um?
Falando a mesma língua: do que estamos falando?
Uma das definições mais completas de um Sistema de Design é cortesia de Nathan Curtis da EightShapes , uma empresa criada para alimentar esses sistemas.
A definição de Curtis decompõe um Sistema de design em grandes caixas de seleção.
Primeiro, ele diz que um Sistema de design quase sempre “oferece uma biblioteca de estilo visual e componentes documentados e lançados como código reutilizável para desenvolvedores e / ou ferramenta (s) para designers”.
Essa definição abre a porta para um sistema feito exclusivamente para designers ou desenvolvedores. Uma coleção totalmente documentada de componentes do Figma (ou sua ferramenta de escolha) é tanto um sistema de design quanto uma combinação totalmente documentada de componentes correspondentes do Figma e do React (ou sua ferramenta de escolha).
Esses dois escopos de entrega e produção são totalmente diferentes. Por quê? Qual nós escolhemos?
Entra na caixa de seleção número dois: os clientes do sistema. Quem usará o Sistema de design e quais são suas necessidades? É possível que os consumidores do Sistema de design sejam apenas designers ou desenvolvedores, mas não ambos. O escopo da entrega mudaria de acordo.
Agora podemos definir o que precisamos e para quem precisamos, fica uma última caixa de seleção: como? A definição de Curtis não é sobre os detalhes minuciosos de como a salsicha é feita, é mais sobre quem a faz: “um sistema de design é feito por um indivíduo, equipe e / ou comunidade. Enquanto alguns surgem menos formalmente, as organizações agora se dedicam esquadrões pequenos a grandes para desenvolver e lançar versões e processos do sistema ao longo do tempo. ”
Isso coloca o sistema de design diante da verdadeira questão: a empresa pode arcar com o custo de ter uma equipe para organizar, possuir e impulsionar esse produto interno? A resposta informa diretamente o escopo da saída possível.
Portanto, essas são as caixas de seleção com as quais trabalharemos. Curtis elegantemente os resume em uma definição de pitch de elevador:
Quase sempre, um sistema de design oferece uma biblioteca de estilo visual e componentes documentados e lançados como código reutilizável para desenvolvedores e / ou ferramenta (s) para designers. Um sistema também pode oferecer orientação sobre acessibilidade, layout de página e editorial e, com menos frequência, branding, viz de dados, padrões de UX e outras ferramentas.
Um sistema de design é adotado e apoiado por outras equipes que estão fazendo experiências. Essas equipes o usam para desenvolver e enviar recursos com mais eficiência para formar uma jornada do cliente mais coesa.
Um sistema de design é feito por um indivíduo, equipe e / ou comunidade. Embora alguns surjam menos formalmente, as organizações agora dedicam grupos pequenos a grandes para desenvolver e lançar versões e processos do sistema ao longo do tempo.
Quando não estamos construindo um sistema de design?
Deixando de fora parte dos clientes
Vamos voltar ao caminho de ramificação. Ele diz que um Sistema de Design pode ser uma coleção de códigos e componentes de design ou exclusivamente um deles. Minha equipe teve uma experiência anterior em que nossos designers tinham seus próprios componentes de design, os desenvolvedores sua biblioteca de IU e nenhum dos dois estavam alinhados. Essa situação nos deixou com uma longa lista de problemas e inconsistências, de modo que essa ramificação nos deixou muito desconfortáveis. Descreve precisamente o que queremos evitar.
No entanto, como vimos, essa primeira parte da definição funciona em conjunto com a noção de clientes.
Em uma empresa onde designers e desenvolvedores trabalham para a mesma carga útil eventual, ambos são clientes do Design System. Suas necessidades são fundamentalmente as mesmas: ambas as profissões desejam um produto homogeneizado, acessível e construído de forma eficiente. Não somos duas equipes trabalhando uma para a outra, mas uma equipe construindo coletivamente a IU de nossos aplicativos.
É por isso que o caminho de ramificação parecia errado. Não podemos fazer a “ou” parte do “código reutilizável para desenvolvedores e / ou ferramenta (s) para designers”, precisamos de ambos ou então comprometeríamos seriamente essa unicidade de propósito. Precisamos falar a mesma língua porque, eventualmente, estamos construindo a mesma coisa.
Com isso, vem nossa primeira pista para avaliar quando não estamos mais construindo um sistema de design.
Tem que ser um nexo para todas as equipes de produção presentes no fluxo de trabalho da empresa. Se designers e desenvolvedores não estão seguindo as mesmas regras ou não estão na mesma linha quanto aos objetivos, então provavelmente não é um Sistema de Design no futuro. Pode ser um UI Kit e uma UI Library (ou dois sistemas separados), ambos vagamente parecidos, mas não em sincronia. Uma parte acabará “mentindo” para a outra. Os designers terão uma ideia do produto, mas os desenvolvedores o construirão à sua maneira.
Se esta divisão estiver OK para você, você não está construindo um Sistema de Design. Provavelmente, você está construindo uma biblioteca de IU isolada.
Deixando as coisas abertas para interpretação
Tudo o que você lê sobre Sistemas de Design gira em torno de documentação. Definição Curtis’ apresenta-lo ( ‘biblioteca de estilos visuais e componentes documentado e lançou’), mas você pode olhar para qualquer dos populares sistema de design lá fora, você vai ver que eles não pular nas diretrizes e documentos completos.
Isso tem um propósito crucial. Imagine que você projetou um componente de botão. Você fez bem o seu trabalho, cada estado interativo é detalhado, você forneceu diferentes comprimentos e tipos de conteúdo para mostrar o comportamento do componente. Ele é escolhido pelos desenvolvedores e transformado em um componente da web.
No começo está tudo bem. No playground (como um Storybook) onde o novo componente é exibido, ele parece e se comporta exatamente como no software de design.
Mas então ele deve ser usado dentro do aplicativo. Como deve se comportar quando colocado ao lado da cópia, por exemplo? A cópia é quebrada ou o conteúdo dentro do botão é quebrado quando o espaço se torna limitado? Além disso, o que acontece quando preciso de mais de um botão no mesmo local? Você pode oferecer variantes então, um botão “Secundário” ou mesmo “Terciário”, mas então você recebe ainda mais perguntas: quando se deve usar Secundário ou Terciário? Posso usar o Terciário sozinho porque gosto de como fica um pouco melhor aqui? Além disso, posso apenas fazer o primário e ir direto para o terciário?
Com cada componente, vem uma longa lista de possibilidades e com eles uma longa lista de opções. Quanto mais fina for a documentação, maior se torna o local para interpretação, seja de outros designers ou de desenvolvedores. Isso vem em oposição direta à declaração de missão de “desenvolver e enviar recursos com mais eficiência para formar uma jornada do cliente mais coesa”. Qualquer interpretação é um risco para a coesão do produto como um todo.
Também é muito menos eficiente: para cada novo componente, a equipe de design terá um fluxo interminável de perguntas e respostas dos desenvolvedores que tentarão garantir que as respostas sejam construídas como código. Porém, mais tarde, outro designer que não tem ideia de que esses limites existem pode usar o mesmo componente e quebrar essas regras implícitas. O componente codificado não é capaz de se ajustar ao design solicitado e o vaivém começa novamente.
A documentação e as diretrizes existem para evitar isso. Teoricamente, pode-se “aprender” seu Sistema de Design e construir qualquer recurso simplesmente aplicando-o e sem prejudicar a homogeneidade do produto. Se você remover o documento, o que há para aprender? São apenas componentes e escolhas individuais a serem feitas.
Se estiver tudo bem para você, você não está construindo um Sistema de Design. Provavelmente, você está construindo um kit de interface do usuário que divide.
Iniciativas que prejudicam o sistema
A definição com a qual estamos trabalhando gira muito em torno de pessoas que usam o sistema de design. Vamos discutir primeiro a última parte, sobre ter um esquadrão trabalhando no sistema. Isso é importante para a propriedade, permitindo que as equipes se movam rapidamente de acordo com um caminho claro. É mais fácil estabelecer uma trilha como uma equipe identificada, em vez de precisar questionar tudo como um grande comitê a cada passo. Também é importante porque ter proprietários para o sistema de design significa que eles “incorporam” esse projeto interno.
Na engenharia de software, estamos acostumados a ter equipes lidando com artefatos para outras equipes. Já fazemos isso com as “equipes de infraestrutura” por trás da plataforma em que outras equipes executam seus serviços ou com as “equipes de controle de qualidade” focadas em testar pipelines e ferramentas necessárias para outras equipes, etc …
Por que isso se aplica aqui? Bem, agora estamos retornando à segunda parte da definição: adoção, suporte e uso pelos consumidores que criam produtos. Esses consumidores (nossos colegas) também contribuem: eles estão mais próximos dos produtos e estão perfeitamente cientes dos requisitos técnicos, entre outras necessidades. A comunicação e a contribuição deles são essenciais para a maioria das empresas. Ter uma equipe central identificada como líder do Sistema permite que todas as outras equipes adiem e centralizem a maior parte do tédio de construir coletivamente um produto para toda a empresa.
Esse é o plano de qualquer maneira. Mas o que acontece quando os desenvolvedores ou designers não assinam o Sistema?
Digamos que, como desenvolvedor, você não queira participar do esforço coletivo necessário para construir um componente que atenderá não apenas às suas necessidades, mas também às necessidades de outra equipe de recursos. Você codificará um componente de uso único fora do escopo do sistema de design. Parece fácil, mas a outra equipe pode fazer exatamente o mesmo. Agora que os designers analisam os dois recursos e veem dois componentes que parecem se comportar da mesma forma, eles têm todo o direito de pensar que esse componente pode ser usado com segurança em escala. Afinal, é genérico para eles, por que não seria para desenvolvedores?
Ao escolher não usar o sistema de design, o desenvolvedor criou uma brecha no contrato básico de um DS. Funciona exatamente da mesma maneira quando os designers tentam fugir do sistema de design.
Você está encarregado de projetar um novo recurso, mas o Design System não parece fornecer exatamente o que você precisa. Você acha que um pouco mais de margem funcionaria melhor ou talvez prefira usar um botão Secundário sem ter um Principal. A tentação de quebrar as regras pré-existentes do sistema de design (ou nunca defini-las) aumenta, mas o contrato seria perdido e a equipe de desenvolvimento não conseguiria cumprir sem atrito.
Se o sistema de design não fornecer o que o designer precisa, talvez o DS não esteja equipado adequadamente e seja necessário trabalho adicional, o que é bom. Peça isso à equipe do sistema de design. É um processo dinâmico e iterativo. A questão é que não é algo que se faz em meio-passos. Ou você constrói o produto com o sistema de design ou não. Se você consistentemente não, especialmente quando poderia, por que existe um Sistema de Design? Toda a estrutura desaba. Não há mais clientes e também não há uso para uma equipe de produção.
Se você está OK em minar seu Sistema de Design, você não está construindo um Sistema de Design. Você pode estar destruindo-o ativamente.
Quando não vale a pena construir um sistema de design?
Como vimos, a definição do que é um Sistema de Design leva em consideração mais do que a entrega. Quem são seus clientes e o que procuram define claramente mais do que o tipo de componente que documenta.
Com isso em mente, pode haver situações em que investir em um sistema de design pode ser um custo muito alto. Como um produto interno, o valor do sistema de design só vale o que seus clientes dizem que vale. Se suas equipes não estão interessadas na criação colaborativa, na curadoria da única fonte da verdade, em metodologias sistemáticas … então o custo de adoção pode ser muito alto para eles pagarem.
Sua organização também pode recusar a ideia de mudar seu pipeline de produção de um modelo “do zero” para uma abordagem de “sistema primeiro” (e, eventualmente, “sistema apenas”). O primeiro tem um ar de total criatividade e potencial ilimitado. É também a razão pela qual muitos produtos têm “camadas” visíveis onde você pode ver as mudanças repentinas nas direções do design. Você pode até encontrar dois botões que parecem iguais, mas não têm os mesmos estilos quando focados. O próprio Airbnb teve isso acontecendo por um tempo.
Este último implica em muito mais trabalho de documentação. Muitas vezes é erroneamente visto como uma simples caixa de peças de Lego, prontas para serem usadas. É decididamente mais do que isso: são os blocos de Lego e o folheto detalhado e cuidadosamente feito que vem com o kit que você comprou. São os tijolos e a maneira de usá-los. São os tijolos, e não o lápis mágico, que farão qualquer tijolo parecer o que qualquer um quiser a qualquer momento. É o tijolo e o vínculo legal que ninguém deve fazer o que quer que seja com os tijolos ou a empresa Lego vai processar. É o tijolo, a equipe que constrói o tijolo e a (s) outra (s) equipe (s) que usa o tijolo e a comunicação entre todos.
Aderir a essa mentalidade leva tempo. É um investimento, tanto nos talentos que exigirá quanto nos métodos que ditará. Se eles valem o tempo de sua equipe (e o dinheiro da empresa) depende do que você (como empresa, equipe de designers e / ou desenvolvedores) está tentando alcançar. Se a coesão e a rápida industrialização das melhores práticas não estiverem no topo de sua lista de objetivos, talvez você não esteja no mercado.
Mas talvez você deva.
Você pode construir um sistema de design
Se há apenas uma coisa a lembrar sobre tudo isso, é que um Sistema de Design é uma metodologia antes de ser um produto final. Seus objetivos são sempre os mesmos: fornecer elementos de interface do usuário homogeneizados e de alta qualidade em escala aos consumidores que os usam para construir produtos.
Para conseguir isso, você pode tentar continuar fazendo o que todos nós temos feito desde sempre: dividir suas equipes de design e desenvolvimento e trabalhar como se uma estivesse construindo para a outra. Provavelmente, ao fazer as coisas que sempre fizemos, você terá os mesmos problemas que sempre tivemos.
A ideia é passar dessa troca isolada de “nós” e “eles” para uma troca de “necessidades” e “meios”. As necessidades são as mesmas para ambas as profissões. Os meios devem, portanto, estar alinhados.
Tem um preço, como a maioria das mudanças. A necessidade de uma equipe motriz central não é motivo de escárnio. Talvez essa equipe não precise se dedicar ao sistema de design em tempo integral no início? Lembre-se de que nada precisa ser um big bang. Não tenha pressa. Identifique suas prioridades, certifique-se de que todos estejam a bordo ou prontos para embarcar. Documente como um sistema de design teria ajudado a resolver problemas recorrentes.
Um Sistema de Design não é necessariamente a solução para todos os seus problemas, mas quando ele resolve a maioria deles, permanecer fiel a seus princípios é a melhor maneira de evitar cair novamente no mesmo poço. É fundamental não nos fazermos acreditar que estamos construindo um quando, no final das contas, estamos apenas colocando o rótulo em um conjunto de regras diferente.
As ilustrações são uma cortesia de Greg Dlubacz no Whoooa .
