Em março de 2025, a Southleft publicou um comparativo definitivo entre o Figma MCP oficial e o Figma Console MCP. Na época, o MCP nativo tinha 13 tools read-only. Desde então, o Figma adicionou escrita no canvas, captura de UI live, suporte a FigJam/Make, e Skills, este artigo usa como referência o artigo atualizando o que teve de novo nesses últimos 2 meses, verificado tool a tool.

A versão resumida das ferramentas

Figma MCP (Oficial) — Agora é um bridge bidirecional. Lê designs, gera código, e escreve no canvas via Remote Server. ~20 tools. REST API + cloud. Closed source. Rate limits. Será pago.

Figma Console MCP (Southleft) — Continua sendo o controle total. Executa qualquer código Plugin API, tem 60 tools dedicados, real-time awareness, batch operations, zero rate limits. Open source (MIT). Gratuito.

Architecture & Connection

Design Reading

Design Writing & Creation

Esta é a seção que mais mudou desde o artigo original. O Figma MCP Nativo agora escreve — mas de forma diferente.

A diferença fundamental: O Figma MCP Nativo escreve via um “canvas write” genérico — o agente precisa saber como construir tudo de uma vez. O Console MCP tem tools granulares para cada operação (resize, move, fill, stroke, text, clone, delete), tornando o resultado mais previsível e debugável.

Variable & Token Management

Component Management

Real-Time & Developer Features

Design-to-Code Workflow

Números finais

Quando usar qual?

Use o Figma MCP Nativo quando:

• Quer design-to-code rápido com Code Connect

• Precisa capturar UI live (localhost/staging) como layers no Figma

• Trabalha com FigJam ou Make files

• Não quer instalar nada além do setup OAuth

Use o Figma Console MCP quando:

• Precisa gerenciar o Design System (tokens, componentes, auditoria)

• Quer batch operations sem rate limits (100 variáveis por call)

• Precisa de real-time awareness (seleção, mudanças no doc)

• Desenvolve plugins para Figma

• Precisa de controle granular sobre cada operação

• Quer zero dependência de cloud e zero custo futuro

Use os dois juntos quando:

• Quer o melhor dos dois mundos — Code Connect + gestão completa do DS

• Precisa capturar UI live (Nativo) E depois auditar tokens (Console)

O que mudou desde o artigo original

Referências

1. Artigo original (desatualizado): Figma MCP vs. Figma Console MCP: A Definitive Comparison — Southleft, Mar 2025 (atualizado Mai 2025). Ainda útil para contexto arquitetural, mas os dados de capabilities estão incorretos para o estado atual do Figma MCP Nativo.

2. Documentação oficial do Figma MCP: Guide to the Figma MCP server — Figma Help Center. Confirma canvas write, UI capture, FigJam, Make, Skills, e que será pago após beta.

3. Figma Console MCP — toolset verificado: 60 tools listados via MCP protocol discovery (figma-console server). Inclui: 11 tools de variable management, 7 de component management, 4 de real-time awareness, execução arbitrária de Plugin API (figma_execute), batch operations, audit dashboard, e mais.

4. Figma Console MCP — repositório: https://github.com/southleft/figma-console-mcp — Open source, MIT license.

5. Figma Developer Documentation: Figma MCP server developer docs — Lista de tools, rate limits por plano, e Skills disponíveis.

Mesmo quando componentes seguem boas práticas, contraste adequado, ARIA correto, navegação por teclado, o produto final ainda pode falhar gravemente em acessibilidade. Isso acontece porque acessibilidade não é apenas uma propriedade do componente, mas da experiência completa em execução.

Enquanto o Design System prepara o terreno. A acessibilidade se mostra quando o produto está em uso, na experiência do dia a dia.

O mito do Design System como solução final

Em muitas empresas, especialmente sem uma área dedicada de acessibilidade, o Design System vira o lugar onde se “resolve” o problema:

• “Esse botão é acessível?”

• “Esse modal passa no Lighthouse?”

• “Esse componente tem ARIA?”

Essas perguntas são importantes, mas insuficientes.

Elas partem de um diagnóstico incompleto: o de que acessibilidade é um conjunto de atributos técnicos aplicáveis a peças isoladas.

Não é.

Assine agora

O que um Design System realmente resolve

Um Design System construído com acessibilidade como requisito, garante consistência em escala e minimiza erros humanos na implementação.
Ele centraliza decisões técnicas críticas em acessibilidade, permitindo auditorias em componentes reutilizáveis antes do uso em produção.

Tecnicamente, ele pode e deve resolver:

1. Acessibilidade intra-componente

• Navegação por teclado dentro do componente

• Gerenciamento de foco interno (ex: modais, dropdowns)

• Estados visuais consistentes (:focus-visible, :disabled, :aria-expanded)

• Tamanho da área de toque em elementos interativos

2. Semântica base correta

• Uso adequado de elementos nativos (button, label, input)

• ARIA apenas quando necessário, nunca como substituto de HTML semântico

3. Tokens e decisões globais

• Relação de contraste validado em tokens de cor

• Escalas tipográficas que respeitam legibilidade

• Espaçamento mínimo para interação

• Suporte a zoom e redimensionamento de texto sem perda de conteúdo

Tudo isso cria componentes confiáveis.
Mas confiável não significa suficiente.

Onde a acessibilidade quebra fora do Design System

Quando falamos que a acessibilidade falha fora do Design System, não estamos falando de componentes mal feitos ou de implementações descuidadas.

Estamos falando de algo mais sutil e mais comum: decisões de composição, estrutura e organização da interface que acontecem no nível da página e do fluxo.

É nesse momento que componentes acessíveis passam a ser usados juntos, em contextos reais, com layouts complexos, prioridades concorrentes e restrições de produto. E é exatamente aí que muitas experiências se tornam inacessíveis, mesmo quando cada peça individual “está correta”.

A seguir, alguns exemplos técnicos claros de falhas que o DS não consegue resolver sozinho.

1. Ordem do DOM ≠ Ordem visual e de leitura

Um componente pode ser totalmente navegável por teclado.
Mas se ele estiver fora da ordem lógica do DOM na página em que foi utilizado, o leitor de tela seguirá um fluxo incoerente.

Exemplo clássico:

• Sidebar renderizada depois do conteúdo principal

• Grid visualmente organizado por CSS, mas com ordem de leitura confusa para leitores de tela.

Isso não é um problema de componente.
É um problema de composição e layout estrutural.

2. Uso de Headings ≠ Hierarquia correta

O Design System pode orientar e documentar boas práticas, como:​

