Todas 55 3D Print 6 Cases 5 E-commerce 6 Front-End 10 IA & Agentes 8 Smart Home 5 UX/UI Design 15

Publicado em: 16/08/2026 · ID 226

Estruturas de UI: os modelos que o mundo usa

App shell real: Header + Sidebar + main + surfaces. Anatomia, zonas e o que não misturar — desenhado a partir de um DS de produto.

UX/UI Design

Que tipo de artigo é este? Explicação das estruturas de UI mais usadas em produto denso — ilustradas com a anatomia de um app shell real (template de estrutura, header e sidebar de design system), não com wireframes genéricos de stock.

Tese O mundo não inventa um layout novo a cada sprint. Inventa regras: um chrome global, um main com surfaces, e zero segundo header.
App shell anotado: Header, Sidebar e main
Figura 1 — App shell: Header (marca) + Sidebar (rail) + main (N60) + Header de páginas + cartão.

1. Template / estrutura — o modelo dominante

Em admin, B2B e SaaS, a estrutura que mais se repete no mundo é o app shell:

  • Header — chrome de marca e ações globais (sticky).
  • Sidebar — navegação estável (colapsada ~82px / expandida ~300px).
  • main — trabalho; largura máxima (ex. ≤1640px) para não “esticar” o conteúdo.

No produto, o shell é montado uma vez. A feature não redesenha sidebar nem inventa outro <header> verde. O miolo começa no Header de páginas (título, subtítulo, ações da tela) e desce para cartões.

Bloco Canal (produto) = Header + Sidebar + main. Documentação de DS pode somar menu da biblioteca e TOC — isso não vai para a tela do usuário final.
Header em cinco zonas no desktop e quatro no mobile
Figura 2 — Header em zonas: desktop 5 células · mobile 4.

2. Header — zonas, não “barra cheia”

Header bom é mapa de zonas, não um dump de botões:

  1. Marca — logo + nome do canal.
  2. Data / hora — contexto temporal (quando fizer sentido).
  3. Contexto — empresa / posto / conta ativa.
  4. Interno — chip de impersonação (só quando precisa; some no mobile para a sidebar).
  5. Ações — carrinho, notificações, perfil (hits ≥40–48px).

Bom: header = só chrome global.
Não: filtros, tabs de feature ou CTAs de página na barra de marca — isso é Header de páginas, no main.

Sidebar colapsada 82px e expandida 300px com L1 L2 L3
Figura 3 — Sidebar: rail 82 · pinada 300 · níveis L1 → L2 → L3.

3. Sidebar — rail com níveis

A sidebar clássica do mundo (e a que escala) é um rail:

  • Colapsada — ícones L1 + pin.
  • Expandida / pinada — título tipo “Navegue por:”, L1 (grupo/destino), L2 (submenu), L3 (bloco raro: destaque / upsell).

Sticky sob o header. Árvore vem de uma fonte só (nav config) — não de CSS copiado por feature.

Bom: hits ~40px, gap curto, L3 excepcional.
Não: CTA de campanha no rail; segunda sidebar; shimmer de “empresa” aqui (isso é do header).

Pilha de surfaces N60 até N0 no main
Figura 4 — Surfaces no main: página → contentor → head → body/foot.

4. Dentro do main — surfaces, não sombra

Depois do chrome, a estrutura que o mundo usa para conteúdo é uma pilha de surfaces:

  1. Página (N60) — fundo do main.
  2. Contentor — agrupa (opcional).
  3. Cabeçalho do bloco (subtle) — título da seção.
  4. Corpo / rodapé (elevated / N0) — onde a pessoa lê e age.

Marca do header/sidebar não é surface de cartão. Verde (ou qualquer cor de chrome) dentro do card quebra a hierarquia e parece “tema errado”.

Bom versus frágil no shell de produto
Figura 5 — Checklist: o que sustenta o shell vs o que vira dívida.

5. Bom vs frágil

  • Bom: um shell; Header de páginas no main; surfaces com papel; sidebar com árvore estável; tokens (não hex soltos); main com teto de largura.
  • Não: segundo header/sidebar; filtros no chrome; marca no cartão; fork do shell por projeto; TOC de documentação no produto; CTA no rail.

Os outros modelos clássicos (tabs, cards, wizard, master–detail) vivem dentro deste shell — não competem com ele. Estrutura do mundo = chrome estável + miolo com um job claro.

Continuar lendo