Jul 29, 2018
Aprendizados trabalhando em um Design System
Problemas enfrentados e soluções escolhidas na concepção de um design system pela primeira vez.
Se eu fosse escolher uma buzzword para 2018 com certeza seria Design System. Trabalhando com design de interface, você com certeza já ouviu falar nos benefícios que um bom design system pode atrelar ao seu produto digital em escala e ao workflow de toda a sua equipe. Por existir uma bibliografia limitada sobre o assunto, artigos aqui no Medium e alguns talks no Youtube são uma excelente fonte de estudo e análise.
Atuando como Product Designer em uma consultoria, tive o desafio de trabalhar no desenvolvimento de um Design System para um produto digital web e gostaria de compartilhar alguns aprendizados que tive durante esse processo.
Defendo que não existe receita de bolo. Contexto define (ou deveria SEMPRE definir) todas as escolhas e decisões de um produto digital. Porém, acredito que alguns pontos desse artigo podem ser de grande ajuda à jovens aspirantes trabalhando em um design system pela primeira vez.
É importante defender que, assim como em qualquer produto, uma solução que funciona para uma feature/produto/serviço X não necessariamente funcionará para uma outra feature/produto/serviço Y. Assim, copiar design systems de outros produtos e não compreender as reais necessidades do seu contexto é uma falha grave. Por isso, antes de tudo, valide o real valor de um design system atrelado ao seu produto e seu impacto em todo o processo de design e desenvolvimento.
Tags HTML como referência
Durante todo o processo na escolha, separação e categorização dos átomos, surgiram várias dúvidas em quais “fundamentos atômicos” (átomos, moléculas, organismos) os elementos seriam classificados. Labels de formulários que geralmente são utilizadas juntos às áreas de input de texto por exemplo causaram alguns questionamentos. Seguindo a risca o modelo de design atômico, decidimos prosseguir com a ideia: se é uma tag HTML (p, h1, h2, spam, label, input, etc.) é um átomo.
O projeto no qual eu trabalhei era voltado à uma plataforma web, então seguir com essa lógica de programação fez total sentido para todo o time. Todos esses átomos (e/ou tags HTML) foram mapeadas e categorizadas em símbolos e estilos escaláveis no Sketch (software utilizado por toda equipe de design e experiência do usuário).
Analisando esse problema em outro contexto, acredito ser relevante compreender com a ajuda de desenvolvedores como é feita a especificação de alguns elementos visuais em cenários mobile — iOS e Android por exemplo. Assim, acredito que ruídos no decorrer do projeto entre design e desenvolvimento sejam evitados.
Nomenclatura dos elementos
No decorrer da categorização dos elementos, encontrar um padrão de nomenclatura na qual designers e desenvolvedores pudessem ter a mesma abordagem e falar a mesma língua foi outro desafio. Tornou-se necessário mesclar a taxonomia compreendida por designers e a semântica do código HTML aplicada por desenvolvedores. Em uma decisão tomada junto com todo o time, escolhemos nomear os elementos em inglês, incluindo seu estado e variações. Por compreender que programação é basicamente escrita em língua inglesa, e o software utilizado por designers no cliente ser em inglês, fez total sentido para o projeto seguirmos com essa escolha.
Vitor Guerra tem um artigo muito bom sobre isso e utilizamos também como referência na tomada de decisão:
Nem tudo que reluz é ouro
Alguns elementos que são descritos como átomos seguindo a teoria de Design Atômico pelo Brad Frost e Dave Olsen mereceram algumas ressalvas. No decorrer do projeto, ficou vago especificar na biblioteca de elementos do Sketch alguns “átomos” como cor e tipografia. Conversando com Aurélio Jota em um meetup, ele me alertou sobre essa dificuldade e me indicou seu artigo aqui no Medium sobre o assunto.
Uma linguagem compartilhada
Durante um outro meetup sediado pelo pessoal do ProdutoSP na Meiuca Design sobre Design Systems, tive a oportunidade de conversar com front-end Paulo Giusti sobre o meu processo enquanto designer de conceber um design system do zero. Entre algumas dicas e posicionamentos, ele me falou algo que ficou bem marcado na minha cabeça e que fiz questão de lembrar o time todo o tempo:
Design system é uma linguagem compartilhada entre todas as partes de um produto — design, desenvolvimento, marketing, branding, etc.
Essa perspectiva me ajudou a lembrar que todo o trabalho no qual eu estava liderando iria ter impacto no produto em sua totalidade, interferindo inclusive no processo de trabalho de outros membros da equipe, como de estratégia e posicionamento do produto. Assim, priorizei ouvir e estar mais próximo de outros profissionais (designers e desenvolvedores) a fim de entender as dores passíveis de melhoria. Colaboração nesse momento tornou-se uma palavra de grande peso.
When the design language is shared knowledge, you can stop focusing on the patterns themselves and instead focus more on the user. — Alla Kholmatova
Seu trabalho é um organismo vivo
No decorrer do projeto, alguns átomos e moléculas foram descartados ou acrescentados à biblioteca de componentes (por até mais de uma vez e por repetidas vezes). Ter a compreensão (e porque não o desapego) que a biblioteca pode crescer e diminuir a qualquer momento é um mindset importante para você enquanto designer.
É válido ter em mente também quem será responsável pela adição de novos elementos e como esse processo será feito — se aberto à toda empresa, se restrito apenas à um designer ou a um time. Algumas perguntas nessa etapa devem ser feitas para evitar o excesso de elementos que tenham a mesma função ou apresentem uma certa semelhança visual. Assim, fica mais fácil manter uma consistência dentro de todo o produto.
Serviços de nuvem e Invision DSM
Por questões técnicas, decidimos testar uma nova ferramenta do Invision voltada para o gerenciamento de uma biblioteca de componentes, o Design System Manager. A ferramenta permite que você armazene, compartilhe e especifique elementos de um arquivo Sketch via plugin Craft para todo o time.
A forma como o Invision DSM organiza e disponibiliza o material entre computadores e membros da equipe é fantástica. A plataforma cria uma página web para visualização dos elementos e suas especificações. Porém, utilizar os elementos no processo de design soou cansativo e não natural. O DSM expõe os elementos em um pop-up dentro do Sketch e isso dificultou nosso workflow na ferramenta, já que estávamos acostumados à usar símbolos nativos da plataforma.
Porém, utilizamos o Sketch Cloud para manter a biblioteca atualizada para a equipe. Como inicialmente era minha a total responsabilidade pelo gerenciamento desses elementos/símbolos via Sketch, escolher e utilizar ferramentas de versionamento de arquivo como o Plant e o Abstract não fez tanto sentido. Qualquer alteração na biblioteca, o arquivo principal era atualizado via Sketch Cloud e todos da equipe tinham livre acesso e uso à biblioteca.
Biblioteca de elementos não é um design system
Quando fui realocado do projeto e passei a responsabilidade para outros profissionais do cliente, finalmente pude analisar que todo o trabalho que estava responsável e dedicado à fazer era nada mais que uma biblioteca de componentes visuais, e que por tanto não deveria ser chamado de design system.
Com certeza uma biblioteca de componentes compartilhada entre os times de design e desenvolvimento pode aumentar a produtividade da sua equipe e do seu produto como um todo, mas considero importante separarmos o feijão do trigo.
Segundo a autora do livro Design Systems — a practical guide to creating design languages for digital products — um livro que eu super recomendo –, Alla Kholmatova defende que um design system contém outros tipos de padrões que não apenas são voltados à interface, como userflows, tom de voz, estratégia e especificações de padrões de experiência (formulários que salvam e replicam informações, padrões de mensagem de erro, interações etc.) Portanto, uma biblioteca de componentes é uma parte integrante de um design system e não um design system por completo.
Espero que os problemas que enfrentei e as escolhas que fizemos te ajude a refletir qual melhor decisão se enquadra melhor dentro do contexto do seu projeto ou produto. Listo mais alguns links abaixo que possam te ajudar nessa tomada de decisão. Fique a vontade para perguntar ou pontuar algo nos comentários:
Atomic Sketch
An interdependent UI pattern library template based on Atomic Design
blog.usejournal.com