• “Use h2 em títulos de seções.”​

• “Evite pular níveis de título (ex.: h2 → h4).”

• “Evite usar mais que um título h1”

Mas ele não decide:

• Onde começa e termina uma seção semântica

• Como a navegação se relaciona com o conteúdo

• Se os títulos são realmente descritivos

Essa decisão é de arquitetura de informação, não de biblioteca de componentes.

3. Foco interno correto ≠ Jornada de foco correta

Um modal pode:

• Conter trap de foco

• Ter botão de fechar acessível

• Gerenciar aria-modal

E ainda assim falhar se:

• O foco não retorna ao elemento que abriu o modal

• O usuário cai em um limbo de navegação após fechar

O DS resolve o micro, o produto precisa resolver o macro.

Além disso, muitos problemas de acessibilidade não aparecem em interações isoladas, mas ao longo do tempo.

Acessibilidade não é apenas conseguir usar uma tela. É conseguir completar uma tarefa inteira, mesmo quando ela envolve múltiplos passos, interrupções, retornos e mudanças de contexto.

Podemos chamar isso de acessibilidade longitudinal: a capacidade de uma experiência se manter compreensível, previsível e navegável do início ao fim de uma jornada.

Um produto pode ter componentes acessíveis, foco bem gerenciado e semântica correta, e ainda assim falhar quando:

• o usuário precisa retomar uma tarefa interrompida

• um erro obriga a voltar vários passos sem contexto claro

• estados intermediários não comunicam progresso ou consequência

Esse tipo de falha não acontece no componente. Ela acontece na orquestração da experiência ao longo do tempo — e essa orquestração é uma responsabilidade direta do produto.

4. ARIA no componente ≠ Experiência compreensível

ARIA labels ajudam tecnologias assistivas, mas não resolvem:

• Labels genéricos (“Clique aqui ou “Saiba mais”)

• Instruções fora de contexto

• Feedbacks que não explicam o que aconteceu

Acessibilidade não é apenas “ser lido”, é ser entendido.

Acessibilidade acontece na experiência final

Conforme o relatório WebAIM Million (WebAIM.org, 2024), o gráfico abaixo mostra as falhas de WCAG mais comuns encontradas em home pages (% de páginas), com base em uma análise automatizada de 1 milhão de páginas.

Parte dessas falhas pode ser prevenida no nível do Design System, por meio de padrões, componentes e tokens. No entanto, outras dependem de decisões no nível da página e de validações adicionais no código.

Vamos explorar cada uma delas:

• ✓ Contraste de texto insuficiente: pode ser tratado no Design System, com validação de contraste e definição de tokens de cor que atendam aos requisitos mínimos.

• ⚠ Ausência de texto alternativo em imagens: deve ser definido no nível da página, avaliando a descrição mais apropriada ou determinando se a imagem utilizada é meramente decorativa.

• ✓ Ausência de labels em campos de formulário: deve ser endereçada no Design System, de modo a reduzir o risco de uso de componentes sem um label associado.

• ⚠ Links e botões vazios: geralmente, o Design System não impede que a implementação gere elementos <a> ou <button> sem conteúdo (ou sem nome acessível); por isso, recomenda-se aplicar validações automatizadas no código ou no processo de build para bloquear esses casos.

• ⚠ Ausência de definição de idioma no documento: o atributo lang é definido no documento/página, ficando fora do escopo do Design System.

Responsabilidades técnicas bem delimitadas

Para que a acessibilidade funcione de verdade, as responsabilidades precisam ser claras:

Design System

• Infraestrutura acessível

• Componentes confiáveis (que realmente funcionem em A11Y)

• Documentação explícita sobre limites

Produto (Design + Dev)

• Estrutura semântica da página

• Fluxos completos e previsíveis

• Ordem lógica de navegação

Conteúdo

• Linguagem clara e contextual

• Instruções acionáveis

• Feedback compreensível

Quando tudo isso é jogado no colo do DS, ele inevitavelmente falha, porque está sendo usado fora do seu escopo.

Na prática, essas responsabilidades não existem em um vácuo.

Decisões de acessibilidade no produto quase sempre competem com outras forças: prazos, escopo, dívida técnica, metas de entrega e limitações de time.

É nesse contexto que muitos problemas surgem, não por desconhecimento técnico, mas porque acessibilidade é tratada como uma característica que o produto “herda” do Design System, e não como uma decisão que precisa ser reafirmada a cada fluxo, página e exceção.

Quando essas decisões não são explicitadas, a acessibilidade se dilui. Ela deixa de ser critério de qualidade e passa a ser um efeito colateral esperado da infraestrutura, algo que não se sustenta na experiência real.

Tratar acessibilidade como responsabilidade de produto é, antes de tudo, assumir que ela envolve trade-offs conscientes, documentação de escolhas e validação contínua na experiência real.

Nesse cenário, em que a acessibilidade depende de decisões contínuas feitas sob restrições reais, não faz sentido tratá-la como uma verificação pontual ou como responsabilidade isolada de um sistema.

As recomendações a seguir não são “boas práticas universais”, mas comportamentos recorrentes observados em times mais maduros, que entendem o Design System como infraestrutura e assumem a acessibilidade como critério ativo de qualidade no produto.

Recomendações para times

• Testar acessibilidade em páginas reais, não apenas em Storybook

• Validar fluxos completos com teclado e leitor de tela

• Documentar decisões de acessibilidade no nível do produto

• Tratar o Design System como base, não como garantia de acessibilidade final.

• Contar com documentação de acessibilidade nos componentes do Design System.

Em resumo

Um Design System acessível é uma conquista importante.
Mas acessibilidade não é uma feature que se “herda”.

Ela é uma propriedade emergente de decisões corretas tomadas em múltiplos níveis: técnico, estrutural, semântico e humano.

Quando entendemos isso, o Design System deixa de ser um bode expiatório e passa a ser o que sempre deveria ter sido: infraestrutura para boas decisões, não substituto delas.

Referências e leituras complementares

Diretrizes e padrões de acessibilidade

• Web Content Accessibility Guidelines (WCAG) 2.1 e 2.2
  W3C – World Wide Web Consortium
  https://www.w3.org/WAI/standards-guidelines/wcag/

• WAI-ARIA Authoring Practices
  Padrões para uso correto de ARIA em componentes interativos
  https://www.w3.org/WAI/ARIA/apg/

• Accessible Rich Internet Applications (WAI-ARIA)
  https://www.w3.org/TR/wai-aria/

Pesquisas empíricas e dados de mercado

