Preenchendo a lacuna entre designers e desenvolvedores

Este artigo foi gentilmente desenvolvido por nossos amigos do UXPin, uma ferramenta de design e prototipagem de interface do usuário que dá aos seus protótipos os superpoderes que eles merecem: estados, expressões JS, variáveis, interações condicionais, sincronização do Git. Este artigo, no entanto, não é influenciado pelo UXPin de forma alguma e expressa a opinião independente do autor. Obrigado!

Nos últimos dois anos, não é segredo que nossas ferramentas de design evoluíram exponencialmente. Com muitos tendo um ótimo gerenciamento de componentes e prototipagem, você pode estar se perguntando qual grande salto poderia ser o próximo?

Vejamos um dilema típico:

Digamos que você seja um designer para a equipe de sistemas de design onde está criando componentes, variantes e gastando muitas horas para documentar todos os casos de uso e propriedades que podem ou não ser alterados. Você finalmente finaliza um componente grande e complexo e o entrega aos desenvolvedores.

Como sabemos que o código é a mesma interface do usuário? Nós realmente precisamos auditar cada componente? Como podemos preencher essa lacuna entre o que é projetado e o que é desenvolvido sem a sobrecarga de fazer revisões constantemente?

Tudo isso e você tem que ajudar a ensinar as pessoas as diferentes maneiras de usar componentes , espaçamentos adequados e design para web responsivo e, claro, o componente precisará ser atualizado para casos de uso futuros.

Há tantos pontos de contato, pessoas envolvidas. Quase parece que quanto mais avançamos nos sistemas de design, mais sobrecarga há para todos! Agora, parece que uma luz no fim do túnel está brilhando, e a próxima grande coisa está a caminho.

Uma jóia escondida em todo o caos

Recentemente, tive a oportunidade de revisitar uma ferramenta que não usava há algum tempo - uma ferramenta que visa preencher essa lacuna e minimizar toda essa sobrecarga: UXPin. Um novo recurso chamado “Merge” foi lançado para ajudar a romper os abismos de design e desenvolvimento, ao mesmo tempo em que melhora a agilidade e a qualidade que nossas equipes esperam. Essa nova tecnologia pode fazer com que alguns repensem como equipes inteiras de design e engenharia colaboram e trabalham por meio de casos de uso e componentes de construção.

Fora com o processo antigo

Se olharmos para o processo atual que a maioria das empresas emprega hoje, pode ser bastante tedioso com algumas falhas óbvias . Quando criamos um novo componente do zero, projetamos o nível básico do componente, adicionamos variantes, escrevemos documentação, publicamos na biblioteca e entregamos aos desenvolvedores. Listar o processo é demorado, mas felizmente só precisa ser feito uma vez (esperamos):

Agora, o que acontece quando precisamos atualizar um componente? Um novo caso de uso chegou, ou talvez tenhamos decidido mudar nossas bordas de arredondadas para nítidas? Agora precisamos adicionar as variantes à biblioteca, (possivelmente) atualizar a documentação novamente, publicá-la e entregá-la aos nossos desenvolvedores. Ufa! Vamos torcer para que nada tenha quebrado ao longo do caminho para nossos designers com toda essa reorganização do componente.

Quase esqueci, ainda precisamos publicar as atualizações na biblioteca de desenvolvimento! Vamos torcer para que eles possam terminar antes que as equipes de produto sigam seu próprio caminho para cumprir os prazos.

Com o novo processo

Então, você pode estar se perguntando, como a tecnologia do UXPin Merge ajuda com esse processo exagerado que todos nós empregamos hoje? Bem, dê uma olhada no diagrama abaixo. Você pode notar que a criação de um componente e variantes não são necessárias (na maioria dos casos). Esse novo processo reduz a quantidade de problemas com ferramentas de layout automático, devido ao nosso relacionamento agora sinergizado com os desenvolvedores:

Precisamos apenas projetar o nível de detalhe necessário para documentação e implementação. Componentes simples, como um botão ou outros componentes de nível atômico, podem não precisar ser projetados. Por que desperdiçar seu tempo fazendo o dobro do trabalho quando o desenvolvimento pode começar imediatamente com pouca sobrecarga? De certa forma, fechamos o círculo; estamos retornando aos modos antigos quando os componentes estáticos exibiam apenas algumas interações na documentação.

Observe que a publicação na biblioteca está agora no final do processo. Isso porque, uma vez que o desenvolvedor termina com o componente, ele agora pode utilizar o Merge para disponibilizá-lo para designers no UXPin e, claro, todos os seus desenvolvedores de produtos o têm ao mesmo tempo!

Ao atualizar componentes, é essencialmente o mesmo que um novo, exceto que pode até ser possível pular a primeira etapa, dependendo do cenário. Por exemplo, digamos que você queira adicionar uma opção para adicionar um ícone aos botões; isso não é algo que precisa ser projetado, mas, em vez disso, precisa ser comunicado aos seus novos melhores amigos em desenvolvimento.

Embora esse novo relacionamento se forme com seus desenvolvedores, a nova maneira de lançar oficialmente componentes para designers pode ser somente após o lançamento pelos desenvolvedores. Longe vão os dias de designers de produtos perguntando se um componente está disponível para seus desenvolvedores de produtos. Se estiver na biblioteca, estará disponível em desenvolvimento e pronto para os designers trabalharem imediatamente.

Mas o suficiente sobre o processo. Vamos dar uma olhada em como o UXPin Merge funciona.

Gerenciando Bibliotecas

A melhor parte é que as bibliotecas podem ser importadas diretamente do seu repositório de código, como GitHub, Bitbucket, GitLab (funciona apenas para componentes React) ou até mesmo do Storybook. Uma vez que uma biblioteca é criada, você terá opções para nomear a biblioteca.

