UX Design
Design de produto feito por quem também escreve código: pesquisa, protótipo e interface que chegam à engenharia prontos para virar software de verdade.
Design que sobrevive ao encontro com o código
Muito projeto de design morre na passagem para o desenvolvimento: telas lindas que ignoram estado de carregamento, mensagem de erro e o caso em que a lista vem vazia. O desenvolvedor preenche as lacunas improvisando, e o produto final não se parece com o que foi aprovado. A causa é estrutural: design e engenharia trabalhando como departamentos que se entregam documentos em vez de construírem juntos.
Aqui o design nasce dentro de uma software house. Começamos entendendo o problema com quem usa: entrevistas, análise do fluxo atual e teste dos caminhos críticos em protótipos navegáveis, antes de qualquer linha de código. Errar no Figma custa uma fração de errar em produção, e é aí que a gente prefere gastar as tentativas, com evidência no lugar de opinião.
Cada tela é desenhada com a implementação no horizonte: estados de carregamento, erro e vazio especificados, componentes que mapeiam para código, tokens de cor e tipografia prontos para virar variáveis. Acessibilidade entra no esboço, não na auditoria final. Quando o desenvolvimento é nosso, a conversa entre designer e desenvolvedor acontece na mesma squad; quando é do seu time, a entrega já fala a língua dele.
Produto lançado devolve dado, e dado alimenta a próxima decisão de design. Acompanhamos como as pessoas usam o que foi desenhado, medimos onde travam e iteramos com base nisso. A biblioteca de componentes segue viva e documentada, para a décima tela nova sair mais rápida e mais consistente que a primeira, em vez de cada entrega reinventar o produto.
- Pesquisa com usuários e mapeamento de jornadas
- Wireframes e protótipos navegáveis em Figma
- Testes de usabilidade com roteiro e síntese
- Design system com tokens e componentes reutilizáveis
- Interfaces para web e mobile prontas para handoff
- Especificação de estados de erro, vazio e carregamento
- Acessibilidade considerada desde o primeiro esboço
- Documentação viva da biblioteca de design
Discovery
Entendemos o problema, o contexto e as restrições antes de escrever a primeira linha.
Construção
Desenhamos em ciclos de protótipo e teste: as pessoas certas usam o protótipo, a gente observa onde travam e refina antes de qualquer código, quando mudar ainda é barato.
Evolução
Com o produto no ar, medimos uso real, priorizamos ajustes com evidência e mantemos o design system atualizado, para cada entrega nova sair mais consistente que a anterior.
Tenho pressa. Dá para pular a pesquisa?
Dá para dimensioná-la, não para eliminá-la. Poucas conversas com as pessoas certas, num intervalo curto, já derrubam as suposições mais perigosas do projeto. Pular essa etapa não elimina o custo dela: só o transfere para depois do lançamento, quando corrigir é mais caro. Ajustamos a profundidade da pesquisa ao risco da decisão.
Vocês só desenham ou também desenvolvem?
As duas coisas, e é essa a vantagem. O design sai de uma empresa que constrói software todos os dias, então o que a gente desenha considera viabilidade técnica desde o esboço. Você pode contratar só o design, com handoff completo para o seu time, ou o ciclo inteiro, do protótipo ao produto em produção.
Meu produto já existe e tem clientes. Dá para redesenhar sem quebrar tudo?
Dá, e é o cenário mais comum. Redesenho de produto vivo pede faseamento: começamos pelos fluxos com mais atrito, medimos o efeito de cada mudança e evoluímos por etapas, sem forçar os usuários atuais a reaprender tudo de uma vez. Big bang de interface costuma ser a pior opção, e a gente evita.
Como vocês sabem se o design funcionou?
Definindo junto com você, antes de desenhar, o que sucesso significa: concluir um cadastro sem ajuda, reduzir abandono num fluxo, diminuir chamados de suporte sobre uma tela. Depois do lançamento, medimos esses indicadores no uso real e comparamos com a linha de base. Design sem critério de sucesso é decoração.
Design system vale a pena para uma empresa do meu tamanho?
Depende menos do tamanho e mais da frequência com que você constrói interface. Se o produto evolui toda semana, uma biblioteca de componentes documentada paga o investimento rápido: menos retrabalho, mais consistência e onboarding mais curto para quem chega. Para um site que muda pouco, uma base bem organizada no Figma resolve, e a gente diz isso.
Meu time interno desenvolve. Como funciona a entrega?
O handoff é tratado como produto: biblioteca organizada no Figma, tokens exportáveis, componentes nomeados em sintonia com o código e especificação dos estados de cada tela. Fazemos uma sessão de passagem com os desenvolvedores e acompanhamos as primeiras entregas para tirar dúvidas. O objetivo é o seu time andar sozinho, não depender da gente.
Tem um projeto em mente?
A gente devolve um plano técnico claro, sem compromisso.
Vamos tirar sua ideia do papel
O investimento é tratado depois, na proposta, após a conversa de discovery.