• WebAIM – The WebAIM Million
  Relatórios anuais sobre os erros de acessibilidade mais comuns na web
  https://webaim.org/projects/million/

• Deque Systems – State of Accessibility
  Relatórios e artigos sobre maturidade organizacional em acessibilidade
  https://www.deque.com/resources/

Em algum momento, toda organização que trabalha com Design System chega ao mesmo diagnóstico: “O Design System não está bom”.

Essa frase costuma surgir quando algo concreto não funciona como deveria. Uma tela parece confusa, um fluxo não performa ou a experiência de produto não comunica bem um novo momento da marca. Existe um incômodo real, e a vontade de melhorar é legítima. O problema não está no desconforto. O problema está no alvo escolhido para resolvê-lo.

Na prática, o Design System passa a ser tratado como se fosse o lugar onde a experiência de produto acontece, como se fosse responsável direto pela qualidade final de uma tela ou pela clareza de um fluxo. Essa expectativa nasce equivocada. Um Design System não é a experiência. Ele é a estrutura que permite que experiências de produto existam de forma consistente.

Por isso, é possível ter experiências muito diferentes usando o mesmo Design System. O Design System organiza a linguagem visual e os componentes compartilhados entre times, mas não define como cada fluxo deve funcionar para o usuário final. Essa responsabilidade está em Produto, que lida com contexto, jornada e decisões específicas de uso.

Quando o Design System é avaliado a partir do resultado final de uma decisão de produto, qualquer problema passa a ser interpretado como uma falha estrutural do sistema, mesmo quando ele é puramente contextual.

Esse assunto não é novo

Brad Frost já levantava essa discussão quando apresentou o conceito de Atomic Design, ainda por volta de 2013, e depois consolidado no livro Atomic Design (2016).

Embora hoje a maioria dos Design Systems não utilize mais a nomenclatura de Atoms, Molecules e Organisms no dia a dia, o princípio por trás do modelo segue atual. Na prática, falamos em componentes base e componentes complexos, mas a lógica de separação permanece a mesma.

Desde a concepção do Atomic Design, Frost deixa claro que o Design System atua até o nível de componentes reutilizáveis e padrões de composição. A partir do momento em que entramos em Templates e Pages, já estamos falando explicitamente de produto.

Templates e Pages não são apenas composição visual. Eles carregam contexto, intenção, hierarquia de informação e decisões de experiência de produto. Mesmo em um dos modelos mais conhecidos da disciplina, a fronteira entre Design System e produto sempre esteve clara.

Quando uma mudança de marca vira um problema técnico

Esse ruído fica ainda mais evidente em momentos de mudança de brand ou concept. Um novo posicionamento entra em cena, novos princípios passam a orientar como a empresa quer se expressar, e rapidamente surge a sensação de que o produto não reflete mais quem somos. A pergunta aparece quase automaticamente: Precisamos refazer o Design System? Na maioria dos casos, a resposta é não.

O que está mudando não é a capacidade do Design System. O que muda é a intenção que orienta o uso dele nos produtos. Os mesmos componentes, tokens e padrões continuam válidos. O que se altera é a ênfase, o ritmo visual, a hierarquia, as combinações e as escolhas de destaque. Em outras palavras, muda o contexto de uso no produto, não a infraestrutura do Design System.

Quando uma mudança de brand é tratada como um problema técnico do Design System, o Design System acaba sendo pressionado a resolver algo que pertence a decisões de produto.

O modelo que ajuda a separar responsabilidades

Grande parte dessa confusão nasce da falta de separação clara entre três camadas que convivem no dia a dia, mas operam em níveis diferentes: Brand, Design System e Produto.

Visualizar essas camadas ajuda a entender onde cada decisão deveria acontecer.

O ponto central não é escolher qual camada é mais importante, mas entender qual pergunta cada uma responde e onde cada decisão deveria acontecer.

Brand / Concept: a camada da intenção

A camada de Brand responde perguntas fundamentais antes de qualquer tela de produto existir.

• Quem somos?

• Como nos comportamos?

• Que sensação queremos transmitir?

• Qual é o nosso tom?

É aqui que vivem os princípios de marca, a narrativa, a direção visual e os valores emocionais.

Brand não define componentes, layouts ou grids. Ele define como decisões devem ser tomadas a partir da identidade e do posicionamento da marca.

Quando um novo brand/concept surge, existe um trabalho paralelo de adequação tanto ao Design System quanto aos produtos. Essas adequações precisam passar pelos times responsáveis, pois envolvem decisões técnicas e estruturais que impactam diretamente a sustentabilidade do Design System e das experiências de produto.

Quando a intenção da marca não está clara, ou não foi traduzida em princípios acionáveis, o produto tenta compensar no visual. Nesse movimento, o Design System começa a ser pressionado a resolver algo que não é dele, funcionando como um substituto improvisado para decisões estratégicas de marca que deveriam ter sido definidas antes.

Design System: a camada da capacidade

O Design System entra exatamente no ponto em que intenção precisa virar algo operável. Ele traduz princípios abstratos em decisões concretas por meio de tokens, componentes, padrões de interação, motion, regras de composição, acessibilidade, limites e exceções.

O papel do Design System não é dizer qual tela de produto deve existir. Ele define quais decisões são possíveis, consistentes e sustentáveis.

Um Design System, por si só, não garante boas experiências de produto. Ele garante que boas experiências possam existir em escala.

Produto: a camada do contexto

Produto é onde tudo isso se materializa. É aqui que vivem telas, fluxos, jornadas, priorizações e trocas reais. É aqui que se decide o que enfatizar, o que simplificar, o que sacrificar e o que experimentar.

Quando uma tela está ruim, um fluxo está confuso ou a experiência de produto não comunica bem um novo brand, o problema está nessa camada. E isso não é um erro. É responsabilidade legítima de Produto.

O problema começa quando decisões de produto passam a ser tratadas como falhas estruturais do Design System.

Onde as responsabilidades se misturam

Quando Brand, Design System e Produto não têm fronteiras claras, alguns padrões se repetem. Decisões de produto passam a ser tratadas como falhas do Design System. Mudanças de brand são interpretadas como problemas técnicos do Design System. O Design System começa a ser avaliado por critérios que pertencem ao produto.

É nesse ponto que surge a frase: “o Design System não está bom”.

Quando, na prática, o que está faltando é clareza de princípios, maturidade de uso e responsabilidade contextual e na maioria das vezes falta uma documentação centralizada.

Quando o Design System realmente precisa mudar

