A trajetória para um produto com design escalável

Cada vez mais nosso software, o RD Station, tem se descolado do nosso framework, o Bootstrap, ampliando a gama de elementos visuais, ícones e grid. Como não guardamos os novos componentes criados por nós, acabamos perdendo a chance de reutilizá-los em outras funcionalidades, duplicando elementos que fariam uma mesma ação em nosso framework.

Por exemplo, criamos um collapse (uma espécie de menu em sanfona) diferente do oferecido pelo Bootstrap. Como você pode ver abaixo, alocamos ele dentro de um painel, acrescentamos ícones e sequer usamos o JavaScript do framework:

Além da falta de documentação dos novos componentes, levantamos outros problemas:

1. Dificuldade em manter consistência na interface do RD Station, tendo em vista o crescimento dos times de design e front-end.
2. Manter a agilidade dos times sem gerar dependências entre desenvolvedores e designers.
3. Atualização do nosso framework visual, o Bootstrap, visto que muitos dos nossos componentes já não fazem parte dele.

Round 1 — Designers, uni-vos

Aqui na Resultados Digitais, temos pequenos times auto suficientes para facilitar a comunicação e o trabalho em equipe. A quantidade de desenvolvedores back-end, front-end e designers varia de acordo com a necessidade de cada time: alguns não têm designer, já que não existem tarefas envolvendo interface e experiência do usuário.

Uma primeira forma de solucionar o problema foi unir alguns designers que estavam dispersos em diferentes times. Eu, Simone, Glauco e Quaresma seríamos os responsáveis por criar soluções visuais e validá-las com nossos clientes antes de passar para os desenvolvedores. Fazer com que novas tarefas passem por uma etapa de validação é uma boa forma de manter a consistência geral do software.

Glauco Cardoso, Rodrigo Quaresma, eu (Lívia Amorim), Simone Beltrame e Daniel Mai.

Por quase duas releases (cada uma com duração de um mês), nós ajudamos os product owners a preencher o backlog dos outros times. A união de alguns designers num time de especialistas em experiência do usuário e na manutenção do framework resolveu um problema de comunicação e, por isso, deixou processo de criação interface mais ágil. Com iterações constantes, percebemos e atacamos problemas mais rapidamente.

Por exemplo, percebemos que os designers de fora do time de solução estavam de mãos atadas e sempre dependendo da nossa aprovação. Além disso, nossas soluções geravam muitos documentos e nem tudo o que era especificado para os desenvolvedores precisava estar ali.

O time de produto da Resultados Digitais trabalha com metodologias ágeis. Um dos nossos princípios é não gerar burocracias sem sentido como documentos estáticos com uma série de requisitos. Não fazia sentido persistirmos na criação de novas documentações a cada tarefa que fizéssemos para manter a consistência da nossa UI (user interface, ou interface do usuário).

Buscando resolver o problema, fomos ao mercado e pesquisamos como algumas empresas encaram o processo de pesquisa, solução e desenvolvimento de novas tarefas.

Round 2 — Estudo e Benchmark

Tanto o MailChimp quanto a Salesforce, empresas que usamos como referência para o nosso benchmark, tiveram o mesmo problema: viram-se em uma aplicação sem padrões na interface — o que afetava a consistência visual dos componentes e o processo de design.

Os designers da Salesforce perceberam esse problema ao tentar fazer o redesign da aplicação. Faltava uma arquitetura que facilitasse o processo. Não havia um framework. Todo o código precisaria ser refeito para que eles fizessem qualquer alteração. Por exemplo, remover sombras, cores, fontes e ícones.

No artigo “Design Products That Scale” (Faça o design de produtos que escalem), Brad Haynes comentou que ele, junto com outros designers da Salesforce, aproveitaram um projeto que estava em andamento, o aplicativo mobile da Salesforce, para criar uma kitchen sink de elementos visuais (uma lista com todos os componentes da interface). Posteriormente, criaram um style guideline para a marca, com princípios, cores e ícones e reuniram todos os componentes em uma aplicação do Heroku, que pode ser vista neste link.

A ideia era que pudessem aproveitar esse mesmo guia, feito do zero, na aplicação antiga. Ficaria mais fácil refatorar o código tendo uma clareza maior sobre os padrões visuais do sistema.

Já o MailChimp, de acordo com o livro UX Reader, juntou o time de 12 pessoas para fazer uma grande alteração com o intuito de manter a consistência geral do software. É importante perceber, porém, que a aplicação do MailChimp não é um enorme castelo de cartas, como o caso da Salesforce, apresentado acima.

