Oscar cria ferramentas digitais para uma variedade de usuários, incluindo membros, fornecedores, corretores, empregadores e uma ampla gama de funcionários de mudancas. Projetar todas essas experiências digitais em paralelo, com uma equipe pequena, tem sido um desafio. Nosso investimento contínuo em nosso sistema de design, Anatomy, nos ajudou a enfrentar esses desafios. Para aqueles que não estão familiarizados, um sistema de design define a UI / UX central de uma marca. Isso inclui tudo, desde tipografia a campos de formulário e layouts de página inteira.

Baseamos nossa abordagem no Atomic Design, um princípio que descreve o menor dos elementos ou componentes da IU como átomos (por exemplo, texto, cor ou espaçamento) e componentes cada vez maiores como moléculas compostas de átomos (por exemplo, uma entrada de texto, um botão, ou um modal). A ideia é que, à medida que um sistema de design atômico se desenvolve, ele levará a componentes (organismos) cada vez mais complexos e agrupados e, eventualmente, a layouts, páginas ou modelos inteiros.

Desde que começou a trabalhar no Anatomy em 2016, a equipe de design implementou o sistema em quase todas as experiências na web que Oscar criou desde então. Nos últimos dois anos, aprendemos algumas lições sobre como comunicar, criar e organizar com sucesso uma equipe para construir um sistema de design.

1. Comunique com antecedência como um bom sistema de design pode contribuir para a escalabilidade.

Em uma startup ambiciosa como a mudancas, os designers têm múltiplas responsabilidades. Precisamos ser enxutos e iterativos. Isso leva tempo, recursos, planejamento e priorização cuidadosa. Para ajudar nossa equipe a entender a importância da anatomia, tomamos uma decisão consciente de compartilhar nosso trabalho de sistema de design, desde o início e com frequência. Educamos outros designers, gerentes de produto, engenheiros e até mesmo parceiros de negócios sobre o que é Anatomia, por que é importante e como está ajudando a contribuir para a escalabilidade de Oscar. Quanto mais cedo for alocado tempo e recursos físicos para uma iniciativa de sistema de design, mais cedo e mais facilmente ela será implementada.

2. Mantenha a simplicidade com apenas um toque de personalização.

Descobrir como equilibrar a flexibilidade em um componente foi uma das lições mais difíceis que aprendemos ao construir o Anatomy. Além das opções de tema (por exemplo, cores e tamanhos), alguns componentes compartilham layouts, funcionalidades e padrões de interação. Eles devem ser integrados ao componente? Quanta definição é demais? Um componente muito bem definido pode ser limitante, mas muita flexibilidade pode ser um convite a um zoológico de inconsistência. Por fim, tomamos essa decisão componente por componente, mas descobrimos algumas regras gerais pelas quais devemos viver. Por exemplo, descobrimos que é melhor não construir qualquer personalização preventivamente. Embora a personalização possa ser adicionada, é mais difícil separar os componentes existentes. Além disso, construir módulos de conteúdo interno para alguns componentes tem sido uma maneira eficaz de controlar layouts específicos, ao mesmo tempo que oferece uma saída de emergência para casos especiais.

3. Nunca é muito cedo para construir em escala.

Inicialmente, construímos o Anatomy em dois produtos da web: o aplicativo da web do membro e o aplicativo da web do provedor. Desde então, o uso do Anatomy mais que dobrou, em uma infinidade de ferramentas internas (incluindo gerenciamento de dados do provedor, processamento de reclamações e as ferramentas da web usadas por nossas equipes de Concierge), bem como Oscar for Business. Além disso, foi desenvolvido um ciclo de feedback com o Mobile Anatomy, o sistema de design React Native do Oscar para nossos aplicativos móveis. Embora haja muitas sobreposições de necessidades, cada aplicativo difere enormemente em seus usuários, casos de uso e fluxos. No início de março, chegamos a um ponto em que, quando queríamos alterar um componente, hesitávamos em implantar a alteração em todas as instâncias do componente. Para resolver isso, ativamos recentemente a sinalização de recursos para bloquear determinados recursos e atualizações em um componente, em vez de um ecossistema tudo ou nada. Essa flexibilidade já provou ser útil para coisas como testes A / B e implementações lentas para mudanças maiores.

