Bom dia pessoal. Tudo bem? Meu nome é Guilherme Hashioka. Eu sou Desenvolvedor Front-end aqui na Taqtile e hoje eu vou falar sobre Style Guides. Por que ele existe, o que ele é, e como que a gente faz ele aqui na Taqtile. Bom, primeiro então dando contexto sobre porque ele existe, quando a gente vai criar produto digital tem uma série de coisas a serem consideradas. Primeiro a gente quer entender qual o problema que a gente quer resolver. Depois disso a gente vai entender Quem é usuário, qual é a jornada que o usuário faz com o produto, qual é a experiência que a gente quer fornecer. E aà isso vai envolver então construir uma identidade visual para o produto, entender qual a personalidade que ele vai ter, o tom de voz. Enfim, como vocês estão vendo é uma série de questões a serem consideradas. E por que eu estou dizendo isso? Porque daà chega a pergunta final, que é como a gente vai fazer o design finalmente do nosso produto, envolvendo todas essas questões. Então a pergunta seria como podemos fazer o design de todo o sistema de modo organizado? E o que eu quero dizer com organizado? O primeiro ponto é que você pode não estar sozinho. Então a sua equipe pode ter vários designers. O desafio é o seguinte, como que a gente faz para que o usuário tenha a percepção que o produto é o mesmo, independente da parte que ele esteja vendo? Como que a gente faz para manter a consistência? Porque se não vai parecer que o seu produto tem distúrbio de personalidade, cada hora ele está de jeito, enfim, feito de alguma forma, e isso impacta no usuário final. O segundo desafio é que design não é tudo. No desenvolvimento de produto digital existem diversas equipes, com diversos tipos de disciplina envolvidas. E aà a pergunta que fica é como que a gente faz para sincronizar tudo isso, como que uma equipe faz para se comunicar com a outra? Aqui no caso a gente tem desafio. Tem os designers que vão desenhar as telas e os componentes, e depois tem os Engenheiros da Computação que vão desenvolver propriamente o produto. E aà nessa questão, enfim, como é feita essa comunicação? O terceiro desafio é a produtividade. Então os últimos dois pontos que eu comentei, eles estão relacionados à qualidade do produto, só que se você não acertar esse ponto da comunicação, o produto além de com má qualidade pode sair mais lento. Então a questão principal é que a falta de organização e comunicação, ela causa retrabalho e a gente quer evitar isso no projeto final. E por último é considerar que o projeto pode ser grande e durar vários anos. Quando a gente está falando de produtos digitais, ele tem uma diferença em relação aos produtos normais que a gente vê no dia a dia, porque ele não é estático. Enfim, ele é dinâmico e isso quer dizer que ele vai sendo implementado a cada tempo, ele vai sendo evoluÃdo. E a grande questão para a gente é como é que a gente faz para desenvolver o produto, sendo que ele não perca a identidade dele? Então eu falei diversos problemas aqui, mas a grande questão é como manter a consistência? Essa é a palavra chave, é a consistência do produto. Então todos aqueles problemas no final é isso, a gente precisa fazer com que o produto seja consistente. Enfim, a solução para isso é a utilização do Style Guides, que é o tema da aula de hoje. Então vamos começar e dizer o que é o Style Guides. O Style Guides é documento visual que vai dizer quais são as regras e padrões a serem seguidos no projeto. Lembrando das aulas anteriores, que a gente viu o que é atomic design, é nele que vai ficar bem classificado quais são os átomos, moléculas, organismos e etc. Enfim, só para dar um contexto maior, na verdade se vocês quiserem ir mais longe do que é Style Guides,ele está inserido contexto muito maior que é o de design systems. Então fica um tema aÃ. Hoje a gente vai abordar só o Style Guides mas nessa ideia de organização e comunicação do time você pode ir mais longe, que é a questão do design systems. E agora vamos para a terceira parte, que é dizer como que a gente faz aqui na Taqtile. Existem diversas formas de fazer esse documento visual que diz as regras e padrões do seu projeto e eu vou só mostrar como é feito aqui. Aqui tem um exemplo do documento, eu vou dando zoom em cada parte dele. A primeira parte seria a parte das cores. Então aqui a gente diz quais são as cores que a gente vai usar no nosso sistema. Em geral tem a ver com as cores da marca, quais são os tons de cinza, qual é a hierarquia entre as cores. Em segundo vem a parte da tipografia. Nela a gente vai dizer quais são as fontes a serem utilizadas, quais são os tamanhos, quais são os pesos. Então você vai vendo que a gente vai construindo aqui exatamente aquela questão das regras e padrões a serem usados no sistema. Uma terceira parte diz a questão dos espaçamentos. Então quais são as margens exatamente que a gente vai ter no nosso sistema. Uma outra parte é a questão dos botões. Então aqui a gente diz quais são os tipos de botões, qual é a hierarquia entre eles. A outra parte são os formulários e nele a gente vai dizer quais são, então, os nossos text fields, quais são os major buttons, os checkbox e qualquer outro tipo de formulário que seja necessário. E aà você pode também ter os tipos de listagens que você vai ter do seu sistema. Então está vendo que a gente vai agrupando cada tipo de elemento, ou a gente vai evoluindo naquela questão da atomic design. A gente começa com os átomos, lá dizendo quais são as cores, e aà vai combinando esses elementos e chega no final em botões e na mainstream listagem, ou qualquer outro tipo de componente que você pode ter no seu sistema. A questão-chave aqui gente é ter exatamente essa divisão. Pode ser feito igual a gente faz aqui na Taqtile ou não, tem outros exemplos. E um ponto assim, importante, é que o Style Guides vai fornecer as bases sólidas para você desenvolver o seu produto. Antigamente aqui na Taqtile a gente não usava Style Guides. Aà a gente tinha problema, porque chegava lá no final do projeto e aÃ, sei lá, a gente ia analisar, vamos analisar as paletas de cores do projeto. E aà tinha, sei lá, 50 tons de cinza. Aà depois ia chegar e olhar, vamos olhar um pouco mais o sistema. E aà a gente chegava que as vezes tinha dois componentes, duas partes de uma tela por exemplo, que faziam a mesma coisa mas eram diferente. E aà fica a pergunta, por exemplo. Vamos analisar o primeiro ponto que eu falei, 50 tons de cinza. Será que precisa mesmo desses 50? Será que o usuário, ele realmente entende a diferença entre os 50? Provavelmente não. O segundo ponto, ter dois componentes diferentes fazendo a mesma funcionalidade. Isso é um grande problema porque ele impacta toda a cadeia de desenvolvimento. Então lá na parte dos designers eles tiveram o dobro de trabalho, pois fizeram duas coisas. Chega para os desenvolvedores, mesma coisa, os desenvolvedores vão ter que se dividir e construir duas coisas diferentes que fazem a mesma coisa. E quando a gente fala de desenvolvimento eu posso entender que, desenvolvedor front-end, que é bem complicado porque todo o código que a gente faz, todo componente que a gente constrói, ele tem que ser escrito, testado, revisado, e quando a gente fala então de dois componentes é tudo isso dobro. E por último tem o impacto até o usuário final, porque ele vai olhar a tela e vai ter dois caras diferentes fazendo a mesma coisa, então são duas coisas que ele tem que aprender a utilizar. Então é uma complexidade que é meio desnecessário ali. Por que que a gente está deixando o sistema mais complexo se, enfim, dá para simplificá-lo? Tem uma frase do autor do Pequeno PrÃncipe, que ele diz, 'A perfeição não é alcançada quando já não há mais nada para adicionar, mas quando já não há mais nada para se retirar'. E quando a gente está falando de Style Guides a ideia é exatamente essa. A ideia é a gente consegui tirar a complexidade, deixar como uma coisa mais simples, tirar os excessos, e ter essa percepção de que no final menos é mais. Por último aqui eu gostaria de deixar mais explÃcito quais são os prós e contras de usar a solução do Style Guides. E bom, vou começar aqui com os problemas. Ele é uma coisa que sim tem tempo para fazer, não sai de graça, então ele dá um certo trabalhinho, mas é aquilo que eu disse, é importante para construir as bases sólidas do produto. Além disso, ele é visto como uma coisa útil somente pelos designers e pelos desenvolvedores. Então todo o resto, o cara que é o owner do produto, o cliente final; cliente final nem vê o Style Guides. Então o fato de ele servir só para desenvolvedores e designers faz com que ele seja meio que produto lateral e aà isso faz com que seja difÃcil de mantê-lo, a gente acaba não dando importância. E o terceiro ponto é que embora ele ajude muito na comunicação entre as pessoas do projeto, que eram dos problemas citados, ele não vai resolver por completo. No final ainda você tem pessoas e têm as dificuldades de comunicação. O documento realmente não resolve todos os problemas. Agora vamos analisar os pontos positivos. O primeiro deles é que você vai ter um workflow muito mais natural e eficiente para a equipe. Então o Style Guides vai dizer exatamente aquela questão de quais são os átomos, quais são as moléculas, exatamente quais são as regras e padrões a serem usados no sistema e a comunicação então com os desenvolvedores fica mais natural e aà o projeto avança melhor. Uma segunda vantagem é que ele é uma boa referência para as pessoas no projeto. Para todo mundo, alguém que acabou de entrar, ou as pessoas que já estão no projeto há muito tempo, ele fica com uma referência. Quais são as regras, quais são os padrões a serem utilizados? Uma terceira vantagem é que ele ajuda na consistência visual e usabilidade do sistema. A é ideia que tendo os Style Guides lá com as bases sólidas, com as regras e padrões a serem seguidas, você vai conseguir manter a consistência do sistema independentemente da parte que você tá olhando. Porque é aquilo que eu tentei mostrar durante aquela parte que eu fui avançando no Style Guides aqui da Taqtile, é que lá a gente vai dizendo exatamente quais são as peças a serem utilizadas. Então a gente consegue manter a consistência visual de todo o sistema independentemente da parte que o usuário esteja vendo. E por último, o ponto que a gente descobriu que é vantajoso aqui na Taqtile é para fazer a arguição com a equipe. Então quando a gente vai avançando o sistema, e desenvolvendo, e implementando, e quer decidir, 'o que é o melhor aqui para o sistema, qual é a forma que condiz melhor com o sistema?' Com o Style Guides a gente consegue decidir melhor esse tipo de questão porque daà dado quais são as regras e os padrões que a gente tem que seguir, esse aqui é o que fica melhor. Então ele é um documento que ajuda na arguição. Bom pessoal, é isso. Obrigado então. Espero que vocês utilizem o Style Guides na hora de desenvolver o seu sistema. Como eu disse, o que eu mostrei aqui é a forma como a gente faz aqui na Taqtile o Style Guides, mas tem diversas outras formas. Agora, se vocês quiserem dar uma olhada como outras empresas estão fazendo Style Guides e tudo mais, eu deixei o link aà na parte dos materiais complementares e aà deem uma olhada.