O time da MailChimp é mais enxuto e a preocupação não estava no processo, mas em facilitar ainda mais futuros redesigns da plataforma de Email Marketing.

Por fim, a solução foi bem parecida com a da Salesforce: eles também subiram uma aplicação com todo o style guideline. O resultado você pode ver neste link.

Tanto a Salesforce quanto o MailChimp usaram os princípios do Atomic Design na construção dos guias de estilo. É bem simples: ele consiste no uso de pequenos componentes para a criação de uma página. Vários frameworks, como o Bootstrap e o Foundation, usam essa mesma técnica.

Round 3 — Aprendizados

Na Resultados Digitais, já usamos um framework. O Bootstrap não é o melhor framework possível, mas resolveu — e ainda resolve — uma série de problemas. Ele já é atômico (montado com elementos menores) e, por muito tempo, foi o nosso style guideline. Por causa dele não precisamos fazer uma refatoração de todo o nosso software. Resumindo, por causa do Bootstrap temos um problema muito menor que o de várias empresas.

Vendo outras soluções, percebemos que precisávamos apenas organizar melhor os nossos componentes, estruturando e deixando isso muito mais visual para desenvolvedores e designers.

Percebemos que a chave do sucesso era gerar uma documentação viva, um style guideline dinâmico.

Essa documentação estaria disponível no GitHub, mantendo um controle de versão e facilitando o compartilhamento com o restante do time de produto. Os designers do time de pesquisa e solução seriam os responsáveis por manter esse documento sempre atualizado. Outros designers e desenvolvedores também poderiam colaborar com qualquer ponto que faltasse através de pull requests e adição de issues.

Com um guia como o do MailChimp ou da Salesforce, ninguém mais teria que depender de um designer para saber questões básicas, como alinhamento ou tipografia. Teríamos documentado tudo o que precisamos para manter a consistência da nossa ferramenta, o que facilita a comunicação e evita desperdícios. Constaria neste documento:

• Tipografia;
• elementos (ex: tabelas e alertas);
• exemplos de páginas (ex: página de upload);
• paleta de cores;
• ícones;
• ilustrações e animações.

Round 4 — Próximos passos

Como nosso software, o RD Station, é feito em Ruby on Rails, resolvemos separar o nosso CSS principal — o núcleo — em uma gema. Basicamente: separar o nosso framework do restante do código. Com isso, ele pode ser usado em várias aplicações, desde o nosso software, até o nosso style guideline. Eles compartilhariam o mesmo CSS. Não é demais?

Os designers do time de solução seriam os responsáveis por manter essa gema e o guia de estilo. O fluxo ideal para a criação de um novo componente seria: implementar o CSS no RD Station SASS (núcleo do CSS), exemplificar o uso no RD Style Guidelines (guidelines para uso do núcleo) e, somente depois, usar do componente no software.

Claro que existem outros cenários. Nem toda implementação vai passar por todo o fluxo. A ideia é que os desenvolvedores e designers tenham a liberdade de adicionar um CSS específico para cada funcionalidade, diretamente no software. Isso mantém nosso processo ágil e lean.

Todas as inconsistências que aparecessem no RD Station seriam anotadas em formas de issue no GitHub para serem organizadas pelos designers do time de solução durante as releases. Podem ser criados novos componentes, removendo o máximo possível de especificidade do CSS do software.

No meu próximo post, prometo falar mais sobre como foi o processo técnico da separação da nossa gema e organização de novos componentes. Agora foi só um gostinho.

Conclusão

Um style guideline é imprescindível para um software com design escalável. Quando se tem um time muito grande, é fácil acabar perdendo um pouco da coerência entre elementos visuais. No nosso caso, como já tínhamos um framework, criamos uma falsa sensação de conforto, já que tínhamos “um documento para seguir”. O problema é que nossa biblioteca era muito maior que a do Bootstrap e aquele documento já não era mais suficiente.

Organizar e padronizar um style guideline é importante e não deve ser um processo doloroso. Precisamos ser ágeis e criar documentos flexíveis e dinâmicos. Para nós, a solução foi separar o CSS principal do nosso software, deixando-o mais escalável e, o RD Station, mais independente.

Por fim, aprendemos a resolver um problema sem gerar novas burocracias. Derrubamos barreiras e demos mais liberdade a todos no processo de desenvolvimento.

Originally published at shipit.resultadosdigitais.com.br.

Quer integrar a equipe de UX aqui na Resultados Digitais, acesse:
http://shipit.resultadosdigitais.com.br/trabalhe-conosco/