Tutorial de Design Systems e Os Benefícios de Usar Um – Indigo.Design

Obtenha a Visão Geral Mais Essencial Sobre Sistemas de Design e as Necessidades de Colaboração entre Design e Desenvolvimento

Usar e construir um sistema de design não é algo novo. O que é novo, porém, é como você o usa e onde o aplica. Faça isso corretamente e você poderá executar melhor os processos em escala – design de produto e transição a partir de designs do Sketch ou Figma, design de UX, handoffs, testes de usuário, desenvolvimento front-end.

Com nosso RefCard de Sistemas de Design, você terá uma visão aprofundada sobre sistemas de design para percebê-los como algo mais do que um inventário deliberado de padrões de UX reutilizáveis e diretrizes de estilo de marca. Você também entenderá o que precisa ser feito no seu cenário de design-desenvolvimento para trazer uma experiência coerente e alinhamento no processo de design-para-código entre equipes multifuncionais.

Leia o RefCard hoje mesmo para aprender sobre:

• A Importância dos “Empoderamentos de Design”: Reduzindo retrabalho custoso e evitável.

• O Que É um Sistema de Design: Indo além de “uma coleção de ativos de design”, ele engloba conceitos de uso de ferramentas ponta a ponta que levam as equipes do design ao código mais rapidamente.

• Os 4 Estágios de Colaboração Entre Design e Desenvolvimento: Desde a troca de mockups e guias de estilo até a geração de componentes específicos de design com o uso de ferramentas como o App Builder.

• A Anatomia de um Sistema de Design: Comparável a átomos, moléculas e organismos, um sistema de design muda para refletir necessidades específicas de UX tendo em mente o produto e as ferramentas.

• Mais Benefícios do Sistema de Design: Ajudando empresas a escalar rapidamente sem necessariamente escalar a equipe de desenvolvimento de design e reduzindo o custo e o tempo para entregar aplicativos completos.

• O Futuro dos Sistemas de Design: Seu potencial para se integrar facilmente com ferramentas de automação de desenvolvimento de produtos digitais e DevOps, convidando desenvolvedores desde os primeiros estágios.

• O App Builder™ em Poucas Palavras: Permitindo que as equipes estabeleçam uma arquitetura sólida e à prova de futuro de um sistema de design, ele economiza tempo e esforço.

Introdução

Design e desenvolvimento continuam sendo as disciplinas funcionais centrais dentro do desenvolvimento de produtos de software, mas o problema é que, na maioria das vezes, eles evoluem por conta própria. Enquanto, na realidade, a complexidade e a escassez de tempo por trás da construção de aplicativos modernos funcionam como um teste de realidade que exige uma única fonte de verdade que seja igualmente benéfica tanto para designers quanto para desenvolvedores.

No entanto, usar e construir um sistema de design não é algo novo. O que é novo é como você o usa e onde o aplica. Faça isso corretamente e você poderá executar melhor os processos em escala – design de produto e transição a partir de designs do Sketch ou Figma, design de UX, handoffs, testes de usuário, desenvolvimento front-end.

