Tem uma reunião que eu não me esqueço.

Era uma tarde de semana normal, a equipe estava reunida para definir o escopo final do MVP antes do lançamento. A gente estava atrasado, o cronograma não fechava e ficou claro que dois épicos inteiros precisavam sair. Épicos que a alta liderança queria — e que eu também queria muito ver no produto —, e fui eu quem disse que não ia dar.

Não tinha PM na sala do Meet, não tinha design lead ou comitê de produto. Era eu, os dados que levantei e a consciência de que, tentar lançar tudo de uma vez, ia comprometer justamente o que mais importava naquele momento: colocar o produto na mão de alguém o mais rápido possível e conseguir iterar a partir disso.

Saí da reunião com uma sensação estranha. Não era exatamente orgulho. Era mais uma mistura de alívio com aquela pontada de “espera, isso era pra ser minha responsabilidade mesmo?”.

A resposta, que aprendi ao longo de dois anos como única designer, é: depende. Às vezes é; às vezes, não deveria ser. E a linha entre esses dois casos nunca fica muito clara.

­

O que imaginei que o cargo seria

Quando aceitei a posição, eu tinha uma imagem razoavelmente clara do que ia fazer: pesquisa com usuários, prototipagem, testes, iteração. Processos e abordagens que aprendi, já sabia aplicar com certa autonomia.

Isso era uma oportunidade de tocar o design de ponta a ponta, do jeito que eu acreditava que deveria ser feito. Mas o que eu não enxergava ainda era a dimensão do espaço em branco ao redor disso.

Numa semana típica do período de lançamento do nosso MVP, eu estava:

• conduzindo pesquisa com usuários,
• sintetizando as descobertas,
• priorizando backlog,
• alinhando escopo com o time de desenvolvimento,
• preparando uma apresentação pro CEO,
• construindo componentes no Design System que criei do zero, e
• tomando decisões que, em qualquer empresa com estrutura de produto já um pouco mais de maturidade, envolveriam pelo menos três pessoas diferentes.
  ­

E assim era uma semana comum minha.

­

Os chapéus que eu não sabia que ia usar

Ao longo do tempo, fui identificando quatro papéis que assumi sem que ninguém tivesse me pedido formalmente. Eles simplesmente foram aparecendo conforme o trabalho exigia, e eu fui descobrindo como utilizá-los da melhor forma.

O chapéu de PM

Priorização de backlog, definição de escopo, decisão sobre o que entra e fica de fora do release do produto são responsabilidades que, em estruturas maiores, pertencem a um Product Manager. Já na startup onde trabalho, todas passavam pela minha mesa.

A decisão de cortar os épicos de Contratos e Fundos foi o exemplo mais concreto disso. O cronograma não fechava, e esses dois épicos, embora importantes, agregavam menos valor imediato do que o que ficou.

O difícil não é só a lógica da decisão, mas também assumir que eu precisava decidir sem esperar que alguém com um cargo mais “apropriado” chegasse para resolver.

Uma coisa que aprendi sobre esse chapéu é que decidir com informação incompleta, muitas vezes, faz parte do jogo. Você raramente vai ter todos os dados que queria antes de uma reunião importante.

A habilidade não é ter a resposta perfeita, e sim saber o suficiente para defender uma posição com honestidade, e obter clareza sobre o que você ainda não sabe.

­

O chapéu de Researcher

Encontrar usuários reais para testes é um dos maiores desafios práticos de quem trabalha sozinho.

Não tem painel de recrutamento, operação de research estruturada, orçamento dedicado. Você improvisa. Negocia. Pede favor. Às vezes, o usuário que conseguiu para testar é um conhecido — você trabalha com o que tem. E, às vezes, você decide não fazer o teste.

Tomei essa decisão em alguns momentos durante o MVP: o prazo não comportava mais uma rodada de validação em campo e a hipótese estava embasada o suficiente pra apostar nela. Foi um risco calculado, e precisei ser honesta comigo mesma sobre o fato de que era um risco.

O produto lançou, coletamos feedback real depois, e iteramos. Mas isso de nenhuma forma quer dizer que eu estava confortável. Na verdade, eu estava apenas sendo pragmática; era o que a situação pedia.

Nicole Orlowski, que passou por uma experiência similar como primeira designer de uma startup, descreveu esse dilema com muita precisão:

Às vezes, você não consegue fazer o melhor trabalho possível e precisa entregar o suficiente para o produto existir com intenção de revisitar depois.

Esse é um aprendizado que parece simples escrito assim, mas que custa muito na prática quando você tem padrões altos para o próprio trabalho.

­