O Design System precisa evoluir quando novos padrões de interação surgem, quando acessibilidade exige novas regras, quando novas plataformas entram em jogo ou quando o próprio Design System deixa de suportar decisões válidas de produto.

Ele não precisa mudar porque uma tela de produto ficou ruim, um fluxo performou mal, um time aplicou mal os componentes ou a marca mudou de tom.

O papel real de um time de Design System

Um time de Design System não é responsável pela qualidade de telas individuais, pela UX de fluxos específicos ou pelo sucesso ou fracasso de features de produto.

Ele é responsável por clareza de regras, coerência entre produtos, flexibilidade controlada, evolução estrutural do Design System e documentação de boas práticas e exceções.

Produto decide o que fazer > Design System define como isso pode existir.

Conclusão: o problema raramente é o Design System

Talvez o Design System não esteja ruim.

Talvez ele esteja sendo usado para resolver problemas que pertencem ao produto.

Separar claramente intenção, capacidade e contexto fortalece decisões, reduz ruído e cria espaço para evolução real.

Quando tudo vira problema do Design System, nada é responsabilidade de produto.

E sem responsabilidade clara, não existe maturidade de design.

Referências e Leituras Relacionadas

Brad Frost

• Atomic Design (artigos): https://bradfrost.com/blog/post/atomic-web-design/

• Atomic Design (livro, 2016): https://atomicdesign.bradfrost.com/

Design Systems como infraestrutura

• Nathan Curtis (EightShapes): https://www.eightshapes.com/

• Shopify Polaris Design System: https://polaris.shopify.com/

• Salesforce Lightning Design System: https://www.lightningdesignsystem.com/

• IBM Carbon Design System: https://carbondesignsystem.com/

Design System × Produto × Experiência

• GOV.UK Design System: https://design-system.service.gov.uk/

• Material Design (guidelines vs products): https://m3.material.io/

Maturidade, Produto e Design Ops

• Team Topologies (camadas de responsabilidade): https://teamtopologies.com/

• Dual-track Discovery: https://www.producttalk.org/2016/02/dual-track-development/

Nem todo layout é responsivo e nem toda responsividade é fluida e existem mais tipos de layouts do que você imagina, sendo comum confundir os inúmeros termos utilizados em desenvolvimento multi-device. No mercado existem inúmeras telas e dispositivos com alturas e larguras diferentes, sendo impossível criar um único layout que fique bom para todos, também não é possível criar um layout para cada dispositivo, por isso é importante pensarmos em dimensões entre larguras ao invés de layouts fixos.

Existem 4 tipos de layouts no mercado que são:

• Static

• Liquid

• Adaptative

• Responsive

Para facilitar o entendimento disponibilizei um arquivo do Figma com as configurações de todos layouts (largura) com um protótipo funcional.

Estático (Static / Fixed)

Layouts estáticos tem uma largura fixa independente da resolução, eram muito comuns no passado e hoje felizmente eles quase não existem mais. O container ou body é formatado para não se mover em sua largura (daí o nome estático).

A desvantagem desse tipo de layout é que ao visualizar o site em resoluções menores será exibido uma barra de rolagem horizontal e será necessário rolar a barra para ver o conteúdo completo conforme imagem abaixo:

Exemplo de site Estático ou Fixo

Fluído (Fluid / Liquid)

Com o layout fluido ou líquido, como o nome já diz, ele se comporta de acordo com o movimento do elemento pai que é o navegador, você especifica seus tamanhos não em pixel, mas em porcentagem, ou seja, se o tamanho da tela mudar, a proporção dos elementos permanecerá igual, porém os elementos se adaptarão internamente.

A desvantagem deste layout é que em telas menores as colunas podem ficar muito estreitas a ponto de não podermos compreender seus conteúdos, imagine um texto extenso em uma coluna de 50pixels de largura ou menor. Isso vale também para elementos como imagens e vídeo que deveriam permanecer em tamanho fixo mas nesse tipo de layout eles de adaptarão com a largura podendo quebrar a experiência, esse layout ao meu ver é bem problemático.

Esse tipo de layout só é vantajoso se comparado ao fixo (anterior), hoje em dia é quase impossível se projetar interfaces 100% fluídas, ambos os cenários Estático e Fluído quase não são usados hoje em dia.

Exemplo de site Liquido ou Fluido

Adaptativo (Adaptative)

Imagine que você tenha muitas resoluções (breakpoints) e em cada uma delas o seu layout terá que se encaixar na largura que sua tela está reduzindo ou aumentando, então cada página terá x adaptações baseadas nos seus breakpoints, ou seja, se a configuração for ter 4 quebras de layout, todas as suas páginas terão 4 adaptações de layout, por isso é muito importante pensar em containers e não em posições absolutas, dessa forma cada adaptação de layout se encaixará no breakpoint entre suas dimensões pré-determinadas conforme imagem abaixo:

A cada breakpoint a tela irá se adequar ao novo formato de layout de forma instantânea, sem responsividade nem fluidez, a ideia do layout adaptativo é a troca sem movimento.

Pensando no ponto positivo é fácil trabalhar com templates de página tendo em vista que os containers sempre serão alterados conforme seus breakpoints pré-determinados, caso o Design System exista regras breakpoints igual o Bootstrap faz melhor ainda.

A parte negativa (ou não) é que existe a necessidade de entender os padrões a fundo e não é aconselhável sair desse padrão devido a consistência do projeto e que haverá uma necessidade de alterar código para que isso funcione corretmanete, mas sim é possível alterar essa regra em avaliando e testando o formato e alinhando com o time de Design System para escalar esse ajuste em Design e código.

Exemplo de site adaptativo

Responsivo (Responsive)

O design Responsivo é o melhor de todos os cenários (na minha opinião), pois ele integra os 2 melhores modelos em 1 só que é o fluído e adaptativo, dessa forma a troca de breakpoints fica mais suave devido ao encaixe do conteúdo nos containers (fluído) antes de alterar o layout no (adaptativo) conforme imagem abaixo:

Apesar de existir uma regra pré-definida dos Breakpoints o conteúdo sempre está “vivo” se adaptando aos containers deixando assim um sentimento de site inteligente e personalizado em cada pixel da tela.

Esse é o formato mais usado hoje no mercado, podendo existir uma mistura de Responsivo até X largura e abaixo disso Adaptativo, as misturas podem ser interessante.

Exemplo de site responsivo

Bônus - O que pode alterar a cada Breakpoints?

Breakpoints (Layout Responsivo como é chamado no mercado) são nada mais que blocos de CSS agrupados de acordo com a Largura ou altura do dispositivo, podendo ser 1 valor de mínimo/máximo ou 2 valores especificando um intervalo conforme abaixo:

Único Valor de tamanho mínimo ou máximo:

/* Extra small devices (phones, 600px and down) */
@media only screen and (max-width: 600px) {...}

/* Small devices (portrait tablets and large phones, 600px and up) */
@media only screen and (min-width: 600px) {...}

/* Medium devices (landscape tablets, 768px and up) */
@media only screen and (min-width: 768px) {...}

/* Large devices (laptops/desktops, 992px and up) */
@media only screen and (min-width: 992px) {...}

/* Extra large devices (large laptops and desktops, 1200px and up) */
@media only screen and (min-width: 1200px) {...}

Valores de mínimos e máximos determinando um intervalo:

@media only screen and (min-width: 360px) and (max-width: 768px) {
	// do something in this width range.
}

Como funciona na prática?

Vamos pensar que temos uma base de estilos que irá transitar entre todas as resoluções, porém, em determinada largura eu quero aplicar uma mudança de largura, cor e espaçamento por exemplo, o código seria conforme abaixo:

.container {
  display: flex;
  flex-wrap: wrap;
  width: 980px;
  margin: 0 auto;
  margin-top: 40px;
  text-color:black;
}

.boxes {
  width: 100px;
}


@media only screen and (min-width: 320px) and (max-width: 576px) {
  .container {
    width: 100%;
    padding-left: 23px;
    text-color: red;
  }
  .boxes {
    width: 100%;
  }
}

Posso alterar QUALQUER propriedade dos estilos com Breakpoints, dessa forma não ficamos limitados apenas as larguras com as adaptações de conteúdo e elementos visuais com larguras e algura conforme estamos acostumados a fazer com as ferramentas de mercado de Design (como o Figma) que não dão suporte a isso (mentira que Framer e Webflow fazem isso, corre lá conhecer elas).

Conclusão

Quer aprender um pouco mais sobre isso? Sugiro estudar o Bootstrap e mexer na prática com o código dele, dê uma lida na documentação do site que é na minha opinião uma das melhores do mercado. Link para Breakpoints

Agradecimentos

*Thanks to Nick Davison who developed the Liqui dap sive website that I use to explain the different examples of applying layout types to websites.

*Referências do artigo e de imagens do site UX Alpaca.

Testando o FIGMA (Design)

Criei 2 containers com as mesmas configurações de 200px de largura, porém, o da esquerda tinha borda, e o da direita tinha padding de 20px e sem a borda.

Testando no HTML (Code)

Aí vem o teste, será que se inserirmos as mesmas configurações no código fica igual? Então peguei as mesmas configurações que o Dev Mode nos dá e inseri no HTML conforme imagem abaixo:

Resultado do HTML no Chrome

De cara já percebemos que não fica igual, falta algo e ele não segue as larguras pré-definidas.

Inspecionando o código percebemos que o CSS está correto com 200px de largura, mas o resultado final tem 242px, que somando 2 bordas de 1px mais 2 paddings de 20px dá um total de 42px a mais.

Sobrepondo ainda as telas do Figma e do HTML fica pior ainda.

Então o Figma DevMode não funciona? Vale a pena comprar algo que não entrega o resultado final esperado? Fica a dúvida no ar.

Resolvendo o problema com box-sizing

Existe um prop do CSS que resolve esse problema que é o box-sizing: border-box.

Resumindo, o que é o box-sizing: border-box?

O box-sizing com o valor border-box faz com que o navegador não calcule a dimensão de um elemento somando bordas e margens com altura e largura, simples e resolve o problema do Figma.

Conforme imagem abaixo ele tem a possibilidade de somar ou não as bordas e paddings.

Resultado do HTML com Content-box: border box

Apesar do texto ainda ser um problema entre Figma e Código que não fica 100% igual, isso ainda é uma ótima solução para esse problema tão grande do Figma que diz “cuspir” a formatação CSS, porém, não foi 100% e dependerá do DEV ter o conhecimento técnico pra ajustar esses pontos na mão. Então não fique bravo com o Dev gente.

Diferentes Navegadores diferentes motores

A entrega 100% pixel perfect não existe pois cada Browser tem um mecanismo de navegação (browse engine) diferente e isso afeta o visual visual em questão de pixels, logo o pixel perfect entre browsers não existe.

Atenção para o Handoff e QA de Design

Não se apegue a sobreposições mágicas de pixel perfect do Design vs Código, pois conforme provado acima o Figma não faz 100% do código e os browsers não renderizam 100% igual entre eles o mesmo visual, logo eles não serão 100% igual.

Obrigado e para mais conteúdos acessem: Iniciativa UI — Bruno Biagioni

Leituras complementares

• W3C Schools — Box Model

• Napoleon — O que é Browser Engine?

Referências

• Wikipedia (2025). Comparison of browser engines

• coolchaem (2021). Browser Rendering

• Free Code Camp (2020). Survey Form Project — ::after, ::before & box-sizing: (align problem!)

Em muitas empresas, times de Ops não foram extintos de forma explícita. Eles simplesmente deixaram de existir como função dedicada.
O trabalho continuou sendo necessário, mas passou a ser absorvido por outros times. Produto, Design, Engenharia e, com frequência, o time de Design System.

Governança, rituais, métricas, alinhamento entre times, processos de decisão e manutenção de acordos continuam acontecendo, só que agora sem um responsável claro.

O diagnóstico mais comum

O diagnóstico mais recorrente é simples: Ops não gerava valor suficiente para justificar o custo.

Esse raciocínio parece lógico, mas tem muito mais por trás do que somente custos ao meu ver.

Ele parte da premissa de que valor só existe quando é diretamente atribuível a uma entrega visível. Ignora o papel de funções que atuam como infraestrutura de produtividade, qualidade e escala.

Ops raramente entrega algo isoladamente ele é mais amplo.
Ele reduz desperdício, organiza o caos, evita retrabalho e protege decisões estratégicas.

Quando isso não é medido, parece invisível.

O que realmente levou as empresas a reduzir Ops

Esse movimento não nasce de um único fator, mas da combinação de vários.

• Primeiro, a pressão de budget e o foco em custos diretos. Em momentos de ajuste financeiro, funções percebidas como camadas de suporte se tornam alvos fáceis, especialmente quando não possuem métricas financeiras claras associadas.

• Segundo, a falta de dados sobre ganhos indiretos. Ops gera ganhos sistêmicos como menos atrito, mais velocidade e melhor alinhamento. O problema é que poucas empresas sabem ou se preocupam em medir esse impacto.