4. Nenhuma decisão é permanente. Tudo pode ser alterado.

Às vezes, as decisões que tomamos sobre como um componente se parece ou é construído parecem muito permanentes enquanto permanecem na base de código por semanas, meses e anos, acumulando-se lentamente mais e mais instâncias com o passar do tempo. “Eu quero mudar isso … mas, como eu poderia mudar agora? Todo mundo já está usando. Está em toda parte.” Soa familiar? Pare com isso. É mutável. É sempre melhor resolver quaisquer problemas mais cedo ou mais tarde, antes que eles sejam ainda mais dispersos no ecossistema de um produto. Até alguns meses atrás, todos os campos de formulário do Anatomy (entradas, seleções, campos de preenchimento automático, etc.) eram componentes de primeira geração feitos antes de aprender algumas práticas recomendadas e com base em designs de código legado. Os campos de formulário anteriores tinham dimensionamento absurdo e suporte a tema / tamanho inconsistente. O conjunto de componentes foi permeado globalmente em todos os nossos aplicativos, mas em fevereiro passado, nos comprometemos a lançar nossos campos de formulário de segunda geração. Avance alguns meses, e muitos de nossos aplicativos da web já começaram a colher as recompensas de maior consistência, melhor qualidade de código e design mais acessível.

5. Documentação e símbolos de esboço são os melhores amigos do designer.

Em uma equipe pequena, pode ser relativamente fácil manter a consistência em como cada designer está usando componentes e padrões de IU específicos. Mas, à medida que as equipes crescem, as especificidades e nuances de como e quando usar componentes individuais podem se perder. É por isso que é extremamente importante manter a documentação atualizada e acessível sobre todos os componentes, tanto nos padrões de design quanto no código. Além disso, manter uma biblioteca de símbolos no Sketch provou ser muito útil para melhorar a eficiência do projeto, a consistência visual e simplesmente atuar como uma fonte irrefutável de verdade para a equipe. Com documentação atualizada para referência e uma biblioteca de símbolos para obter, novos designers que se juntam ou até mesmo não designers que desejam fazer algo bruto podem fazer isso sem se preocupar com detalhes como cor e espaçamento.

6. Configure um processo para construir, crescer e contribuir.

Quando começamos a trabalhar em nosso sistema de design, era difícil trabalhar nele e nossa abordagem não era polida. No entanto, à medida que o Anatomy cresceu, tanto a equipe de engenharia quanto a equipe de design começaram a desenvolver seus próprios fluxos de trabalho em torno de como contribuir para o Anatomy. Para design, exercícios como conversar com as partes interessadas relevantes, auditoria de caso de uso adequada e pensamento explícito em relação à acessibilidade e capacidade de resposta ajudaram imensamente a garantir o sucesso de um componente em nossa biblioteca. Além de um processo de design estabelecido, a padronização de tarefas como documentação, transferência, revisão de código e QA tem sido útil para tornar a anatomia mais familiar para qualquer pessoa curiosa. Definir esses processos também tem sido uma ótima maneira de diminuir a curva de aprendizado para que novos colaboradores se envolvam.

A beleza e a frustração de trabalhar em Anatomia é que, como um sistema de design vivo, o trabalho nunca está realmente completo. Ao longo do ano passado, quase todos os componentes do Anatomy foram ajustados ou reprojetados. À medida que avançamos na construção de nossos primeiros componentes em nível de organismo na anatomia, tomamos um momento para reavaliar e garantir que estamos construindo sobre uma base sólida. Nos próximos meses, nossa equipe continuará a atualizar nossos componentes de nível atômico com foco na acessibilidade antes de passar para componentes de layout mais complicados. Nesse ínterim, continuaremos a aumentar o escopo de nossa biblioteca, tanto em termos de componentes de IU, quanto de recursos com suporte, flexibilidade e escalabilidade. Fique ligado para mais informações sobre Anatomia nos próximos meses!