Um guia rápido para sistemas de design

Nós da Infragistics realizamos uma pesquisa com 388 desenvolvedores que participaram de nossos webinars mais recentes e descobrimos que apenas cerca de 26% deles trabalham com uma equipe de design – deixando mais de 3 em cada 4 desenvolvedores também atuando como designers de interface do usuário. Pouco mais de 70% dos desenvolvedores também dizem que trabalhar com HTML/CSS e projetar telas é o maior desafio em termos de criação de aplicativos da web, o que os retarda e complica ainda mais o processo.

Com a interface do usuário (UI) representando 60% do tempo de desenvolvimento de aplicativos, a chance de erros durante as transferências de designer para desenvolvedor é enorme e pode custar um fator de 10x depois que um aplicativo é implantado. Os problemas que as equipes costumam encontrar são interrupções comportamentais e visuais, discrepâncias de marca, usabilidade ruim, padrões de design mal comunicados e outras inconsistências no ciclo de design e desenvolvimento do produto. Outras vezes, há o momento de falha que surge em algum lugar entre o momento de construir um sistema de design e implementá-lo adequadamente.

No entanto, com um sistema de design em vigor, a criação do aplicativo ocorre sem problemas, reduzindo o retrabalho caro e evitável que impede que os aplicativos cheguem ao mercado rapidamente.

Antes de mergulhar nos sistemas de design, vamos revisar como os artefatos de colaboração entre design e desenvolvimento progrediram. Podemos classificar isso amplamente em quatro níveis:

• Nível 1: Especificações visuais estáticas
• Nível 2: Especificações visuais interativas (inspecionar)
• Nível 3: Especificações visuais vinculadas aos componentes da interface do usuário (Design Systems)
• Nível 4: Gerando aplicativo a partir de especificações de design (Design Systems +)

Para todos os níveis, podemos supor que alguma forma de atividade de design precedeu o desenvolvimento. Ou seja, as especificações para as interfaces do usuário e fluxos são criadas antes do desenvolvimento.

Nível 1: Especificações visuais estáticas

Essa forma de comunicação de design e desenvolvimento é mais comum. Nesse nível, as maquetes visuais são criadas usando ferramentas usadas por designers visuais (por exemplo, Sketch, Adobe XD). As especificações de estilos, layout, dimensionamento, etc., são adicionadas como anotações no topo das simulações para revisão.

Os desenvolvedores consultam esta documentação como parte de seu processo de desenvolvimento e a implementam manualmente no código. Essa abordagem é adequada para projetos únicos personalizados que não precisam ser mantidos.

Nível 2: Especificações visuais interativas (Inspecionar)

Nesse nível, a equipe de design visual ainda está compartilhando maquetes e guias de estilo com os desenvolvedores, mas em vez de um documento estático, eles contam com ferramentas para fornecer as especificações em um formato mais acessível. Usando ferramentas como Zeplin.io, os designers podem fazer upload de seus designs sem se esforçar para marcar os designs e os desenvolvedores podem visualizar os designs no navegador. Mais importante, à medida que clicam no design, os desenvolvedores podem visualizar as especificações sob demanda e em um formato que se alinhe com sua plataforma de destino (por exemplo, HTML, CSS).

O principal benefício dessa abordagem é que os designers não precisam se preocupar com a adição manual de anotações, e os desenvolvedores ainda podem extrair ativos e especificações para qualquer parte da interface do usuário. No entanto, ele não está vinculado a nenhum componente de software usado pela organização.

Nível 3: Especificações visuais vinculadas aos componentes da interface do usuário

Nesse nível, podemos esperar que o design tenha colaborado com o desenvolvimento para criar um inventário de estilos, layouts e componentes de interface do usuário que atendam às suas necessidades; Em outras palavras, eles delinearam um sistema de design.

Aqui, as equipes de design criam designs usando um kit de interface do usuário padronizado que reflete o sistema de design. Kit de interface do usuário é um nome comum dado a uma coleção de elementos de design visual reutilizáveis criados usando a própria ferramenta de design (por exemplo, Sketch ou Adobe XD) que corresponde aos componentes em sua base de código. Isso torna mais fácil para a equipe de desenvolvimento implementar os designs porque já existem componentes de interface do usuário correspondentes.

