---
type: article
slug: hands-on-para-head-de-design
title: O head de design que ainda abre o Figma
summary: Hands-on dá ao head de design vocabulário, diagnóstico rápido e credibilidade técnica. Mas pode virar gargalo e microgerenciamento. Onde fica o equilíbrio?
date: 2026-09-03
heroImage: /images/articles/obj-hands-on-hero.webp
tags:
  - liderança
  - design
  - carreira
---

Um head de design que só aprova acaba virando gerente de status. Quando ainda desenha, prototipa e entra na crítica de forma, ganha autoridade real sobre a qualidade do trabalho, e passa a correr riscos que valem ser conhecidos antes.

## Por que faz diferença

Vocabulário compartilhado é o ganho mais imediato. Feedback vago como "não está com a cara da marca" não ensina nada. Quem ainda edita token e mexe em componente consegue apontar qual decisão de forma quebrou a tese, além de dizer que algo está errado.

Problema estrutural também aparece mais cedo. Olhando só o entregável pronto, o head vê sintoma. Participando da construção, vê a causa antes de virar padrão: um token de forma mal definido, que vai se repetir em cem componentes, só aparece pra quem esteve dentro do arquivo, e não pra quem revisou o print no fim do sprint.

A credibilidade muda de lugar. Autoridade e accountability precisam estar na mesma pessoa, e quando o head executa, a defesa de um critério técnico diante de stakeholder vem de quem conhece o custo real da mudança.

E tem a calibração. Pra exigir nível sênior, é preciso saber na prática quanto esforço um resultado bom custa. Sem isso, o head aceita entrega mediana achando que é o teto do time, ou cobra um teto que nem ele alcança.

![Quem ainda mexe no componente consegue apontar a decisão exata que quebrou a tese](/images/articles/hands-on-head-de-design-pareando.webp)

## Onde vira armadilha

O risco mais comum é virar gargalo de aprovação. Hands on sem delegação estrutural transforma o head em revisor de tudo, e o time para de decidir sozinho porque sabe que o líder vai refazer de qualquer forma.

![Quando o líder pega o mouse, o time para de decidir](/images/articles/hands-on-head-de-design-gargalo.webp)

Microgerenciamento costuma chegar com nome de rigor. Apontar que o token de espaçamento quebrou a grade é uma coisa. Reescrever a solução do designer pixel a pixel é outra, e ensina o time a parar de propor.

Tem ainda a ausência estratégica. Cada hora dentro do Figma é uma hora fora da conversa de roadmap, orçamento e território com as outras lideranças. O head que só executa perde a cadeira onde a decisão de negócio acontece, e o design volta a ser tratado como serviço.

O último risco é o ego com crachá de padrão de qualidade. Quando a defesa técnica vira desculpa pra impor gosto pessoal, hands on deixa de ser ferramenta de liderança e vira controle. A régua precisa ser a [tese de marca](/artigos/emocao-no-design-de-produto) e o [ICP validado](/cases/bipa), nunca a preferência de quem está no comando.

## Onde fica o equilíbrio

Horas na ferramenta não medem nada. A pergunta que ajuda é se aquele hands on está gerando um contexto que relatório nenhum entrega, ou se é desconfiança de que o time não vai fazer do jeito certo.

> **Pra você, founder:** ao avaliar um head de design, hands on genuíno é sinal de credibilidade técnica, e não de microgerenciamento. O risco aparece quando ele vira gargalo de aprovação ou some das conversas de negócio.
>
> **Pra você, designer:** hands on de quem lidera devia ensinar vocabulário e apontar causa, sem reescrever a solução pixel a pixel. Se as propostas pararam de surgir porque tudo volta refeito, vale levar isso pra conversa: é sinal de que o equilíbrio quebrou.
>
> **Pra você, tech:** o mesmo dilema existe pro tech lead. Continuar codando dá vocabulário e diagnóstico rápido, e também pode virar gargalo de review e ausência na conversa de arquitetura com outras lideranças.