Do ponto de vista do sucesso empresarial, as empresas reconhecem a necessidade de entregar uma UX atraente em seus aplicativos [#]. No entanto, entregar uma UX atraente requer um alto grau de colaboração entre design e desenvolvimento. E esse nível de colaboração pode se mostrar caro dada a natureza remota e distribuída do trabalho moderno. O custo de entregar UX também é agravado por outros fatores, como o esforço necessário para comunicar a intenção do design e para transformar especificações visuais em código, para citar alguns. A menos que consigamos reduzir esses custos, pode ser inviável entregar uma UX atraente mesmo para as empresas mais dispostas.

Nos últimos anos, os sistemas de design surgiram como uma solução para melhorar a colaboração entre design e desenvolvimento. A abordagem de sistema de design foi adotada por organizações como Salesforce.com, IBM, Atlassian, entre outras, e serve como um testemunho de seu apelo.

Mas existe essa definição popular de que um sistema de design é uma coleção de ativos de design que você usa para construir interfaces de usuário. Em termos simples, sim, ele representa um inventário de padrões de UX e um guia de estilo de marca que são realizados como componentes de software correspondentes que podem ser reutilizados ou contextualizados para a construção de aplicativos de software. De uma perspectiva mais ampla, os sistemas de design são muito mais do que bibliotecas de componentes de UI reutilizáveis. Eles são “empoderamentos de design” feitos sob medida que:

• Servem como fonte única de verdade para as equipes de produto.

• Se ajustam a um contexto de uso específico e domínio de aplicativo.

• Aceleram o processo de design e melhoram significativamente a consistência.

Eles também podem ser estendidos para conter orientações de voz e tom para escrita de conteúdo, modelos de página e até fluxos de usuário, mas de uma forma que é artesanal para o domínio de aplicativo e contexto de uso específico de cada organização.

Para entender tudo isso, aqui está o que revisaremos neste artigo:

• A importância dos “empoderamentos de design”

• Estágios da colaboração entre design e desenvolvimento

• A anatomia de um sistema de design

• Benefícios de usar um sistema de design

• O futuro dos sistemas de design se entrelaça com automação e ferramentas low-code

• App Builder em poucas palavras

Sistemas de Design vistos como “empoderamentos de design”

Nós, na Infragistics, conduzimos uma pesquisa entre 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 UI. Pouco mais de 70% dos desenvolvedores também dizem que trabalhar com HTML/CSS e projetar telas é o maior desafio em termos de construção de aplicativos web, o que os atrasa e complica ainda mais o processo.

Com a interface de usuário (UI) representando 60% do tempo de desenvolvimento de aplicativos, a chance de erros durante os handoffs de designer para desenvolvedor é enorme e pode custar um fator de 10x uma vez que um aplicativo é implantado. Os problemas que as equipes frequentemente encontram são interrupções comportamentais e visuais, discrepâncias de marca, baixa usabilidade, padrões de design mal comunicados e outras inconsistências no ciclo de design e desenvolvimento de produtos. Em outras ocasiões, há o momento de falha que surge em algum ponto entre a construção de um sistema de design e sua implementação adequada.

No entanto, com um sistema de design em vigor, a criação do aplicativo flui com muito mais suavidade, reduzindo o retrabalho custoso e evitável que impede que os aplicativos cheguem ao mercado rapidamente.

Estágios em evolução da colaboração entre design e desenvolvimento

Antes de mergulharmos 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 (inspeção)

• Nível 3: Especificações visuais vinculadas a componentes de UI (Sistemas de Design)

• Nível 4: Geração de aplicativo a partir de especificações de design (Sistemas de Design +)

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

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

Essa forma de comunicação entre design e desenvolvimento é a mais comum. Nesse nível, mockups visuais são criados usando ferramentas utilizadas por designers visuais (por exemplo, Sketch e Figma). As especificações de estilos, layout, dimensionamento etc. são adicionadas como anotações sobre os mockups para revisão.

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

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

Nesse nível, a equipe de design visual ainda compartilha mockups e guias de estilo com os desenvolvedores, mas, em vez de um documento estático, ela conta com ferramentas para fornecer as especificações em um formato mais acessível. Usando ferramentas como o Zeplin.io, os designers podem carregar seus designs sem o esforço de marcá-los, e os desenvolvedores podem visualizar os designs no navegador. Mais importante ainda, ao clicarem no design, os desenvolvedores podem visualizar as especificações sob demanda, em um formato alinhado à sua plataforma de destino (por exemplo, HTML, CSS).

O principal benefício dessa abordagem é que os designers não precisam se preocupar em adicionar anotações manualmente, e os desenvolvedores ainda podem extrair ativos e especificações de qualquer parte da UI. No entanto, isso não está vinculado a nenhum componente de software usado pela organização.

Nível 3: Especificações visuais vinculadas a componentes de UI

Nesse nível, podemos esperar que o design tenha colaborado com o desenvolvimento para criar um inventário de estilos, layouts e componentes de UI 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 UI padronizado que reflete o sistema de design. Kit de UI é o 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 Figma) que correspondem a componentes em sua base de código. Isso facilita a implementação dos designs pela equipe de desenvolvimento, pois os componentes de UI correspondentes já existem.