Com essa abordagem, os desenvolvedores ainda precisarão escrever código de interface do usuário para estruturar o aplicativo, criar os layouts e configurar ainda mais os componentes para corresponder às especificações. Como a implementação faz uso de componentes do sistema de design acordados, ela reduz o potencial de falhas de comunicação. Soluções como o Storybook possibilitam vincular componentes do kit de interface do usuário ao kit de ferramentas do componente do desenvolvedor. Esse tipo de integração está ganhando popularidade entre as equipes de software para documentar o kit de ferramentas do desenvolvedor.

No entanto, o maior problema é que nem todas as organizações investiram em um sistema de design. Portanto, esse grau de colaboração é aspiracional para a maioria. Além disso, essa colaboração está focada na reutilização de componentes do sistema de design ou tokens de design. Os desenvolvedores ainda precisarão configurar cada componente e implementar a interface do usuário, que será aprovada pela equipe de design.

Nível 3: Especificações visuais vinculadas aos componentes da interface do usuário

Um sistema de design pode ajudar as equipes de design e desenvolvimento a padronizar em torno de um conjunto comum de blocos de construção. No entanto, os artefatos criados como parte da entrega (ou seja, entrega de design) podem se tornar uma fonte de ineficiência. Conforme descrito na seção anterior, o esforço desperdiçado pode ser atribuído à equipe de desenvolvimento que precisa implementar os designs. Mais especificamente, configurar componentes e recriar os layouts.

Algumas organizações ainda tendem a usar frameworks antigos e chegam a um ponto em que devem migrar para Blazor ou Angular. Mas fazer isso e, ao mesmo tempo, tentar acelerar o tempo de lançamento no mercado exige uma solução mais radical. Criar especificações com base em um sistema de design e incluí-las como artefatos de transferência é uma maneira de lidar com isso. No entanto, esses projetos também devem superar outros desafios que não se limitam ao seguinte:

• Pesquise e arquitete um sistema de design (ou seja, blocos de construção acordados)
• Construindo e mantendo uma biblioteca de componentes que corresponda ao sistema de design
• Familiarize-se com a plataforma de destino (por exemplo, Angular) e incorpore as melhores práticas.
• Crie a documentação necessária para o desenvolvedor para auxiliar durante o desenvolvimento
• Certifique-se de que o aplicativo corresponda exatamente às especificações visuais (layouts + temas)

Soluções como App Builder ™ visam substituir o tipo tradicional de transferência, conforme descrito na seção anterior (consulte o Nível 3). Em vez de compartilhar um documento de especificação ou maquete, os desenvolvedores recebem um aplicativo baseado em especificações de design já realizadas. Isso elimina a necessidade de inspecionar e extrair peças de especificação e reimplementar os projetos.

Usando a abordagem Indigo.Design, os designers criam seus modelos usando o kit de interface do usuário do Indigo.Design. Este kit de interface do usuário fornece aos designers uma versão do sistema de design em um formato adequado para a ferramenta de design (por exemplo, Adobe XD, Figma ou Sketch). Isso permite que os designers criem os layouts de tela e configurem os componentes de acordo com o que o sistema de design permite.

Quando a maquete estiver concluída, os usuários poderão publicar seus designs como um aplicativo usando o plug-in Indigo.Design. O plug-in converte automaticamente os arquivos de design estático em um aplicativo que pode ser editado usando um editor WYISWYG baseado em nuvem. Este editor permite que os desenvolvedores continuem editando o aplicativo antes de baixar todo o código-fonte do aplicativo.

Os principais recursos do App Builder que dão suporte à história de design em escala incluem:

• Shell e exibições do aplicativo de andaimes para plataformas Angular e Blazor
• Roteamento e navegação de aplicativos
• Layouts da Web
• Temas e tokens globais
• Vinculação de dados usando fontes da API REST
• Integração com o GitHub para continuar o desenvolvimento

Agora que temos uma ideia melhor de onde um sistema de design se encaixa na história do design ao desenvolvimento, vamos ver como ele está estruturado.

Um sistema de design usa uma abordagem para construir elementos escaláveis que podem ser melhor ilustrados como átomos, moléculas e organismos. É referido como a Metodologia de Design Atômico; criado por Brad Frost. Tornou-se uma abordagem popular para descrever a estrutura de um sistema de design.

