Design system no portfólio: como mostrar num case

Um case de design system corre o risco de virar só telas de componentes. A NN/g define design system como um conjunto completo de padrões para gerir o design em escala, usando componentes e padrões reutilizáveis, e o descreve como um conjunto de ferramentas para designers e desenvolvedores trabalharem mais rápido. Nossa recomendação: o case deve contar como o time passou a trabalhar com essa ferramenta, inclusive na versão em inglês.

O que é um design system, segundo a NN/g?

Um design system tem duas partes: o repositório e as pessoas que o mantêm. No artigo Design Systems 101 (Therese Fessenden, 2021, revisado em agosto de 2026), a NN/g descreve o repositório como um conjunto que costuma ter um guia de estilo, uma biblioteca de componentes e uma biblioteca de padrões.

Parte	O que a NN/g descreve
Guia de estilo	Diretrizes de implementação, referências visuais e princípios de design, como marca, tom de voz e padrões visuais e de interação
Biblioteca de componentes	Elementos de interface reutilizáveis, com nome, descrição, atributos, estados e trechos de código
Biblioteca de padrões	Agrupamentos de elementos e layouts reutilizáveis, como estruturas de conteúdo e templates
Equipe	No mínimo um designer de interação, um designer visual e um desenvolvedor; idealmente também pesquisa, arquitetura e conteúdo, quando esses papéis existem

A NN/g lista benefícios de um design system bem implementado: replicar o trabalho de design e desenvolvimento com rapidez e em escala, liberar o tempo do time para problemas mais complexos, criar uma linguagem comum entre equipes, garantir consistência visual entre produtos e servir de referência para designers juniores. Também lista dificuldades: criar e manter exige tempo e uma equipe dedicada, ensinar os outros a usar leva tempo, e projetos vistos como únicos podem parecer não precisar de componentes reutilizáveis.

Case de design system: a história de uma mudança no time

Neste post, o case de design system é tratado como a história de uma mudança no jeito de trabalhar de um time, e não só como um conjunto de telas. A NN/g descreve o sistema como ferramenta; a partir disso, este post entende que o que ele entrega, para o seu case, tende a ser o efeito no trabalho: replicação mais rápida, menos inconsistência, menos tempo em ajustes visuais. Esses efeitos só entram no case se você os observou ou mediu, e com os seus números.

Há também um risco que a NN/g aponta em 5 Steps to Creating a UX-Design Portfolio (Rachel Krause, 2019): a ideia equivocada de que um portfólio de design é só UI final e screenshots. No design system, isso se traduz, na nossa leitura, em um case com muitas telas de componentes e nenhuma explicação de como o time passou a usá-los. Para a lógica de output e outcome aplicada ao case, veja outcomes vs outputs no portfólio de UX.

O que mostrar no case de design system?

Use os itens que a NN/g recomenda para um case study de portfólio de UX e adapte cada um (as adaptações são sugestões deste post).

Item do case (NN/g)	Adaptação para design system (sugestão)
O problema ou a hipótese	Qual dor de consistência, retrabalho ou comunicação existia, e como você a identificou
O seu papel e como colaborou	Que parte do sistema foi sua e com quem trabalhou, como desenvolvedores e outros designers
Como chegou à solução	Qual caminho seguiu (adotar, adaptar ou criar) e por quê
Como a solução resolveu o problema	Como o sistema passou a ser usado pelo time
Desafios	Manutenção, adoção e o que ficou de fora
Efeito em usuários e negócio	O que mudou no trabalho e, se possível, no produto, com evidência real
O que aprendeu	O que faria diferente

Exemplo ilustrativo (hipotético, sem números): “Trabalhei com [N] desenvolvedores e um product owner. Adaptei [sistema aberto] porque [razão]. Depois de [período], as revisões de design passaram a discutir [tema] em vez de [tema anterior].”

Como contar a decisão: adotar, adaptar ou criar?

A NN/g descreve três abordagens: adotar um design system existente, adaptá-lo ou criar o seu. Segundo o artigo, quanto mais personalizada a solução, mais tempo e dinheiro ela exige, e adotar um sistema existente é a abordagem de menor custo. Criar o seu pode compensar quando a organização tem necessidades que os sistemas abertos não atendem, e a economia de adaptar diminui à medida que as personalizações crescem. Para uma prova de conceito ou um protótipo que deve mudar, a NN/g diz que um design system completo provavelmente não traz retorno desejável no curto prazo.

Para o case, a sugestão deste post é contar a decisão com o raciocínio por trás dela: o que o time precisava, que alternativas existiam e o que pesou. É esse raciocínio, e não o tamanho do sistema, que mostra como você decide.

Como escrever o resultado sem inventar número?

Escreva o resultado como mudança no trabalho do time, com dado seu e verdadeiro. Os modelos abaixo são deste post, com lacunas para preencher; eles não trazem números reais.

Em vez de (output)	Escreva (modelo em inglês)
Built a design system with [N] components.	Built a design system that cut [handoff time or rework] from [X] to [Y] for [N] teams.
Documented the component library.	Documented [N] components with usage guidelines, which [observed change] for [team].
Adopted [existing system] and adapted it.	Adapted [existing system] to our needs after comparing adopt, adapt and build, reducing [effort or inconsistency] by [measure].

Se você não tem métrica, diga o que observou e como: por exemplo, o que mudou nas revisões de design depois do sistema (se você registrou). Não invente um número para preencher a lacuna.

O que evitar no case?

Esta lista é avaliação deste post, apoiada em dois pontos da NN/g: o seu papel e os desafios entre os itens do case.

• Só telas de componentes. Sem explicação de como o time os usa, o case mostra o output, e não a mudança.
• Papel vago. Um design system envolve várias pessoas, então diga o que foi seu. A NN/g lista o seu papel entre os itens do case.
• Número sem origem. Se o dado vem de um teste, de uma métrica ou de uma observação, diga qual.
• Esconder o que não deu certo. A NN/g recomenda incluir os desafios e o que não seguiu adiante, e o design system tem os seus: manter o sistema e ensinar o time a usá-lo.

Vagas fora do Brasil: o que o case sinaliza

Para uma vaga fora, o case de design system pode mostrar que você trabalha em colaboração. A NN/g diz que uma linguagem comum reduz tempo perdido com falhas de comunicação, principalmente quando as equipes ficam geograficamente dispersas; isso é um ponto de partida para a conversa, e não uma promessa de resultado. Em entrevista, esteja pronto para explicar o seu papel, o caminho escolhido e o que mediu, em inglês, sem exagerar o que foi seu (sugestão deste post).

Checklist antes de publicar o case

• O case diz qual caminho você seguiu (adotar, adaptar ou criar) e por quê.
• O seu papel e as pessoas com quem trabalhou estão claros.
• Há pelo menos uma frase de resultado com dado real ou observação descrita.
• As telas de componentes têm contexto: onde e como foram usadas.
• O texto em inglês foi revisado. Para a estrutura geral, veja case study de UX em inglês.
• O foco do portfólio combina com a vaga: veja portfólio UX ou UI para vagas globais.

Para defender as decisões do case em uma entrevista, veja como defender decisões de design em inglês. Se você usa IA para gerar telas ou componentes, veja os limites em vibe coding vs vibe designing. Mais textos sobre portfólio na categoria portfólio.