Com essa abordagem, os desenvolvedores ainda precisarão escrever código de UI 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 previamente acordados, isso reduz o potencial de má comunicação. Soluções como o Storybook tornam possível vincular componentes do kit de UI com o toolkit de componentes do desenvolvedor. Esse tipo de integração está ganhando popularidade entre as equipes de software para documentar o toolkit do desenvolvedor.

No entanto, o problema maior é 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 se concentra na reutilização de componentes do sistema de design ou tokens de design. Os desenvolvedores ainda precisarão configurar cada componente e implementar a UI, que será então aprovada pela equipe de design.

Nível 3: Especificações visuais vinculadas a componentes de UI

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 do handoff (ou seja, o entregável de design) podem se tornar uma fonte de ineficiência. Como descrito na seção anterior, o esforço desperdiçado pode ser atribuído à equipe de desenvolvimento ter que 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 precisam migrar para o Blazor ou Angular. Mas fazer isso enquanto também tentam acelerar simultaneamente o tempo de lançamento no mercado exige uma solução mais radical. Criar especificações baseadas em um sistema de design e incluí-las como artefatos de handoff é uma forma de lidar com isso. No entanto, esses projetos também devem superar outros desafios que não se limitam aos seguintes:

• Pesquisar e arquitetar um sistema de design (ou seja, blocos de construção acordados)

• Construir e manter uma biblioteca de componentes que corresponda ao sistema de design

• Ganhar familiaridade com a plataforma de destino (por exemplo, Angular) e incorporar as melhores práticas.

• Criar documentação de desenvolvedor necessária para auxiliar durante o desenvolvimento

• Garantir que o aplicativo corresponda exatamente às especificações visuais (layouts + tematização)

Soluções como o App Builder visam substituir o tipo tradicional de handoff, conforme descrito na seção anterior (veja o Nível 3). Em vez de compartilhar um documento de especificação ou mockup, os desenvolvedores recebem um aplicativo baseado com as especificações de design já realizadas. Isso elimina a necessidade de inspecionar e extrair partes da especificação e reimplementar os designs.

Usando a abordagem low-code, os designers criam seus mockups usando o kit de UI do Indigo.Design. Esse kit de UI fornece aos designers uma versão do sistema de design em um formato adequado para a ferramenta de design (por exemplo, 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 o mockup é concluído, os usuários podem publicar seus designs como um aplicativo usando o plugin. O plugin converte automaticamente os arquivos de design estáticos em um aplicativo que pode ser editado ainda mais usando um editor WYSIWYG baseado em nuvem. Esse 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:

• Estruturação de shell de aplicativo e views para as plataformas Angular e Blazor

• Roteamento e navegação de aplicativo

• Layouts web

• Temas e tokens globais

• Vinculação de dados usando fontes de API REST

• Integração com o GitHub para continuar o desenvolvimento

A anatomia de um sistema de design

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

Um sistema de design usa uma abordagem para construir elementos escaláveis que pode ser melhor ilustrada como átomos, moléculas e organismos. É chamada de Metodologia de Design Atômico, criada por Brad Frost. Ela se tornou 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, título etc.). Esse componente minúsculo é 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 base e a tipografia, que define a identidade da marca da organização.

Subindo um nível a partir dos átomos, temos as moléculas, que são compostas de átomos. As moléculas podem ser mapeadas para componentes e representam estruturas mais complexas, como item de menu, item de lista, item de dropdown.

Depois, combinando layouts e múltiplos componentes, obtemos a próxima unidade hierárquica – padrões de UX; ou, mantendo nossa comparação biológica, organismos. Estes encapsulam as melhores práticas de UX seguindo princípios de design “bons” 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 imutável – ele deve refletir as necessidades de UX do produto e evoluir constantemente, junto com o produto e as tecnologias usadas. Novos requisitos surgem devido a novas necessidades de layout de dispositivos, novos recursos de produto, e mudanças na identidade da marca são inevitáveis, e devemos garantir que nosso Sistema de Design seja flexível e esteja pronto para mudar para que possamos nos adaptar a essas mudanças.