Ao importar com o Storybook, o processo é bastante simples. Basta pegar o URL da biblioteca e o UXPin fará o resto por você. Com os componentes React, usando a CLI, você tem controle sobre os componentes que são publicados especificando o token exclusivo da biblioteca UXPin.

Controle e teste de versão

Uma das maiores preocupações entre designers e equipes de sistemas de design é o controle de versão. A maioria das preocupações pode ser resolvida com o recurso Merge do UXPin. Vamos pintar uma imagem rápida:

Hoje, quando decidimos atualizar um componente, sempre existe o medo de quebrar um componente ou camadas que podem ser renomeadas e limpas. Uma reestruturação total do componente pode até ocorrer, o que muitas vezes leva à ansiedade (do lado do designer) sobre se eles devem atualizar um componente ou manter o antigo.

No entanto, quando um componente é desenvolvido, desde que as propriedades permaneçam as mesmas, não importa como o layout do componente muda ou a marcação real do componente. Isso, por sua vez, permite que os projetistas atualizem seus componentes para as versões mais recentes com confiança.

Claro, no raro instante em que um componente fica totalmente estragado, assim como em qualquer projeto de codificação, ele pode ser facilmente revertido e republicado a versão antiga do componente.

Atualizações de teste

Ao testar novos componentes ou atualizações, hoje não é tão fácil. Obviamente, não podemos editar a biblioteca de design existente para testar, pois isso pode ser publicado acidentalmente e bloquear quaisquer outras atualizações que estejam prontas para serem lançadas. Também é muito complicado criar um componente em um novo arquivo, testá-lo e tentar lidar com a mesclagem de volta para a biblioteca atual sem quebrar as camadas.

Felizmente para nós, os desenvolvedores descobriram esse problema há muito tempo e ele se encaixa perfeitamente na tecnologia Merge do UXPin. Ao testar novos componentes, já é uma prática recomendada bifurcar ou ramificar o código , e essa nova ramificação pode ser publicada em um ambiente de teste no UXPin. Sua equipe pode testá-lo ou você pode conceder acesso a um pequeno grupo de testadores beta em sua empresa. Uma vez que o componente tenha sido testado e testado, o componente pode ser rapidamente introduzido e publicado na biblioteca de projeto principal sem um ponto.

Projetando com código

Então, como os membros da nossa equipe projetam e o que essa tecnologia significa para eles? Bem, que bom que você perguntou! Do ponto de vista de um designer de produto - não há muita diferença. Quando um designer usa um componente da biblioteca de desenvolvimento utilizando Merge, ele será marcado com um hexágono laranja para cada componente. Qualquer coisa nova continuará se comportando exatamente da mesma forma que a biblioteca do desenvolvedor.

Componentes dos desenvolvedores podem ter restrições definidas, mas no bom sentido. Um problema comum geralmente é usar ícones como links em vez de envolver o ícone em um componente de botão. Se usarmos apenas um ícone da biblioteca, ele fica bloqueado e o usuário não pode adicionar interações:

Como alternativa, o botão do ícone abaixo permite interações. Isso nos permite realmente refinar e controlar quais componentes devem interagir e quais não devem; tanto do ponto de vista dos padrões quanto da acessibilidade.

Com esses tipos de restrições, fica mais fácil para a equipe de Design Systems que os componentes terão que ser usados ​​de maneira adequada e, se forem substituídos, será óbvio no painel de camadas que algo foi feito sob medida.

Não interferir

Quando você estiver pronto para entregar aos desenvolvedores, o protótipo finalizado poderá exibir cada componente e sua configuração para copiar e colar nas ferramentas do desenvolvedor e construir rapidamente o projeto . Se sua equipe ainda não possui uma biblioteca de componentes, o UXPin vem com uma biblioteca padrão ou você pode importar facilmente algumas das bibliotecas públicas disponíveis diretamente no UXPin.

Acessibilidade

Falando em acessibilidade, muitas vezes ela é esquecida ou não há tempo suficiente para criar documentação em todos os meta rótulos, tags aria e assim por diante. Os designers não sabem quais tags precisam inserir e os desenvolvedores não querem passar pelo incômodo.

Com o UXPin, podemos expor várias propriedades , mesmo dados de meta-nível que podem nunca ser visíveis para a interface, como os rótulos ARIA. Os designers podem inserir todas as informações necessárias (ou um redator, se você tiver a sorte de ter um em sua equipe), e haverá pouca ou nenhuma sobrecarga para os desenvolvedores de produtos implementarem.

Layouts, modelos e grades

Apenas lendo o título, você sabe o que está por vir, e tenho certeza que você está pulando em sua cadeira agora – eu sei que estou. Grades, layouts e até mesmo modelos de página podem ser inseridos na biblioteca como um 'componente' que permite aos usuários trazer componentes para a área ativa de uma página e permitir que todo o espaçamento seja tratado pela biblioteca de desenvolvimento.

Modelos comuns (por exemplo, telas de login, páginas de preenchimento, formulários, páginas de perfil e assim por diante) também podem ser utilizados como um componente de arrastar e soltar. Fale sobre acelerar o processo e reduzir o erro humano no projeto !

Em Fechamento

Se você está pronto para dar o salto, nunca é tarde demais para experimentar novos softwares e novos processos para melhorar seu fluxo de trabalho. Afinal, todos nós queremos ser ágeis e o mais adotivos possível. Vamos construir relacionamentos mais fortes em nossas equipes, reduzir nossa carga de trabalho e trabalhar com mais eficiência. Com ferramentas como o UXPin Merge, nos aproximamos de um ambiente de trabalho muito mais integrado.