Documentar, seja o que for, em especialmente algo como um design system é uma tarefa extraordinariamente complexa. É uma tarefa fundamental, em particular quando falamos de sistemas de grandes organizações, com equipas dedicadas de manutenção e mais equipas ainda de produto a utilizarem o sistema. Mas, é uma tarefa que se pode tornar um buraco negro de recursos e que muitas vezes é difícil avaliar o seu retorno de investimento.
Como quase tudo em design em geral e design systems em particular uma leitura cuidada do contexto específico para o qual estamos a trabalhar pode ser meio caminho andando para simplificar o trabalho das equipas. As soluções que funcionam num determinado contexto, podem muito bem não funcionar noutros. Isto é uma verdade incontornável. É muito importante em cada caso, percebermos o negócio da empresa, os modelos de funcionamento das equipas, o grau de maturidade dos profissionais, entre muitos outras características essenciais para a aplicação de qualquer sistema.
Sem fórmulas pré-concebidas
Uma noção clara do contexto, das suas limitações e mais-valias é também um desafio para se contrariar os modelos tradicionais de construção e manutenção de um design system. Por exemplo, faz sentido que todo e qualquer design system tenha uma plataforma de documentação partilhada entre todas as equipas, certo? Errado! Nem sempre estas plataformas de documentação podem ser as melhores soluções para escalar a correcta aplicação dos sistemas nas organizações, independentemente da sua dimensão.
Uma das coisas mais importantes sobre estas plataformas de documentação é perceber, quem as vai utilizar e no que é que essa plataforma vai ser útil para a sua missão no dia a dia. Isto parece lógico, mas não raras vezes assistimos em muitas equipas a investimentos muito consideráveis na construção destas plataformas e depois a sua utilização é bastante residual.
Quando falamos destas plataformas de documentação, é muito importante perceber bem a quem se destinam, até para percebermos se é a altura certa para fazer este investimento. Por exemplo, se em determinado momento, apenas designers e developers estiverem a trabalhar com o design system, não faria mais sentido otimizar o workflow dentro das ferramentas que estes profissionais utilizam ao invés de investir numa plataforma de documentação para todas as equipas? Será que neste caso, uma plataforma de documentação centralizada, é a melhor forma de otimizar a aplicação do design system na organização?
O facto de vermos uma coisa como um padrão na indústria, não quer dizer que esse seja o passo que devemos dar num momento específico de evolução do nosso design system. É certo que muitas vezes medimos a qualidade de um design system pela qualidade da sua plataforma de documentação, mas é preciso ter cuidado com esta avaliação. O poder do sistema não está no show-off que é capaz de gerar, mas sim, no impacto que tem (ou não) nos indicadores de negócio das empresas.
Zeroheight ou Storybook?
Passada a discussão inicial do modelo de documentação que devemos adoptar e se uma plataforma de documentação vai ajudar nisso ou não, uma das dúvidas que mais vezes encontramos nas equipas é que ferramenta utilizar.
Dados do Mapa dos Design Systems em Portugal 2022 mostram que as equipas já chegaram à conclusão que é preferível utilizar ferramentas prontas do que criar a sua própria ferramenta. Dos dados do estudo, vemos que 41,3% utiliza como base para a sua documentação o Storybook e outros 35% utilizam o Zeroheight. Estas percentagens contrastam como os 7,8% de equipas que utilizam uma solução própria para a base de documentação do seu design system.
Contudo, olhando para as percentagens muito próximas de utilização do Zeroheight e do Storybook e conhecendo a realidade de várias equipas, vemos que muitas vezes persiste a dúvida se se deve utilizar uma ou outra e qual pode trazer maiores vantagens para o contexto específico da equipa.
A resposta a esta questão pode ter várias perspectivas. A primeira de todas é que depende. Por tudo aquilo que foi dito aqui sobre a importância do contexto, em determinados casos a solução pode não ser nenhuma destas duas ferramentas (e isso não tem problema absolutamente nenhum). Noutros casos, talvez a generalidade deles, a resposta a esta dúvida pode muito bem ser os dois, ao invés da opção de um ou outro.
Vantagens do Zeroheight
Antes de se escolher qualquer ferramenta é muito importante perceber bem as mais-valias que esta pode trazer à realidade da equipa. No caso do Zeroheight, isto quer dizer, conhecer bem o propósito da ferramenta para percebermos o que de melhor podemos tirar da sua utilização no nosso contexto.
O Zeroheight é uma ferramenta de documentação que permite centralizar numa única plataforma, (tipo wiki) toda a documentação relevante de um design system, facilitando a sua consulta por todas as pessoas da equipa de projecto. Sejam designers ou developers, passando por product owners ou qualquer outro tipo de profissional, pode ser o público alvo da base de documentação que as plataformas criadas com o Zeroheight podem disponibilizar.
Concretamente, o Zeroheight pode ter como mais-valias para a documentação dos design systems, as seguintes vantagens:
- Oferece uma curva de aprendizagem bastante pequena para qualquer tipo de utilizador na equipa de projecto.
- Permite a sincronicação com ficheiros de Figma o que facilita a utilização e atualização de diferentes elementos de desenho.
- Facilita a integração e visualização da componente de código (utilizando em articulação com o Storybook) de componentes.
- Disponibiliza várias ferramentas para a colaboração da equipa na documentação (versões de páginas, comentários, perfis de edição etc.).
- Oferece várias métricas que tornam possível perceber o tipo de consulta realizadas pelos utilizadores (pages views, user recordings, etc.).
Estas são só algumas das muitas vantagens do Zeroheight. Podes consultar todas as suas mais-valias no seu website. Aí podes também conhecer alguns casos de estudo da sua aplicação em diferentes design systems.
Vantagens do Storybook
Por outro lado, o Storybook não se pode dizer que seja uma ferramenta concorrente ao Zeroheight. A bem da verdade elas até são complementares. Ao contrário do Zeroheight, o Storybook destina-se quase em exclusivo às equipas de development. Resumindo bastante a explicação, a ferramenta permite dar visibilidade de forma interativa a qualquer pessoa da equipa, do desenvolvimento dos componentes em código do sistema.
O Storybook tem ainda uma outra especificidade muito interessante. Tudo o que é feito em código e que o Storybook dá visibilidade pode também ser integrado com a documentação disponibilizada em Zeroheight. Isto dá força ao argumento da complementaridade das ferramentas e não da lógica de dever ser ou uma ou outra.
Para facilitar a análise se o Storybook, em complemento com o Zeroheight ou não, pode ser uma boa opção, aqui ficam algumas das suas vantagens:
- Permite dar visibilidade a qualquer pessoa da equipa do desenvolvimento de código dos vários componentes do design system.
- Integra facilmente com a maior parte dos modelos e tecnologias utilizadas pela generalidade das equipas de desenvolvimento.
- Integra facilmente com a documentação disponibilizada em Zeroheight e mantém uma sincronização em tempo real.
- Democratiza os processos de teste porque permite o envolvimento de mais pessoas da equipa de projecto.
- Facilita a gestão dos diferentes componentes de UI e a sua distribuição pelas várias aplicações onde podem ser utilizados.
Se quiseres saber um pouco mais sobre o que o Storybook tem para oferecer, podes sempre consultar a sua documentação e também descobrir como algumas equipas o estão a utilizar no seu dia a dia.
Documentar para escalar
Documentar um design system não pode ser uma ferramenta para o ego. Não documentamos sistemas simplesmente para amplificar a imagem do nosso trabalho enquanto criadores e gestores de sistemas de design. Documentamos design systems, para tornar possível que outras pessoas na organização possam utilizar o sistema e usufruir realmente das suas mais-valias.
Isto pode querer dizer muitas coisas. No final do dia, quer também dizer, que ouvir quem é suposto utilizar o design system e perceber as suas reais necessidades é meio caminho andando para que o impacto do sistema seja real e palpável na organização. Afinal de contas é para isto que existem os design systems, não?
Fotografia © Panagiotis Nikoloutsopoulos (Unsplash)