Benefícios de usar um sistema de design

UX padronizada

Um dos benefícios mais fortes de um sistema de design é preservar a consistência em diferentes dispositivos, produtos e subprodutos, além de se coordenar com marketing e branding.

Uma fonte comum de inconsistência ocorre quando diferentes desenvolvedores e designers estão envolvidos no desenvolvimento do produto. Some-se a isso a crescente natureza descentralizada do trabalho, através de fusos horários, o que torna caras as revisões individuais. 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. Eles podem, em vez disso, focar em interações de alto valor em torno de resultados.

De uma perspectiva puramente do cliente, a consistência significativa entre aplicativos oferecidos pela mesma organização permite que os usuários reutilizem os aprendizados de suas interações passadas com os aplicativos.

Como Diana Mounter, do GitHub, coloca:

“Os sistemas de design trazem ordem ao caos. Todos ficam alinhados, de modo que o produto inteiro permanece consistente e polido. Os sistemas de design melhoram a experiência do usuário por meio do uso repetido de padrões familiares e comprovados. Projetar algo do zero deixa margem 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 de novos recursos devem parecer e como implementá-los.“

Vocabulário compartilhado entre design e desenvolvimento

Embora a consistência seja uma grande vantagem, algo tão simples quanto uma nomenclatura mutuamente acordada para componentes e padrões pode fazer uma grande diferença. Isso é útil para os usuários atuais do sistema de design e para integrar futuros membros. Tornar a convenção de nomenclatura explícita e compartilhada facilita para desenvolvedores e designers encontrarem os componentes em seus respectivos ambientes de ferramentas.

Com o tempo, os nomes dos padrões de UX começarão a aparecer em conversas, servindo como um substituto para os requisitos do usuário. Por exemplo, quando alguém menciona que devemos usar um componente combo-box, fica claro tanto para designers quanto para desenvolvedores que tipo de comportamento ele suporta e como se encaixa nos objetivos da experiência. Como um sistema de design documenta um componente como um padrão, geralmente explica quando usar um componente específico e como usá-lo da maneira correta, com exemplos. Assim, 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. De uma perspectiva de design, as eficiências vêm do fato de não ser necessário criar novos componentes ou padrões, já que eles já fazem parte dos kits de UI do sistema de design. Mesmo diante da necessidade de criar um novo padrão complexo, os designers podem contar com as 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ências entre as especificações de design e o código.

