Design
Design System & Design Ops: Introdução
7 minutos de leitura
Série sobre Design System & Ops
Este artigo faz parte de uma série sobre Design System & Ops, na qual abordamos diversos aspectos relacionados a esses temas dentro da disciplina de design e suas interações com outras áreas da tecnologia.
Esse é o artigo Nº 1 da série.
No mundo da tecnologia muito se ouve falar em Design System e Design Ops dentro de uma mesma conversa. Mas o que é exatamente cada coisa?
Fotografia de Mario Gogh na Unsplash
Com a crescente demanda de produtos digitais nas últimas décadas surgiram novas necessidades dentro do mercado e a partir disso se ramificaram novas áreas dentro de outras já existentes.
Alguns exemplos disso são: a área de Agilidade dentro da Gestão de Projetos ou Dev Ops dentro da área de Desenvolvimento de Software e inclusive Design Ops e Design System dentro da área de Design.
Dentro dessas áreas, foram criadas abordagens que ajudaram sua implementação em experimentos, projetos, produtos, empresas, etc e que acabaram sendo testadas à prova de fogo, conquistando o seu valor e espaço no mercado e se estabelecendo como essenciais dentro da indústria.
Design System (DS, para os mais chegados) é uma dessas áreas que se tornou um case de sucesso e que acabou se interconectando com uma outra área que vem se estabelecendo nos últimos anos: a área de Design Ops.
Um possível diálogo em um time de tecnologia:
— Tá, mas o Design Ops não é o designer que cuida do DS?
— Hmm, não é bem isso…
Foto de Emily Morter na Unsplash
O que é então?
Design Ops
Para esclarecer um pouco mais vamos olhar para como alguns dos gigantes da área a definem.
Design Ops é tudo que apoia métodos, processos e habilidades de alta qualidade.
— Dave Malouf
Gosto de dizer que Design Ops é tudo menos design. Mantenha os designers focados no trabalho e deixe o Design Ops cuidar do resto.
— Meredith Black
São duas definições com suas particularidades, mas algo em comum que podemos perceber entre as duas é que Design Ops se trata de uma abordagem que busca proporcionar autonomia, performance e qualidade em Design dentro de uma companhia.
No geral, Design Ops é compreendido tanto como uma área/subdisciplina do design assim como uma pessoa ou setor responsável pela área ou até mesmo como uma abordagem dentro de um time de design menor onde não há uma pessoa dedicada exclusivamente, mas sim iniciativas e atividades de Design Ops compartilhadas entre os designers desse time.
Design System
Hora de conferir a definição dos outros gigantes.
Um Design System é a história oficial de como uma organização projeta e constrói produtos digitais.
— Brad Frost
Um Design System oferece uma biblioteca de estilo visual, componentes e outras preocupações documentadas e divulgadas por uma pessoa, equipe ou comunidade, como código e ferramentas de design para que a adoção de produtos possa ser mais eficiente e coesa.
— Nathan Curtis
Percebemos que aqui o objetivo se especifica em garantir mais eficiência e entregas com mais coesão em times que atendem produtos digitais.
Em Design System também temos alguns casos e contextos de aplicações diferentes. Geralmente pode ser considerado tanto como uma área/subdisciplina do design assim como um setor ou time responsável.
E indo mais além, podemos entender que o Design System também é um produto. É claro, um “produto-consequência” que se retroalimenta e abastece os demais produtos de seu ecossistema.
Mas assim como seus demais irmãos, ele também possui uma vida. A diferença é que essa vida se baseia conforme a evolução e necessidade desses outros.
Como as duas coisas se conectam?
Com o amadurecimento e o surgimento de oportunidades de aprimoramento do design dentro da tecnologia, apareceu um terreno fértil para que as duas áreas pudessem coexistir dentro das companhias.
Em alguns casos isso permitiu que o setor de Design Ops percebesse Design System como uma iniciativa com potencial para alavancar o processo de design dentro de sua empresa e consequentemente com que o setor se responsabilizasse pelo DS.
Além disso o setor ou a pessoa de Design Ops é responsável por diversas outras iniciativas. Mas isso é um papo para outro momento, hoje vamos nos concentrar em DS.
Foto de Alina Grubnyak na Unsplash
E por que um Design System?
Bom, como notamos anteriormente, o principal objetivo de um DS se trata de potencializar a eficiência e coesão na entrega de produtos digitais.
Mas acho que podemos engrossar um pouco mais esse caldo considerando alguns outros aspectos.
—
Motivo #1 — Coesão no produto
Nathan Curtis menciona isso em sua definição. Mas o que seria isso exatamente na prática? Digamos que você está envolvido na construção de um App ou Site que possui o potencial e a expectativa de aumentar de tamanho.
A área de negócio tem planos para oferecer diversos outros produtos e serviços dentro desses canais e isso pode ocorrer numa velocidade muito rápida dependendo da empresa.
E aqui vale refrescarmos duas leis fundamentais da UX:
- Consistência e Padronização (4ª Heurística de Nielsen): “Os usuários não deveriam se perguntar se palavras, situações ou ações diferentes significam a mesma coisa. Siga as convenções da plataforma e do setor.”
- Efeito Estético-Usabilidade (Kurosu e Kashimura): “Os usuários geralmente percebem um design esteticamente agradável como um design mais utilizável.”
Para a pessoa designer, a preocupação aqui é entregar essas novas soluções com a melhor experiência do usuário possível e esses dois fundamentos (e muitos outros) vão estar pipocando na cabeça dessa pessoa na hora de conceber a UI.
Porém, muitas vezes o designer vai trabalhar em pedaços desse App ou Site em momentos diferentes ou então é possível que a equipe de design cresça para atender todos esses novos produtos.
Isso abre margem para que o designer crie um botão com um padrão (visual e comportamental) em um pedaço do produto e re-crie um outro botão com um padrão diferente em outro pedaço do produto.
E aqui a primeira mágica do DS acontece…
Mágica 1: Um ecossistema de Design System conta com uma biblioteca com todos elementos que podem ser reutilizados na interface do produto, assim garantindo que todos os designers estejam utilizando o mesmo botão na construção de suas interfaces.
—
Motivo #2 — Escalabilidade
Se lembra que no Motivo #1 o produto tá aumentando e que a velocidade disso pode ser muito rápida e que estão surgindo diversos produtos querendo reutilizar um botão?
Mesmo que os designers e desenvolvedores saibam que precisam utilizar um botão que esteja consistente em todas as etapas do fluxo, como podemos garantir que isso está acontecendo de forma fiel e eficiente? Automatizando.
E como se automatiza? Criando bibliotecas, com elementos de UI reutilizáveis, espelhadas entre o lado de Design e o lado de Desenvolvimento. Por exemplo uma biblioteca de design no Figma que seja idêntica a uma biblioteca de desenvolvimento.
Esses elementos de UI são como “peças de lego” que você vai utilizar para construir a sua mini-cidade. Eles se chamam Tokens e Componentes, mas não se preocupe com isso agora, nós vamos olhar pra isso em uma publicação futura.
Dessa forma o designer ou desenvolvedor só vai precisar pegar essas “peças de lego” do DS e inserir na UI em que está construindo e o que antes levava minutos ou horas agora leva segundos.
Mágica 2: Os designers, desenvolvedores e stakeholders ganham tempo e conseguem dar mais atenção para outras preocupações que também são importantes para o produto.
—
Motivo #3 — Comunicação
Imagine se designers e desenvolvedores se referissem a um mesmo elemento de UI utilizando o mesmo nome?
Pois é, um DS possibilita isso. Porque o espelho entre as bibliotecas de design e código proporcionam esse “contrato” entre design, desenvolvimento e qualquer stakeholder que esteja discutindo uma solução de UI.
Mágica 3: Acredite se quiser, o time vai ganhar bastante tempo com isso, além de se entrosar, se sentindo dono, co-autor e defensor da UI.
“And the world will live as one”
—
Motivo #4 — Eficiência
Um time que consegue entregar consistência e padronização com escalabilidade e boa comunicação naturalmente vai se tornar eficiente. E aqui veremos a última e maior mágica de todas acontecer.
Designers felizes com a UI e organização dos entregáveis, Devs felizes com o código e a arquitetura do projeto, usuários conseguindo utilizar o produto com mais facilidade, área de negócio feliz com as entregas, stakeholders conseguindo consultar os entregáveis com facilidade, etc…
Parece um sonho, né? Mas não é, e não sou eu que tô dizendo. Empresas como Google, Airbnb, IBM e Salesforce implementaram Design Systems com sucesso, resultando em uma experiência do usuário mais consistente e eficiente em seus produtos.
Ainda segundo o Report da Meiuca sobre Design System & Design Ops no Brasil em 2022, 73% das empresas, respondentes da pesquisa, trabalham com algum tipo de Design System.
Mágica 4: As entregas vão acontecer com mais qualidade e agilidade.
Foto de Mourizal Zativa na Unsplash
Tá, mas quando utilizar um DS?
Considerando que um dos aspectos que um Design System busca é entregar artefatos com coesão, devemos refletir que esse aspecto se trata de uma mesma entrega que se divide em diversas partes e que todas essas partes devem ser orientadas por uma mesma diretriz.
É possível perceber um Design System gerando muito valor em cenários como estes:
Cenário A — Escalabilidade de entregas
Quando se existe expectativa de escalabilidade em relação a uma empresa, produto, projeto, etc. Pois como vimos anteriormente, um DS permite a escala de uma UI que necessita crescer rápido, de forma padronizada e com agilidade.
Cenário B — Qualidade de entregas
Se a empresa está buscando melhorar a qualidade dos seus entregáveis como um todo, um DS pode ajudar visto que consegue equalizar a padronização e qualidade de diversos entregáveis.
—
Potenciais desafios
Sabemos que na vida nem tudo são rosas, né? Então vamos falar um pouco sobre adversidades que possivelmente você pode enfrentar. Isso vai te ajudar a se preparar para tirar o seu DS do papel.
Mão de obra — Ter um DS envolve responsabilidades e comprometimento, além de trabalho duro, pois no fim das contas se trata de um produto. Um DS não vai acontecer sem ser construído e sustentado e sem evoluir junto ao ecossistema de produtos do qual faz parte.
Governança — Um DS não se faz sozinho. Quanto mais pessoas o conhecerem e o utilizarem mais efetivo ele se tornará. E pra isso você vai precisar comunicar e articular o seu produto dentro da companhia.
Maturidade — É natural que as pessoas tenham que desenvolver suas habilidades em Design Ops e Design System ao longo dessa trajetória. Então investir em difundir o conhecimento e educação será crucial e intermitente para subir a régua do seu time e consequentemente seu produto.
Hey 😃
Que legal que você chegou até aqui! Espero que os insights compartilhados tenham sido úteis e de valor para a sua trajetória. Fique a vontade para fazer trocas, compartilhando opiniões, experiências e sugestões comigo. Nos vemos no próximo!