O chapéu de Design Lead

O Design System que a startup usa hoje construí do zero. Cada decisão de nomenclatura, cada estrutura de componente, cada token de cor e tipografia foi minha. Sem revisão de pares, sem um design lead mais sênior para validar as escolhas, sem ninguém para me dizer “esse nome de componente vai virar um problema daqui a seis meses”.

Tem um artigo do Taras Savytskyi que descreve exatamente o que é isso no dia a dia:

Você lida com a estratégia de alto nível e com o detalhe mais granular ao mesmo tempo — e é você quem precisa transitar entre os dois sem perder nenhum de vista.

A liberdade é real e encantadora:

• Poder tomar decisões de sistema sem passar por aprovação de comitê;
• Testar abordagens sem convencer quatro pessoas antes;
• Construir do jeito que você acredita que é certo.

Isso tem um valor enorme, especialmente quando você ainda está se formando como profissional e está construindo sua carreira.

Mas como nem tudo são flores… a “solidão técnica” também é real.

Tinha dias em que passava horas em dúvida sobre uma escolha de arquitetura de componentes e a única saída era pesquisar artigos, ler o que designers fizeram em contextos parecidos, tentar triangular uma resposta a partir de fontes externas. Funcionava, mas eu sempre ficava com um resíduo de “e se estiver errado?”.

Deu tudo certo! O sistema está de pé e resolve o que precisava resolver. Mas levei bastante tempo para parar de me questionar se poderia ter sido melhor.

­

O chapéu de Stakeholder Manager

Quando fui apresentar pela primeira vez ao meu CEO, levei um protótipo de um dos módulos do sistema. Ele reagiu bem, me fez perguntas, e no final apontou o que eu poderia trazer a mais na próxima vez. Foi uma conversa boa.

Mas, o que ficou mais do que o feedback em si, foi entender que ele não estava me avaliando como designer, mas que ele estava me avaliando como alguém que entende o produto e sabe traduzir esse entendimento em decisões de negócio.

Aprendi rápido que cada área da empresa fala um idioma diferente, e que é responsabilidade do designer solo ser fluente em todos.

O CEO quer saber o que foi descoberto, o que será feito com aquilo e em quanto tempo. Direto, analítico, conectado a métricas e tempo de retorno. Ele não quer saber como o processo foi conduzido, não quer ver cada etapa da pesquisa, não quer o racional completo por trás de cada decisão. Quer o resultado e o próximo passo.

O time de desenvolvimento quer clareza e viabilidade. Quer saber o que foi decidido, por que foi decidido assim, e o que isso significa para o sprint. Qualquer entregável que ignora limitações técnicas ou chega como surpresa no meio de um ciclo é um problema, não uma contribuição.

O COO quer previsibilidade. Processo, prazo, impacto operacional. Quer conseguir encaixar o que você está fazendo na visão maior de como a empresa funciona.

Há um artigo do Gessé Celestino sobre stakeholders que fala que o uso da linguagem para um UXer atravessa barreiras institucionais e hierárquicas.

Li isso há muito tempo, antes de entrar na posição, e achei bem abstrato na época. Mas pode ter certeza de que faz sentido de verdade quando você está na sala, sozinha, precisando fazer a mesma descoberta soar relevante para pessoas com objetivos completamente diferentes.

­

Os dias difíceis

Tem dias ruins.

Não do tipo que vira história engraçada depois. É o tipo em que você começa cedo, trabalha o dia inteiro, e quando para para olhar o que avançou, a resposta é: nada.

Nenhuma decisão foi tomada, algum impedimento surgiu, o que estava proposto não conseguiu ser cumprido, e você fecha o notebook com a sensação de que o dia foi perdido.

Nesses dias, a frustração é dupla:

• Uma parte é com o processo, com as circunstâncias, com o que não depende de você.
• A outra parte é consigo mesma, aquela voz que pergunta se você poderia ter feito diferente, se poderia ter antecipado o impedimento, se poderia ter se esforçado mais em alguma demanda.

O que aprendi a fazer, e que levou um tempo para descobrir, é sair do trabalho de verdade. Não abrir o computador de noite para tentar recuperar o dia. Cozinhar algo novo, sair para comer, fazer alguma coisa com a família. Usar um estímulo completamente diferente para resetar.

No dia seguinte, a clareza volta.

Um problema que parecia enorme às seis da tarde costuma ter uma escala muito mais razoável às nove da manhã.

Ser designer solo de uma empresa significa que você não tem como dividir a carga com outro colega de profissão quando está pesada.

Você precisa aprender a colocar ela no chão, mesmo que só temporariamente.

­