• Terceiro, uma cultura excessivamente orientada a outputs. Se a organização mede apenas features entregues, prazos e roadmap, qualquer função focada em como o trabalho acontece perde espaço.

Por fim, estruturas cada vez mais enxutas. O achatamento organizacional elimina papéis intermediários mesmo quando eles eram responsáveis por manter a máquina funcionando de forma saudável.

Nada disso significa que Ops não funciona.
Significa que o valor de Ops não estava explícito o suficiente para sobreviver a um corte.

Onde a confusão conceitual começa

A confusão aparece quando a empresa assume, mesmo sem dizer, que se não existe um time dedicado, o trabalho deixa de existir.

Isso nunca acontece.

Design System passa a acumular responsabilidades que vão muito além da construção e manutenção do sistema. Mediação entre times, alinhamento estratégico, definição de rituais, governança e educação organizacional entram no escopo de forma informal.

O efeito colateral nos times de Design System

Design Systems raramente são times grandes.
Quando assumem responsabilidades operacionais sem estrutura, os sintomas aparecem rapidamente.

Backlogs invisíveis, decisões constantemente adiadas, desgaste contínuo, queda de qualidade e a sensação permanente de estar apagando incêndios.

A empresa acredita que economizou ao cortar Ops.
Na prática, apenas transferiu o custo para outras áreas de forma difusa e difícil de rastrear.

O que essa decisão resolve e o que ela não resolve

Ela resolve problemas imediatos.
Reduz headcount, simplifica o organograma e facilita decisões financeiras de curto prazo.

Mas não resolve questões estruturais.
Não resolve problemas de escala, desalinhamento entre times, retrabalho, inconsistências de produto ou perda de eficiência ao longo do tempo.

Sem Ops, a empresa não se torna mais simples.
Ela se torna menos consciente da própria complexidade.

Caminhos para contornar o problema

A resposta não é simplesmente recriar estruturas antigas por inércia, nem assumir que o trabalho vai “se resolver” ao ser distribuído informalmente entre outros times.

Algumas possibilidades que vêm aparecendo em organizações mais maduras passam por:

• Tornar o valor operacional mensurável
  Ganhos de Ops raramente aparecem como entrega direta, mas impactam tempo, qualidade e retrabalho. Tempo economizado entre squads, redução de inconsistências, diminuição de dependências e impacto na velocidade de entrega precisam ser tratados como dados, não apenas como percepções ou narrativas internas.

• Separar claramente infraestrutura de entrega
  Design System não é um substituto natural de Ops. Quando infraestrutura organizacional e entrega de sistema se misturam, o time perde foco, cria dívida invisível e fragiliza a escala no médio prazo. Mesmo que a estrutura seja enxuta, a distinção conceitual precisa existir.

• Tratar Ops como capacidade organizacional, não apenas como time
  Mesmo sem um time dedicado, a função operacional precisa estar explícita. Alguém responde por governança, métricas, rituais e acordos entre times. Quando essa responsabilidade não é nomeada, ela se espalha de forma caótica.

• Criar modelos híbridos e temporários, não soluções definitivas
  Em vez de estruturas fixas, algumas empresas têm adotado células, papéis rotativos ou ciclos de dedicação parcial para funções operacionais, sempre com escopo, duração e critérios claros. O risco não está no modelo híbrido, mas na informalidade permanente.

• Evitar a romantização do time enxuto
  Times pequenos não são mais maduros por definição. Enxugamento sem clareza apenas desloca o custo. Maturidade vem de limites bem definidos, decisões conscientes e acordos explícitos sobre o que não será feito.

Uma reflexão final

Talvez a pergunta mais honesta não seja se Ops vale o custo.

Talvez a pergunta real seja se estamos preparados para operar sem enxergar o custo real da ausência de Ops.

Enquanto essa reflexão não acontece, o trabalho continua existindo. Ele apenas se torna mais fragmentado, mais invisível e, na maioria das vezes, mais caro do que parece.

Hoje o Figma praticamente domina o mercado de aplicativos de Interface de Design Web, mas existem inúmeros aplicativos ótimos por aí onde todos visam que os seus layouts espelhem 100% ao que será desenvolvido seja para Web ou Mobile. Só que existe uma coisa em comum que nenhuma delas faz: espelhar 100% do que é possível ser feito em HTML e CSS (todas menos o Webflow, mas é polêmico o assunto). Sabendo que nem toda ferramenta consegue simular 100% do código, como podemos reduzir essa discrepância?

Por outro lado existe também uma grande maioria de pessoas que criam interfaces para dispositivos (Web e Mobile) entendendo pouquíssimo (ou quase nada) do que pode ser feito no final do código.

Sendo assim:

Como podemos criar layouts se não sabemos como eles se comportam no código?

Atualmente sim é possível (necessário) criar layouts sem entender de HTML e CSS, porém, como dizia Charles Dickens: “Uma vaga noção de tudo, e um conhecimento de nada”. E é assim que no fim das contas acontece, o pouco conhecimento sobre o que o HTML e CSS pode limitar a entrega final para o desenvolvimento o que acaba se tornando uma briga onde um lado (dev) fala que a entrega não foi detalhada corretamente e o outro lado (design) fala que o layout não foi implementado da forma que foi desenhado.

Agora voltando um pouco no passado quando comecei a trabalhar com Design em janeiro de 2006, designers faziam layout e “recortavam” o HTML e CSS também. Aprendi da pior (ou melhor) forma possível como o código funcionava.

Entrei em um time de Sustentação que era o time responsável por arrumar os bugs de toda a fábrica de software (simples assim). Naquela época não existia o inspecionar código dos navegadores; era o Internet Explorer 6 e tínhamos que abrir o código e inserir borda vermelha em todo CSS e alerts nos JavaScripts. Era mais ou menos assim e se não funcionasse era só colocar !important no fim do CSS.

Contudo em 2008 quando comecei a trabalhar na SKY eu já tinha um entendimento de como o Designer e o Desenvolvedor deveriam trabalhar e até hoje penso exatamente igual, seria algo assim:

O Tiago Gonçalves e a Tamires Dias não me deixam mentir, o trabalho era lado a lado e sabíamos que era importante o compartilhamento mas não era saudável se aprofundar muito, então desenvolvemos um padrão de que um deveria conhecer minimamente como o outro lado funcionava.

­

Tentando resolver o problema

Como podemos pensar em um estudo segundo a sua necessidade ou carreira tendo em vista que existem muitos cargos que podem exigir mais ou menos desse entendimento, pensando nisso, criei uma categorização do tema onde podemos facilmente entender seus níveis e em que momento podemos aplicar cada etapa da sua carreira:

1. Semântico (Estruturação de Layouts)

2. Responsivo (Prototipação com Multi-Resoluções)

3. Interativo (Animações, Micro Interações, UX Motion)

­

1. Semântico

Essa etapa é voltada para quem trabalha mais com desenho de telas ao nível de interface sem se aprofundar em interações ou componentes.

Entender a semântica do código ajudará você a nomear suas layers segundo a vocação da Tag HTML, elevando demais a entrega de seus layouts para o time de desenvolvimento.

Abaixo temos dois exemplos, o primeiro uma estrutura de layout de dashboard com as áreas de conteúdo nomeadas, logo a seguir uma estrutura de Card com os elementos internos bem nomeados para facilitar assim a identificação dos itens.

Agora pense em como seria uma entrega desse mesmo layout sem semântica? Indo mais além, imagine isso em um fluxo de 50 páginas?

Claro que nem sempre é possível detalhar cada elemento do seu layout, mas quanto mais ele estiver organizado melhor será o seu conhecimento semântico porque com o tempo você evoluirá essa parte e também seu handoff será melhor e o reuso das suas telas e componentes em outros fluxos terá muitos ganhos.

­

Pontos positivos para um site semântico

O uso de HTML Semântico contribui para que os motores de busca (SEO) consigam interpretar melhor o conteúdo e o contexto das informações presentes nas páginas e dessa forma posicione melhor sua página em buscadores. Exemplo:

Resultado foi um crescimento de +30% de visitas e isso é só o começo do que pode ser feito.­

2. Responsivo

Essa etapa acredito que seja interessante detalharmos dois formatos muito confundidos nos layouts, o Media Query (Breakpoints) e o Container Query, ambos trabalham o comportamento do elemento de acordo com alguma dimensão acima deles. Exemplo de suas aplicações abaixo:

Precisamos identificar a forma de uso de cada um para conseguirmos criar experiências ricas e personalizadas conforme o momento mais adequado para a tela ou para o elemento.­

2.1 — Breakpoints (Media query)

Media Query: Recurso do CSS 3 que permite que a renderização do conteúdo se adapte a diferentes condições de resolução da tela. Tornou-se um padrão recomendado pelo W3C em junho de 2012.

Quando trabalhamos tipos de largura de tela usamos os Breakpoints da página configurados pelos Media Queries para que possamos adaptar nosso conteúdo conforme a largura da janela do navegar, essa parte é muito importante pois podemos alterar praticamente TUDO de uma tela a cada Breakpoint da página, desde posicionamentos, larguras, cores, efeitos, tudo.

Extra: Se utilizarmos Javascript podemos aumentar o leque de opções de uso (window.outerWidth, window.innerWidth, window.outerHeight e window.innerHeight) conforme imagem abaixo:

2.2 — Container Query — Largura (ou dimensão) do elemento pai

Container query: Os recursos de largura de containers permitem aplicar estilos a um elemento com base no tamanho do contêiner do elemento, ou seja, podemos alterar outros estilos em um Container Query. Não é a largura da página e sim a largura do elemento pai conforme abaixo:

Como é o código em CSS?

@container (min-width: 500px) {
  .card {
    grid-template-columns: 1fr 2fr;
    grid-template-rows: auto 1fr;
    align-items: start;
    column-gap: 20px;
    max-width:100%;
  }
}

Code pen do exemplo acima

Outro exemplo:

Contudo nem tudo são flores, nem todas as ferramentas conseguem automatizar essas regras, então a imagem acima mostra possibilidades onde a configuração vai de acordo com a aplicação e suas regras de uso em tempo real, com isso, tanto o Breakpoint quanto o Container Query devem documentados no Handoff do componente ou na entrega do layout onde se aplica a regra.

Seria maravilhoso se essas regras fossem automatizadas no Figma em um futuro não? Tomara que isso chegue um dia (sonho).­

3. Interativo

Trabalhar com UX Motion e Micro Interações de um componente ou tela requer uma visão ampla de animações e noção de mínimos e máximos, nem toda interação cabe em determinado lugar e para que a animação seja fluída, padronizada e faça sentido com o contexto é importante conhecermos a fundo todas possibilidades de aplicação e suas limitações técnicas.­

Micro Interações

São movimentos ou animações de elementos onde podem transformar uma tarefa simples em uma experiência significativa, saindo do simples estático que antes poderiam ser despercebidos para movimentos impactantes.

Exemplo de micro-interações:

E como as micro-interações são aplicadas? Esse é um cenário amplo que vale até outro artigo, mas em resumo geralmente ela é feita (hoje em dia) via Json, mas já foi feito muito no passado com GIF e CSS.­

UX Motion

As animações e transições de UX Motion ajudam a guiar o uso de telas e fluxos tornando a experiência do usuário mais agradável e com propósito. Mas o Motion como conhecemos hoje veio de outra área mais conhecida como Motion Graphics, também conhecido como motion design, videografismo ou design de animação, é uma técnica de design gráfico que mescla princípios de design, animação, vídeo e cinema, gerando um grande impacto visual.

Abaixo os 12 princípios de UX Motion mais conhecidos:

Já no Motion, diferente de Micro-interações, podemos usar outros recursos como CSS, Javascript, Jquery e até Json se for o caso de uma animação de elemento de ilustração. Abaixo alguns exemplos reais de UX Motion:

Mas o que UX Motion e Micro-Interações estão fazendo aqui nesse artigo de HTML e CSS? No final das contas mesmo que o processo seja feito em outras ferramentas, o resultado será aplicado em código e é muito importante conhecer as limitações do código para que a aplicação da animação seja fluída e não seja uma dor de cabeça para o time técnico. Já vi muito processo ser feito e no final não ser possível a aplicação por falta de conhecimento final da aplicação, como também já vi muito projeto sendo aplicado da forma errada e ao invés de melhorar a experiência piorar.

Uma dica em Motion é: Saiba pesar a mão e converse com o time de desenvolvimento. Não tente aplicar todo o seu conhecimento em uma única tela, seja simples.

Quer trabalhar com UI ou Design System e se destacar? Abra sua mente para o código. Aprender linguagem de formatação e animação te trará uma nova visão de como tudo funciona além de te dar mais força para interagir com o time técnico (desenvolvedores). No final os times de desenvolvimento são seus parceiros de time e não o time concorrente.

Me sigam nas redes sociais:

Meus links

Downloads de Figma grátis

Referências

