Soma Design System no iOS
Você já ouviu falar de Design System?
Aqui na XPInc. já faz parte do nosso dia a dia, mas se você ainda não ouviu falar, aqui vai uma breve definição nossa:
Design System, ou DS, é um ecossistema de componentes criados e documentados a partir de semânticas de estilo, respeitando princípios de design e marca, a fim de auxiliar a forma como os produtos são projetados e escalados.
Hoje nós vamos falar um pouco do SOMA, o Design System da XPInc..
Pensando em escalabilidade, e ganho de agilidade no desenvolvimento dos nossos produtos e features, o design system caiu como uma luva nas nossas necessidades do dia a dia.
O SOMA é um DS multiplataforma (iOS, Android e Web), e nesse post vamos falar um pouco de como ele foi pensado e criado no iOS, e como é o nosso dia a dia utilizando-o.
O que são Design Tokens?
Para times e empresas que estão pensando em adicionar um DS aos seus projetos, o termo Design token vai ser essencial nessa jornada.
Também chamado de Variável semântica de estilo, os Design Tokens são variáveis definidas pelo time de design e que, na escala atômica de design, são os menores valores utilizados para construção de telas e componentes. Definidos por: cor, espaçamento, tamanho e estilo de fontes, variáveis de animação e etc.
Na nossa equipe de iOS, nós optamos por utilizar os Design Tokens através de um arquivo .json utilizado no SDK.
Exemplo de uma folha de design tokens:
Esses tokens são lidos via runtime, e carregam o valor durante o tempo de execução por um Singleton.
SpacingInset.somaSpacingInsetLg.value()UIColor.soma(.brand1)
O principal benefício do uso dos Design Tokens é que, quando iniciamos a aplicação, apontamos pra qual tema ou marca deve ser carregado naquele momento.
Hand-off de componentes
Agora que você conheceu um pouco de como utilizamos design tokens, vamos mostrar o quão importantes eles são no nosso dia a dia.
Aqui na XPInc., por definição utilizamos o Figma para criação de telas, definição de fluxos, componentes. Para padronizar e facilitar o desenvolvimento, tanto de componentes como de telas, utilizamos um arquivo de Handoff. Nada mais é que a tradução de todos os Design Tokens para o time de desenvolvimento.
Dessa forma, podemos referenciar os tokens no código, sem se preocupar com o valor do mesmo.
Isso facilita muito o dia a dia dos desenvolvedores, já que cada configuração do componente já está listada no Figma, e sabemos qual é o tema base de cada item daquele layout.
No código, utilizamos protocolos de temas para definir as propriedades que podem ser modificadas naquele componente:
Por fim criamos classes que implementam esses protocolos, facilitando a criação de diversos temas para o mesmo componente:
E quando a equipe de design precisa fazer uma pequena modificação no componente, como por exemplo, a mudança da cor de um botão na tela de onboarding?
Aí entra mais um recurso do SOMA no iOS, a extensão das classes de tema:
Simples né? Foi montado assim para facilitar a adesão dos times.
Utilizando Temas no componente
Por fim, utilizamos esses protocolos e implementações de tema, dentro do componente, que acompanha sempre um tema default:
E deixamos sempre um método público para receber a mudança de tema.
Garantido a qualidade
Como os componentes do SOMA podem ser utilizados nos mais diversos dispositivos, precisamos manter a qualidade independentemente de onde eles serão importados. Por isso, desenvolvemos componentes responsivos que permitem uso desde um iPhone SE a um iPad Pro.
Para tudo isso funcionar bem, os testes de UI são essenciais. Utilizamos a ferramenta do Facebook, Snapshot Test, com ela conseguimos manter sempre a consistência do componente criado. Primeiro rodamos um teste inicial para criar a “referência ideal”, onde temos a certeza que o componente está certo.
Deixamos a variável record como true, assim será criado uma imagem do componente.
Em seguida deixamos o record = false, e rodamos novamente, será criado uma nova imagem do componente, dessa vez comparando com a tirada anteriormente. Caso haja qualquer modificação em um pixel do componente o teste irá falhar.
Desafios do Design System em uma empresa multimarca
Se por um lado o DS traz um ganho relevante nas entregas de produtos, por outro é preciso ter muito cuidado quando se trabalha com muitos times e aplicativos multimarca. Nós consideramos alguns pontos importantes quando utilizamos o SOMA:
Sempre alinhar o escopo dos componentes
Aqui entendemos que desenvolvedores tem opiniões diferentes e, naturalmente, o entendimento de cada componente pode variar de acordo com o time que o implementa. Por isso é importante que todo mundo esteja alinhado, e saiba responder a algumas perguntas, como: os componentes vão ter regras de negócio? vão ser apenas visuais? o que vai ser implementado pelos times?
Pequenas modificações podem causar grandes problemas
Quando um componente é utilizado por diversos times, cada alteração deve ser pensada a ponto de não impactar implementações existentes. Acompanhamos de perto as alterações no SOMA para que um time não prejudique o outro.
Melhoria contínua
O SOMA nunca está pronto. Todos os dias as equipes importam componentes para seus projetos e encontram melhorias necessárias. Então constantemente nós abrimos Pull Requests explicando o porquê nosso time precisa daquela alteração e, por isso, todos os dias o SOMA fica melhor.
Conclusão
É difícil afirmar que o DS vai ser a melhor solução para o seu produto. Hoje entendemos que o desempenho do SOMA está ligado ao comprometimento de todos os envolvidos. Desde desenvolvedores e designs até a alta gestão. Não podemos dizer que é uma tarefa simples manter essa estrutura funcionando, mas já estamos colhendo os frutos do SOMA. Frutos que não são poucos.
Tivemos um ganho de 20% a 30% de eficiência na entrega de novas features, equalização de comportamentos de design em todas as plataformas e até mesmo ganhos subjetivos, como uma maior unificação da equipe, já que nossas entregas quase sempre podem ser reaproveitadas em outros apps.
Se você ou sua equipe ainda está com dúvidas se usar um DS é o melhor caminho, sugerimos começar pequeno, implementado componentes para serem reaproveitados por outros times, padronizando temas (Dark e Light por exemplo) e observando como as equipes utilizam esses componentes. Os resultados podem surpreender.