Voltando à metáfora de átomos, moléculas e organismos, você começa projetando o menor componente (por exemplo, botão, avatar, rótulo, cabeçalho etc.). Este menor componente é chamado de átomo.

Indo um nível mais fundo, os átomos consistem em partículas como núcleo, prótons e nêutrons. Para um sistema de design, isso pode ser mapeado para a paleta de cores e tipografia base, que define a identidade da marca para a organização.

Subindo um nível dos átomos, você tem moléculas compostas de átomos. As moléculas podem ser mapeadas para componentes e representam estruturas mais complexas, como item de menu, item de lista, item suspenso.

Então, combinando layouts e vários componentes, obtemos a próxima unidade hierárquica – padrões de UX; ou aderindo à nossa comparação biológica - organismos. Eles encapsulam as melhores práticas em UX seguindo "bons" princípios de design e são construídos para as necessidades específicas de um produto.

O objetivo de ilustrar sistemas de design como átomos, moléculas e organismos é traçar paralelos com um sistema vivo. Um sistema de design não deve ser estático e nunca mudar – ele deve refletir as necessidades de UX do produto e evoluir constantemente, com o produto e as tecnologias utilizadas. Novos requisitos surgem devido a novos requisitos de layout de dispositivos, novos recursos de produtos e mudanças de identidade de marca são inevitáveis, e devemos ter certeza de que nosso Sistema de Design é flexível e pronto para mudar para que possamos nos adaptar a essas mudanças.

UX padronizado

Um dos maiores benefícios de um sistema de design é preservar a consistência em torno de diferentes dispositivos, produtos e subprodutos, bem como coordenar com marketing e branding.

Uma fonte comum de inconsistência é quando diferentes desenvolvedores e designers estão envolvidos no desenvolvimento do produto. Acrescente a isso a crescente natureza descentralizada do trabalho, em todos os fusos horários, torna caro fazer 1-1 avaliações. Com um sistema de design em vigor, designers e desenvolvedores podem trabalhar de forma independente em suas próprias ferramentas sem exigir verificações de baixo nível em torno da implementação do design. Em vez disso, eles podem se concentrar em interações de alto valor em torno dos resultados.

Do ponto de vista do cliente, a consistência significativa entre os aplicativos oferecidos pela mesma organização permite que os usuários reutilizem os aprendizados de suas interações anteriores com os aplicativos.

Como diz Diana Mounter, do GitHub:

"Os sistemas de design trazem ordem ao caos. Todos são mantidos na mesma página, para que todo o produto permaneça consistente e polido por toda parte.Os sistemas de design melhoram a experiência do usuário por meio do uso repetido de padrões familiares e comprovados. Projetar qualquer coisa do zero deixa espaço para erros, então tente usar o que já funciona.Os sistemas de design melhoram a eficiência do fluxo de trabalho - as equipes de produto sabem exatamente como os componentes dos novos recursos devem ser e como implementá-los."

Vocabulário compartilhado entre design e desenvolvimento

Embora a consistência seja uma grande vitória, algo tão simples quanto nomear componentes e padrões mutuamente acordados pode ajudar muito. Isso é útil para os usuários atuais do sistema de design e para a integração de futuros membros. Tornar a convenção de nomenclatura explícita e compartilhada torna mais fácil para desenvolvedores e designers encontrar os componentes em seus respectivos ambientes de ferramentas.

Com o tempo, os nomes dos padrões de UX começarão a aparecer nas conversas, servindo como um substituto para os requisitos do usuário. Por exemplo, quando alguém menciona que devemos usar um componente de caixa de combinação, fica claro para designers e desenvolvedores que tipo de comportamento ele suporta e como ele pode se adequar ao objetivo da experiência. Como um sistema de design documenta um componente como um padrão, ele geralmente explica quando usar um componente específico e como usá-lo da maneira correta com exemplos. Então, nesse sentido, um sistema de design pode atender à necessidade de orientação de UX acessível, evangelizando assim as práticas de design.

Acelere o processo de design e desenvolvimento