O que o trabalho fez por mim

Tem uma pergunta que quase sempre me fazem quando conto que sou uma designer solo na empresa: “mas você não sente falta de ter um time?”. E a resposta honesta é sim, às vezes.

A solidão de não ter com quem trocar uma dúvida rápida, de não ter ninguém para revisar uma decisão antes de ela virar realidade, pesa em alguns momentos. Mas quando olho para o que esse tempo me deu, a balança pende para o outro lado sem muita dificuldade.

Em dois anos, eu:

• Tomei decisões de produto com impacto real e sem rede de segurança,
• Construí um Design System do zero que hoje sustenta o desenvolvimento de todo o produto,
• Aprendi a apresentar para C-level de um jeito assertivo,
• Fiz pesquisa sem estrutura completa, sem painel, sem budget dedicado, e mesmo assim consegui insights que moldaram funcionalidades inteiras,
• Entendi o produto pela lente do design e pela lente do negócio ao mesmo tempo.

Como Anna Vasyukova resumiu:

O benefício de ser designer solo, é o crescimento significativo e a capacidade de aprender e experimentar de forma contínua.

Isso descreve bem o que acontece quando você é jogada em profundidade e precisa nadar. Dificilmente eu chegaria em algum desses lugares numa estrutura maior, com processos estabelecidos e responsabilidades bem delimitadas.

O caos, paradoxalmente, foi o melhor ambiente de aprendizado que eu poderia ter tido nesse momento da carreira.

­

O que eu teria dito pra mim mesma antes de aceitar

Aprenda a conversar com todas as áreas da empresa,

e aprenda o mais cedo que você conseguir. Não como soft skill secundária, mas como ferramenta de sobrevivência. Você vai precisar convencer, negociar, ceder e firmar posição na mesma semana, às vezes até no mesmo dia.
­

Aprenda a vender suas decisões,

Não basta ter o design certo. Você precisa conseguir explicar o porquê com dados, com clareza, e para públicos completamente diferentes. Um executivo não quer ver seu fluxo de pesquisa. Ele quer saber como sua decisão de design vai se traduzir em resultado para o negócio. Fale a língua de quem está na sala.
­

Aceite que você vai tomar decisões com informação incompleta,

porque é assim que funciona na prática. A sua habilidade não deve ser eliminar totalmente a incerteza, mas sim agir bem dentro dela.
­

E, encontre seus resets pessoais.

Saber quando sair do trabalho de verdade, quando desligar, quando fazer outra coisa completamente diferente, não enxergue isso como falta de comprometimento. Isso é o que vai te manter nesse cargo tempo suficiente para colher tudo o que você plantou.

Designer solo não é um cargo para quem quer conforto ou previsibilidade.

É um cargo para quem quer crescer rápido, aprender com profundidade e ter disposição pra assumir responsabilidades que extrapolam o que está escrito no título.

Se você tem disposição pra isso, vale muito a pena. Não porque é fácil, mas sim porque o que fica no final é difícil de conseguir de outra forma.

O que ninguém te conta sobre ser a única designer da empresa was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Existe uma diferença entre trabalhar num Design System e ser responsável por um.

A primeira experiência é técnica. Já a segunda é totalmente existencial.

Quando entrei na empresa como única designer, o produto ainda não tinha ido ao ar. Tinha prazo, tinha pressão, tinha um MVP que precisava sair rápido o suficiente pra gerar feedback real logo.

O Design System não era prioridade, era quase um luxo. Mas eu sabia que sem uma base consistente, cada feature nova ia custar mais do que deveria, pra mim e pro desenvolvimento.

A decisão de construir um Design System veio de mim. Não foi uma demanda do time de produto, não foi um requisito de negócio. Foi uma aposta.

E como toda aposta feita sem rede de segurança…ela me ensinou muito mais do que eu esperava.

O problema com começar tudo ao mesmo tempo

Meu primeiro instinto foi fazer tudo em paralelo. Tokens e componentes simultaneamente, porque pareciam inseparáveis, porque eu queria ver resultado rápido, porque a pressão do roadmap não esperava.

E isso foi um erro grande.

Tokens são a gramática do sistema. Componentes são as frases. Quando você constrói as frases antes de dominar a gramática, elas ficam tortas de um jeito que só aparece mais tarde, quando você já tem quarenta componentes prontos e precisa mudar uma decisão que deveria ter sido tomada no início.

Passei semanas revisitando componentes que poderiam ter nascido certos se eu tivesse ficado mais tempo na camada de tokens. Cor, tipografia, espaçamento, elevação, estados. Cada uma dessas camadas merece atenção antes de virar variável dentro de um botão.

