Tornando o design escalável

Diego Jovanholi
4 min readJun 6, 2017

--

Componentização de um ecossistema

Muito se fala sobre componentização e design escalável, mas, a grande maioria dos conteúdos relacionados só apresentam um apanhado de boas práticas sobre vários conceitos sem se aprofundar muito, e fica a pergunta: Como se faz isso?

Neste post vamos mostrar o framework que estamos testando e ferramentas para deixar nosso trabalho escalável e consistente em todos os ecossistemas da OLX.

O grande desafio de quem trabalha com User Interface Design em times grandes com toda certeza é gerenciar e atualizar elementos em arquivos compartilhados, mantendo a consistência enquanto ele cresce.

Oh não! Meus símbolos estão desatualizados!

Quando você trabalha sozinho isso não é necessariamente um problema. Você pode atualizar tudo manualmente e seguir seu próprio fluxo de trabalho. Agora, vamos adicionar 3, 6 ou mais designers nessa equação. Mesmo você tendo um arquivo único e sendo muito organizado os problemas já começam a aparecer.

Vamos começar!

Desenvolva seu sistema

Utilizamos uma adaptação da metodologia de atomic design para criar nosso sistema de design. Ela consiste em desenvolver o sistema em múltiplas partes para criar algo único.

Como é isso no nosso dia a dia?

Inicialmente, cada componente será desenvolvido dentro de um contexto da vertical (Squads) e será validado em produção ou teste de usabilidade. No final do ciclo de desenvolvimento, os componentes serão uma opção sólida e válida para ser adicionada ao guia de componentes (UI Style Guide), tornando o design escalável e agilizando o processo de componentização. As plataformas que englobam o ecossistema do produto OLX:

  • Web — Desktop e Mobile
  • Apps — Android e iOS

A ideia de componentização não é tão recente quanto parece. Já em 1968, Doug Mcllroy da NATO Software surgiu com o tema componentização. Na época ele teve a ideia de criar componentes de software para produção em massa.

Então, fica mais ou menos assim:

Você pode trabalhar criando um único arquivo ou separar dentro de uma pasta os elementos do seu UI Kit Style Guide (Ex: Forms, Colors).

Versione

Mesmo utilizando a metodologia do atomic design para desenvolver o UI Style Guide, ainda existe o problema de controle e versionamento dele, que gera retrabalho e inconsistência no resultado final

Para controlar e versionar nossos Guides, utilizamos o Git. Através dele, podemos desenvolver projetos nos quais diversas pessoas podem contribuir simultaneamente, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas. Para configurar nosso repositório contamos com a ajuda do time de desenvolvimento.

No início, utilizamos o plugin Git Sketch para fazer os commits no nosso repositório. Infelizmente, ele ainda é muito instável. Acabamos adotando o SourceTree, o mesmo utilizado pelo nosso time de desenvolvimento. Trabalhamos com um arquivo Master (versão estável). Para inserir atualizações e criamos Branchs.

Ao final de cada expedição de atualização, fazemos um Merge request para Master, fechando um Release note com tag da versão.

Sugestão de nomenclatura para Tag:

Guide_”Plataforma”_0.0.0

Cada zero é representado por um “M”:

  • m (major) (quebra total de versão anterior)
  • m (medium) (adição de novas funcionalidades)
  • m (minor) (correção de algo que está em produção)

PS: Caso sua empresa já tenha uma linha visual não consolidada (em arquivos), sugiro fazer expedições de no máximo 1 vez por semana (time de UI) para fechar os arquivos até chegar em uma versão estável (1.0.0).

Mãos a obra

Trabalhamos com o Sketch para desenvolver nossas interfaces. Somos apaixonados por ele! A coisa mais legal é a possibilidade de que os usuários criem plugins, o que facilita muito nosso dia a dia. Segue nosso setup:

Align: Utilizamos para alinhar o artboard de Symbols.

Automate Sketch (O pulo do gato): Diferente do Craft, ele é muito simples (Sem bugs). Possibilita atualizar/importar seus símbolos e estilos a partir de um repositório.

Nudged: Utilizamos o sistema de grid de 8pt. Essa configuração facilita o posicionamento dos componentes da interface na tela e o desenvolvimento de um design modular. O Nudged possibilita trocar o espaçamento de 10pt (padrão) para 8pt ou qualquer outro valor.

Zeplin: Para compartilhar as telas com o time de desenvolvimento.

Runner: Com ele você não precisa pesquisar no menu, é só executar comandos diretamente do seu teclado.

Vantagens:

Para o time de design:

  • Velocidade
  • Padronização
  • Sistema escalável
  • Manutenção simples
  • Curva de aprendizado menor para novos membros do time

Para os desenvolvedores:

  • Componentização
  • Velocidade
  • Manutenção simples
  • Curva de aprendizado menor para novos membros do time

Quer tirar alguma dúvida? Debater algum tópico do artigo?

Manda um e-mail pra gente, vai: design@olxbr.com. Estamos buscando designers incríveis para completar nossa equipe.

--

--