• Hugo Scott. Use semantic HTML5 tags to focus your page content and avoid pollution and dilution of the page’s theme

• Adrianti Rusli (2023). Container Queries: Do we still need Media Queries?

• Ahmad Shadeed (2023) — The Guide To Responsive Design In 2023 and Beyond

• Kamil Kiełczewski (2020). Get the size of the screen, current web page and browser window

• Tony Pinkevych — Icons Microinteractions

• Joseph Foley — This handy UX design cheatsheet is invaluable

• Akal Sujlana — 7 UX Animation Principles (You Need to Know)

Como a utilização de plugins pode acelerar seus processos de trabalho no dia a dia? Sempre que penso em fazer algo em escala dentro do Figma eu me pergunto: “poxa, será que alguém já pensou em fazer isso e fez algum plugin que acelere meu trabalho?”, nem sempre eu consigo tudo em um único plugin, mas você pode unir 2 deles para resolver seus problemas. Então vamos lá.

Lembrando que são os meus top 5 plugins, caso você tenham algum que vale acrescentar na lista, manda aí pra gente compartilhar.

5 - Rename Styles

Mesmo estando em último na lista, este é um dos meus favoritos e já foi um dos mais usados. Neste componente você pode alterar não somente os nomes dos estilos de cores mas também os de texto, grid e efeitos.

O uso dele é muito simples, você executa o plugin e ele vai carregar já de cara tudo que tiver no seu arquivo, lembrando que ele não vai carregar bibliotecas externas e sim o que estiver dentro do seu arquivo principal.

Ao carregar os nomes você pode filtrar na esquerda caso tenham muitos itens, na direita você coloca o nome que quer alterar no “find” e no “replace” você insere o dado que você irá substituir. Muito simples e usual.

Download do plugin Rename Styles

4 - Simple Sort

Este plugin é muito ágil para quem trabalha com Design Systems, a estrutura dele é baseada em variantes, portanto só é possível organizar itens dentro de um set de componentes com variantes.

O ponto fraco dele é que não é possível reordenar as variantes, somente as propriedades delas, portanto, se você quiser inserir primeiro o State (conforme) a imagem, você terá que alterar no primeiro nó do set. Caso alguém tenha outro que já faça isso manda aí :).

Download do plugin Simple Sort

3 - Super Select

A tempos eu procurava por este plugin, imagine que você tenha que selecionar um filho do componente que você quer alterar algo, porém, você está trabalhando com muitos milhares de variantes, sim eu já selecionei um a um no passado, hoje graças a esse componente eu não faço mais isso.

Seguindo a imagem abaixo, eu seleciono o item pai (pode ser o filho também), e usando o plugin eu consigo selecionar todos os itens filhos dele, abaixo da hierarquia.

Você pode também selecionar no Figma algum item filho com o Control e pedir para ele selecionar o item pai, e isso é infinito, enquanto você quiser que o plugin suba níveis ou desça é só você ir repetindo a operação.

Download plugin Super Select

2 - Similayer

Este item é para alterar propriedades de elementos em massa, por exemplo, se você quer alterar todas as bordas de vários elementos das suas 50 páginas do projeto, esse plugin dá várias opções para você escolher baseado em um elemento que você selecionou, você pode unir propriedades para que você possa procurar elementos em comum.

É uma mão na roda principalmente para procurar elementos de mesmo nome, por isso a importância de renomearmos os componentes corretamente.

Download plugin Similayer

1 - Rename it

Apesar do Figma ter uma funcionalidade semelhante, eu gosto muito desse plugin por ter algumas funções extras onde podemos selecionar elementos e adicionar nomenclaturas avançadas e ordem de números se necessário conforme imagem abaixo. É possível também concatenar as funções com o caracter +.

Também é possível selecionar um grupo de itens, sejam eles layers, grupos ou componentes e buscar uma plabra específica e trocar por outro valor, porém, nessa função não é possível utilizar as regras do item anterior de Keywords. Essa função é sensacional!

Download plugin Rename it

Espero que essa lista ajude vocês a acelerarem seus processos e que abram também a mente para procurar mais plugins de produtividade.

Tem mais plugins de produtividade? Comenta aí gente.

Porque ninguém fala de coisas simples que poderiam melhorar? Estamos tão preocupados em fazer coisas futuristas e inovadoras que esquecemos do básico, pode parecer pouco, mas pare para pensar em quantas coisas nós reclamamos no dia a dia que poderiam melhorar, desde uma informação faltando a um uso de máquinas de café ou impressoras, no meu caso foi o banheiro, sim eu fui usar banheiro e me senti totalmente desconfortável com a usabilidade do banheiro, mais especificamente da casinha do trono, essa da foto abaixo.

Poxa, mas falamos falar de banheiro e privada? Vamos sim, porque ninguém fala disso e precisamos começar a fazer UX do básico para depois irmos para o avançado, se conseguirmos pensar em solucionar problemas do dia a dia nós aprenderemos a fazer coisas mais avançadas de forma mais simples, é igual video game, começamos em um nível básico fazendo uma coisa por vez primeiro andar, depois pular, depois arremessar, depois desviar e só depois passamos a usar comandos avançados e combinados, pensando nisso criei a série "A UX que ninguém fala" para tratar assuntos como esse que pra mim fazem toda a diferença, pois vejo muitas pessoas reclamando de coisas básicas das empresas mas ninguém as resolve e no final esses problemas se transformam em insatisfação raiva.

Vamos começar a resolver coisas básicas para depois mudarmos o mundo, isso vai ajudar muito no desenvolvimento das suas ideia.

Voltando ao assunto banheiro, o que tem de errado na foto? Tem tudo que preciso ali né? Privada, papel e lixeira, mas você já parou pra pensar como irei abrir a lixeira? Tenho que pisar nela e não posso encostar as mãos, então olha de novo na foto e pensa, como farei isso estando sentado de costas para a lixeira?

E como resolver?

Fiz uma troca básica tirando a lixeira de trás da privada e coloquei na frente e testei pisando nela, pronto, consigo dispensar meu papel sem encostar na lixeira que é um problema muito ruim, ter que encostar na lixeira pra abrir e jogar o papel dentro, dessa forma nova resolvemos o problema de forma simples e eficaz.

Acredito que resolver coisas simples do dia a dia pode melhorar muito o Employee Experience que é um assunto que está sendo muito falado, ações utilizadas para garantir o bem-estar das equipes deve fazer parte do dia a dia também do User Experience, saia da sua mesa e olhe ao seu redor, o que posso ajudar para ajudar melhorar o dia a dia das pessoas?

Obrigado Abraços.