Qual a relação entre Design System e Metodologias Ágeis?
Entenda porquê é importante usar o Agile na criação de um Design System
Artigo de conclusão do Curso Design System Boost da Pixelcast, que realizei com uma bolsa fruto da parceria com a PretUX.
No Curso Design System Boost, temos um módulo exclusivo sobre o tema de Agilidade, isso já mostra como esses temas estão relacionados e a importância dessa mentalidade ágil para construir e usufruir desse produto que é o Design System.
Contextualizando Design System
Como já muito discutido e difundido, um Design System se trata de um produto que serve outros produtos. Ele tem como objetivo tornar produtos de software escaláveis, auxiliando equipes a trabalharem de forma mais ágil e produtivas.
"Um Design System é um produto que serve outros produtos. Com decisões semânticas tomadas e disponíveis para uso tanto de designers quanto de desenvolvedores." Guilherme Gonzales (Design System Boost)
Justamente por ser um produto, nunca podemos dizer que o Design System está acabado, na verdade ele está constantemente passando pelas fases de estudo, teste, implementação e adoção de todo time. Além disso, precisa de atualizações e correções constantes conforme os resultados das análises das métricas e pesquisas realizadas com designers, desenvolvedores e demais utilizadoras do produto.
É interessante notar como a dupla designer + desenvolvedor complementam suas especialidades no processo de criação de um Design System: enquanto designer entende como a interface pode variar e cria uma linguagem visual que se adequa a todos (ou quase todos) os cenários e comportamento, desenvolvedor atua para implementar essa linguagem de forma consistente e flexível.
Design, Design System e Agile
Por terem elementos parecidos, por vezes as pessoas acabam se confundido, mas não se engane, criar um Design System não se trata apenas de organizar os arquivos de design com fontes, cores e ícones, mas sim de pensar em meios conectar diferentes disciplinas, envolvendo as áreas de tecnologia, negócios e quais outras forem necessárias, ou seja, todos os stakeholders importantes para esse produto chamado Design System, que tem o dever de ser útil para todas as frentes da empresa.
Design não é sobre beleza ou provocação, isso é arte. Design é sobre solucionar problemas de forma sistemática.
Um processo de criação e manutenção de Design System bem feito deve envolver, não somente as pessoas do time de Tecnologia como desenvolvedores, Product Manager, Tech Lead, Product Lead, entre outras, mas também o pessoal de outras áreas da empresa como branding, marketing e quem mais for consumir de alguma forma algum elemento que estará presente no Design System.
Uma das premissas para essa boa criação de um Design System é colocar todas as pessoas que irão usar a solução juntas desde a idealização até o dia a dia de sua produção, para haver uma análise constante da utilização, lembrando que o papel do Design System é deixar os produtos consistentes em todos as frentes.
O que o agile tem a ver com isso?
Como já citado, um dos objetivos de um Design System é auxiliar equipes a trabalharem de forma mais ágil, lembra?
Pois então, atualmente é muito comum times de desenvolvimento trabalharem usando metodologias ágeis, e times de design também já estão implementando essa mentalidade ágil em seus processos e trabalhando em parceria com desenvolvedores em times multidisciplinares.
E se você pensa que o Manifesto Ágil foi feito apenas para desenvolvedores, está cometendo um grande equívoco. Na verdade o manifesto foi criado para melhor a construção de produtos de software. Se você trabalha em startups ou com produto digital, você já trabalha criando produtos de software, e nesse caso é ainda mais importante conhecer e aplicar as metodologias ágeis!
O Manifesto Ágil foi criado com objetivo de melhorar o processo de criação de produtos, “descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.”
O manifesto ágil não é uma metodologia e apesar do nome “ágil”, na realidade não significa simplesmente entregar software mais rápido, muito pelo contrário!
São princípios que nos norteiam a desenvolver software com maior qualidade, entregas de valor e feedback frequente dos usuários.
Dividindo as entregas em etapas que geram valor ao usuário final, auxiliando o time a entender e prever possíveis erros e acertos ao longo do processo, dando tempo e disponibilidade ao time para ajustar a rota caso veja que algo está indo no caminho errado.
Porque usar agile na construção de um Design System?
Posso parecer repetitivo, mas, por definição Design System é um produto que tem o papel de solucionar os problemas dos times auxiliando produtos a serem escaláveis e equipes a trabalharem de forma mais ágil e produtiva.
Se um Design System se propõe a solucionar problemas por meio de um produto digital em constante desenvolvimento, nada mais natural que usemos o Manifesto Ágil para desenvolver esse produto.
“Design System não é um projeto, é um produto servindo outros produtos. Ele precisa de um MVP, um roadmap, atualizações e melhorias. Se possível até um time focado nele.” Nathan Curtis
Ser agil é diferente de ser rápido
Design System não é somente o styleguide ou os design tokens, ele envolve também liderança, alinhamento com stakeholders, processo de criação de interfaces, métricas de sucesso, entre outras demandas que um produto digital envolve.
É justamente nesse ponto que entram as metodologias ágeis, que servem para melhorar a comunicação, trazendo uma forma de trabalhar mais transparente, aberta para mudanças e reajustes, buscando sempre um entendimento e lembrando de que tudo é processo e precisa ser feito aos poucos, com análises, testes e ajustes constantes.
Ágil não pra ser feito de forma rápida, mas sim para saber priorizar o que realmente precisa ser feito e, o mais importante, saber também o que não precisa ser feito
No curso Design System Boost o instrutor Guilherme Gonzales lembra muito bem que “não existe Design System sem agilidade”, pois esse processo de criação exige uma equipe que saiba trabalhar com um produto em desenvolvimento, sempre contando com as mudanças de curso e que entende a importância das validações constantes com usuários, não para fazer rápido, mas para estar sempre atento ao que precisa ser mudado e poder tomar decisões de forma ágil.