A velocidade de entrega é um benefício explícito da reutilização de componentes em um sistema de design. Do ponto de vista do design, as eficiências vêm de não precisar criar novos componentes ou padrões, pois eles já fazem parte dos kits de interface do usuário do sistema de design. Mesmo quando confrontados com a necessidade de criar um novo padrão complexo, os projetistas podem confiar nas diretrizes do sistema de design e construir algo usando os "átomos" ou "moléculas" já disponíveis. Do ponto de vista do desenvolvedor, ser capaz de gerar o código para esse componente ou padrão ajuda a evitar inconsistência entre as especificações de design e o código.

A velocidade de aprendizado é um benefício não tão óbvio do uso de uma abordagem de sistema de design. Agora que os designers estão livres da criação de pixels, eles podem retornar ao verdadeiro processo de design, concentrando-se em projetar jornadas ou fluxos do usuário e avaliá-los com os usuários. A abordagem usada para criar entregas de design também pode ser usada para protótipos provisórios de produtos para [teste de usabilidade](#) e [obtenção de feedback das partes interessadas](#).

Qual ferramenta de design você usa?

Os processos de design às vezes são mais complexos, dispersos e caóticos do que deveriam ser. Nesses casos, eles exigem um sistema de design como uma função estratégica e como um instrumento para melhorar a colaboração. Como discutimos, um sistema de design serve como uma espécie de conhecimento comum que pode ajudar a alinhar design e desenvolvimento. É um fórum onde as equipes podem codificar (o máximo que puderem) as melhores práticas. E como é suposto ser um sistema vivo, também oferece oportunidades para que novos padrões, requisitos e até soluções de geração de código (como o uso de criadores de aplicativos low-code ao longo do processo) sejam discutidos e depois absorvidos. Mais importante, um sistema de design não é apenas um repositório, mas é uma forma de colaborar. Não é uma bala de prata para os desafios enfrentados por designers e desenvolvedores ao colaborar. Nem a existência de um sistema de design impede uma conversa significativa entre as duas disciplinas.

O maior desafio para muitas empresas é começar com uma abordagem de sistemas de design relevante que ressoe com suas necessidades e a transformação digital contínua ao mesmo tempo. Para alguns, que já têm uma grande variedade de aplicativos em estado selvagem, a fase inicial é tediosa. Embora existam vários sistemas de design disponíveis para referência, cada um foi criado para sua própria organização pai. Ao mesmo tempo, eles também compartilham muito em comum em termos de padrões de UX e melhores práticas. Há uma necessidade de ferramentas e serviços, então, para ajudar as organizações a criar rapidamente seu próprio sistema de design, e não copiar cegamente.

O tipo de processo simplificado e consistência de que falamos pode ser alcançado por meio de automações e plug-ins que, por exemplo, permitem aplicar um tema abrangente à sua biblioteca de design de uma só vez. Isso também significa permitir abordagens inovadoras e muito mais eficientes para lidar com a transferência de designer-desenvolvedor, economizando tempo e energia tentando explicar ideias ou justificar animações e microinterações que geralmente não estão nos arquivos Sketch, Adobe XD e Figma.

No cenário altamente digitalizado, então, o uso de ferramentas como App Builder se torna a espinha dorsal de um sistema de design funcional e eficaz para equipes e empresas. Para ilustrar melhor como ele altera positivamente o design e o desenvolvimento, aqui está o que App Builder faz:

• Adiciona ao Material UI Kit com UI Kits para Bootstrap, Fluent e Indigo. Isso dá às equipes de design a capacidade de direcionar qualquer sistema de design popular, personalizável para os temas, partes da tela e padrões de interface do usuário que são transferidos perfeitamente para App Builder para aplicativos perfeitos em pixels e geração de código para Angular ou Blazor.
• Toneladas de controles e recursos de geração de código - desde controles de navegação e vinculados a dados até a geração de código para aplicativos Blazor e Angular.
• Modelos de aplicativos e layouts de tela – Para iniciar o design do aplicativo e ajudar a criar páginas responsivas com um único clique. Eles aliviam a parte mais difícil do desenvolvimento de aplicativos para os desenvolvedores - codificar manualmente CSS responsivo para a web e criar layouts complexos e interativos com controles de interface do usuário reais vinculados a dados reais.

É importante observar que um sistema de design não é apenas as melhores práticas de UX e kits de interface do usuário. Você também precisa de componentes de interface do usuário correspondentes no lado do desenvolvimento. Embora o movimento de sistemas de design tenha sido tradicionalmente defendido por equipes de design em grandes organizações, para que seja realmente bem-sucedido, a equipe de desenvolvimento também precisa se tornar um coproprietário/colaborador do sistema de design.

Além disso, a estrutura átomos-moléculas-organismos é apenas o ponto de partida para sistemas de design, mas não precisa parar por aí. Ele pode conter informações adicionais sobre como os aplicativos devem se comportar. A seguir está uma lista de possíveis candidatos para inclusão em um sistema de design, que de forma alguma é exaustiva:

• As diretrizes de design de interação descrevem como os usuários interagirão com os aplicativos, seja controlado por gestos, mouse e teclado. Ele descreve o que fazer e o que não fazer. O design de materiais do Google faz isso muito bem.
• Movimento e transições estão se tornando cada vez mais comuns para fornecer um nível de dinamismo e prazer ao usar aplicativos. No entanto, embora possamos entender algumas das transições isoladamente, é bom padronizá-las para os aplicativos (por exemplo, transição de slides para transição mestre-detalhe).
• As histórias de usuários podem ajudar a documentar como algumas das tarefas comuns ou especializadas foram realizadas no aplicativo. Pode servir de inspiração para novos designs.
• Aplicativos de referência que mostram como as diferentes partes de um sistema de design podem trabalhar juntas

Construir, usar e manter um sistema de design, então, leva a experiências mais coerentes porque não há necessidade de reconstruir componentes ou padrões. Em vez disso, designers e desenvolvedores se beneficiam de um inventário unificado que promove a reutilização e oferece ativos de design flexíveis, economizando tempo e esforços ao projetá-los do zero. O futuro dos sistemas de design também dita práticas que regem padrões claros e conformidade prática da marca por meio de tipografia, cores, voz e tom consistentes.

Mas há algo mais - o sistema de design bem-sucedido de hoje também requer uma mudança cultural comum e uma mentalidade diferente que:

• Cultiva a funcionalidade cruzada, incluindo designers e desenvolvedores para canalizar melhor ideias e resultados, melhorar a qualidade do produto final e aumentar o impacto que as equipes geram juntas.
• Dá as boas-vindas a ferramentas, sistemas e serviços como App Builder práticas de UI e UX já estabelecidas para aprimorar roteiros, eliminar silos, reduzir tarefas repetitivas, ajudar a estabelecer uma única fonte de verdade e aumentar a velocidade e a qualidade do design e desenvolvimento de produtos digitais.

Além de ajudar as equipes a implementar uma arquitetura sólida e preparada para o futuro de um sistema de design, economiza tempo e esforços e permite que os designers se concentrem no design real.

• O que Indigo.Design diferencia:
• Possui kits de interface do usuário de terceiros que seguem exatamente o mesmo sistema de design para todas as tecnologias, o que significa que os designers podem até mesmo alternar sua ferramenta de escolha enquanto ainda podem projetar com símbolos fornecidos por nós para a ferramenta específica.
• Representa uma biblioteca nativa para Sketch e Adobe XD (em breve para Figma) utilizando os metadados por trás dos símbolos do kit de interface do usuário, a fim de trazer as telas projetadas para o App Builder e visualizá-las em termos de componentes reais.
• Ele não apenas fornece componentes com estados, mas também modelos e variantes que se ajustam automaticamente à medida que o usuário do sistema de projeto altera a configuração de um componente.
• Funciona com o App Builder para criar componentes reais na web.
• Abstrai uma maneira de definir a estrutura do aplicativo, visualizações e interações.
• Permite que você tenha um mesmo aplicativo em diferentes tecnologias.
• Pega um design, torna-o compreensível para o App Builder e permite a visualização e a geração de código para Angular ou Blazor (Web Components e React em breve).
• Define padrões comuns entre tecnologias.
• Gerado por analisadores de ferramentas de design sobre os kits de interface do usuário, o App Builder ou outros plug-ins de terceiros.
• Possui mecanismos poderosos para temas, marca, e outras opções de personalização.
• Implementa variantes distintas para Material, Bootstrap e Fluent que se parecem com essas estruturas.