A velocidade de aprendizado é um benefício não tão óbvio de usar uma abordagem de sistema de design. Agora que os designers estão liberados da criação pixel a pixel, eles podem retornar ao verdadeiro processo de design, focando em projetar jornadas ou fluxos de usuário e avaliá-los com os usuários. A abordagem usada para criar entregáveis de design também pode ser usada para produzir protótipos intermediários para [testes de usabilidade](#) e [obtenção de feedback das partes interessadas](#).

Paisagens em mudança ou como o futuro dos sistemas de design se entrelaça com automação e ferramentas low-code?

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 função estratégica e como 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 (tanto quanto possível) as melhores práticas. E como se supõe que seja um sistema vivo, ele 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 ainda, 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, ao mesmo tempo, com a transformação digital em curso. Para algumas, que já possuem uma ampla variedade de aplicativos em uso, a fase inicial é tediosa. Embora existam vários sistemas de design disponíveis como referência, cada um foi criado para sua própria organização de origem. Ao mesmo tempo, eles também compartilham muito em comum em termos de padrões de UX e melhores práticas. Há, então, uma necessidade de ferramentas e serviços para ajudar as organizações a criar rapidamente seu próprio sistema de design, e não simplesmente copiar cegamente.

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

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

• Adiciona ao Kit de UI Material com Kits de UI 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 de tela e padrões de UI que se transferem perfeitamente para o App Builder para aplicativos pixel-perfect e geração de código para Angular ou Blazor.

• Toneladas de controles e recursos de geração de código – de controles vinculados a dados e de navegação até geração de código para Blazor e para aplicativos Angular.

• Modelos de aplicativo e layouts de tela – Para dar início rápido ao design de aplicativos e ajudar a construir páginas responsivas em 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 UI reais vinculados a dados reais.

É importante observar que um sistema de design não é apenas melhores práticas de UX e kits de UI. Você também precisa de componentes de UI correspondentes no lado do desenvolvimento. Embora o movimento de sistemas de design tenha sido tradicionalmente liderado por equipes de design dentro de grandes organizações, para que ele realmente tenha sucesso, a equipe de desenvolvimento também precisa se tornar coproprietária/contribuinte do sistema de design.

Além disso, a estrutura átomos-moléculas-organismos é apenas o ponto de partida para os sistemas de design, mas não precisa parar por aí. Ela 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:

• A orientação de design de interação descreve como os usuários interagirão com os aplicativos, seja por gestos, mouse ou teclado. Ela delineia o que fazer e o que não fazer. O Material Design do Google faz isso muito bem.

• Movimento e transições estão se tornando cada vez mais comuns para proporcionar um nível de dinamismo e encantamento ao usar aplicativos. No entanto, embora possamos entender algumas das transições isoladamente, é bom padronizá-las para os aplicativos (por exemplo, transição de deslizamento para transição master-detail).

• Histórias de usuário podem ajudar a documentar como algumas das tarefas comuns ou especializadas foram realizadas no aplicativo. Isso pode servir de inspiração para novos designs.

• Aplicativos de referência que mostram como as diferentes partes de um sistema de design podem funcionar juntas

Construir, usar e manter um sistema de design, portanto, leva a experiências mais coerentes, pois 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 entrega ativos de design flexíveis, economizando tempo e esforço 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 de marca por meio de tipografia, cores, voz e tom consistentes.

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

• Cultiva a interfuncionalidade, incluindo tanto designers quanto desenvolvedores para melhor canalizar ideias e resultados, melhorar a qualidade do produto final e aumentar o impacto que as equipes geram juntas.

• Acolhe ferramentas, sistemas e serviços como o App Builder em torno de práticas de UI e UX já estabelecidas para aprimorar roteiros, eliminar silos, reduzir tarefas repetitivas, ajudar a estabelecer uma fonte única de verdade e aumentar a velocidade e a qualidade do design e desenvolvimento de produtos digitais.

Por que escolher o App Builder como sua solução?

Além de ajudar as equipes a estabelecer uma arquitetura sólida e à prova de futuro de um sistema de design, ele economiza tempo e esforço, e permite que os designers se concentrem no design em si.

O que diferencia o App Builder:

• Possui kits de UI de terceiros que seguem exatamente o mesmo sistema de design para todas as tecnologias, o que significa que os designers podem até trocar sua ferramenta de escolha enquanto ainda são capazes de projetar com símbolos fornecidos por nós para a ferramenta específica.

• Representa uma biblioteca nativa para Sketch e Figma, utilizando os metadados por trás dos símbolos do kit de UI, a fim de trazer as telas projetadas para o App Builder e visualizá-las em termos de componentes reais.

• Não apenas entrega componentes com estados, mas também modelos e variantes que se ajustam automaticamente conforme o usuário do sistema de design altera a configuração de um componente.

• Funciona com o App Builder para criar componentes reais na web.

• Abstrai uma forma de definir a estrutura, as views e as interações do aplicativo​.

• Permite que você tenha um mesmo aplicativo em diferentes tecnologias.

• Pega um design, torna-o compreensível para o App Builder e habilita a pré-visualização de código 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 ferramenta de design sobre os kits de UI, o App Builder, ou outros plugins de terceiros​.

• Possui mecanismos poderosos para tematização, branding e opções adicionais de personalização.

• Lança variantes distintas para Material, Bootstrap e Fluent que têm a aparência e a sensação exatas dessas estruturas.