Se eu começasse hoje, pararia na fundação até ter certeza. Não certeza absoluta, porque isso não existe em design, mas certeza suficiente pra construir em cima sem medo de que o chão vai ceder.

Manter um Design System sozinha é um trabalho diferente de construí-lo

Construir é empolgante. Você está criando algo do zero, as decisões têm peso, cada componente que sai do Figma parece um progresso visível. Tem uma energia boa nisso.

Manter…já é outra coisa.

Manter um Design System é ter uma gama de perguntas silenciosas que aparecem antes de cada feature nova:

• Esse componente já existe?
• Precisa de uma variação ou de um componente novo?
• Se eu criar uma exceção aqui, o que acontece com a regra?

Essas perguntas não têm cerimônia, não aparecem numa reunião, não estão no roadmap. Elas aparecem de supetão no meio de um fluxo, quando você está tentando resolver outra coisa.

Sem um time de design ao redor, essa responsabilidade é inteiramente sua.

O Design System vira um segundo produto dentro do produto. Com suas próprias demandas, sua própria dívida técnica, seu próprio backlog implícito.

O que me ajudou foi mudar a forma como eu documentava. Não documentar só o resultado, mas a decisão. Por que esse componente existe dessa forma. Qual o problema que ele resolve. O que ele deliberadamente não resolve.

Quando essa lógica está registrada, revisitar meses depois deixa de ser arqueologia e vira uma conversa com você mesma de um tempo atrás.

Fica bem mais fácil de evoluir sem perder coerência.

A conversa com os desenvolvedores que deveria ter acontecido antes

Existe uma fantasia no processo de design de que o sistema nasce no Figma e vai para o código de forma fluida, quase automática.

Na prática, existe um momento de tradução entre esses dois mundos, e esse momento é onde muito retrabalho mora.

Eu demorei para entender que envolver o time de desenvolvimento mais cedo não era uma concessão, e sim uma vantagem enorme.

Não porque os devs precisam aprovar o Design System. Mas porque eles são os primeiros a implementar, e implementar revela problemas que o Figma esconde:

• Nomenclatura que faz sentido visual mas é ambígua em código,
• Componentes que parecem simples de desenhar mas são complexos de construir,
• Tokens que existem no arquivo mas não têm equivalente claro na implementação.

Quando essa conversa acontece tarde, os atritos aparecem no meio de um sprint, quando o custo de consertar é maior.

Quando acontece cedo, ela entra no próprio processo de decisão. O sistema fica melhor porque foi pensado pra ser implementado, não só pra ser desenhado.

Hoje eu não finalizo nada sem pelo menos uma conversa antes. Não como validação formal, mas como checagem de realidade.

O critério de pronto que ninguém me disse que eu precisava

Existe uma armadilha específica nos Design Systems: eles nunca parecem realmente prontos.

Sempre tem um estado que falta, uma variação que poderia existir, um edge case que não foi contemplado.

Se você não define o que significa “pronto” antes de começar, o sistema vira um projeto sem fim, com componentes eternamente pela metade.

Aprendi isso da forma mais lenta possível, que é descobrindo no meio do caminho enquanto eu fazia.

Definir critérios de conclusão para cada componente antes de começar a desenhá-lo muda completamente a relação com o trabalho, porque garante que você sabe quando parar.

E isso com certeza é uma das habilidades mais subestimadas de quem trabalha sozinho.

O momento em que valeu a pena

Tem um ponto em todo Design System onde ele para de ser um projeto e vira infraestrutura. Você não sabe dizer exatamente quando ele acontece. Mas um dia, subitamente...

Você percebe que as features estão saindo mais rápido, que as decisões de interface não precisam mais ser tomadas do zero, que o componente já existe. O padrão já existe, a discussão já foi feita.

Na minha empresa, esse momento foi real. A velocidade das entregas mudou não porque o time ficou mais ágil num sentido abstrato, mas porque o sistema tinha absorvido as decisões repetidas.

Cada componente bem documentado era uma decisão que não precisava ser tomada de novo.

Esse é o retorno real de um Design System. Não é a consistência visual, embora ela apareça. Não é a beleza das telas, embora ela melhore.

É a velocidade com qualidade, sem o custo de reinventar a roda a cada sprint, e o tempo que sobra pra pensar no problema em vez de pensar na solução que você já tinha.

Construir um Design System sozinha é possível. E é muito gratificante, da forma difícil que as coisas gratificantes costumam ser. Mas é um trabalho que exige tanto de processo quanto de craft. E o processo, nesse caso, é tão parte do sistema quanto os componentes em si.