Qual a diferença entre UX, UI e design de produto

Essa confusão parece uma questão de vocabulário. Na prática, ela aparece em orçamento, contratação, escopo e expectativa. A empresa diz:

precisamos melhorar o UX do produto.

Contrata alguém. Recebe telas mais bonitas. Seis meses depois, o produto continua com o mesmo problema de ativação, suporte ou retenção. Ninguém necessariamente fez um trabalho ruim. Talvez tenham contratado uma competência para resolver um problema que estava em outra camada.

A diferença entre UI, UX e Product Design fica mais útil quando deixamos de discutir títulos e perguntamos: que tipo de problema essa pessoa tem responsabilidade para investigar e decidir?

UI é a interface pela qual o produto é operado

UI significa User Interface. É a camada com a qual a pessoa interage diretamente:

• botões;

• campos;

• tabelas;

• tipografia;

• cores;

• espaçamento;

• ícones;

• estados;

• componentes;

• feedback visual;

• comportamento dos controles.

Reduzir isso a “deixar bonito” é um erro. Uma boa UI determina se alguém consegue distinguir uma ação primária de uma secundária, perceber que um pagamento está pendente, comparar números numa tabela ou entender que um botão está desabilitado por algum motivo. Hierarquia, legibilidade, consistência, estados, densidade, feedback: tudo isso é trabalho de interface.

O problema começa quando a empresa espera que melhorar essa camada resolva uma decisão que aconteceu antes dela. Imagine um formulário com onze campos desnecessários. Você pode melhorar espaçamento, componentes, labels e hierarquia. O formulário ficará melhor. Continuará pedindo onze coisas desnecessárias. UI consegue melhorar como uma decisão de produto aparece e é operada. Ela não tem, por definição, o poder de tornar uma decisão ruim automaticamente boa.

Uma interface bonita pode esconder um problema por mais tempo

Esse é um dos motivos pelos quais projetos de redesign às vezes frustram. O resultado visual é evidente. Antes e depois funcionam muito bem numa apresentação. Mas o problema do produto talvez fosse: o cliente precisa esperar dois dias para receber o resultado, só um administrador consegue concluir a configuração, o relatório não contém a informação de que o financeiro precisa, a integração exige trabalho manual toda semana, o cliente não entende por que deveria usar aquela funcionalidade.

Nenhuma dessas coisas desaparece porque o card ganhou melhor hierarquia. Uma interface ruim pode piorar um produto bom. Uma interface excelente também pode tornar mais agradável um produto que continua resolvendo o problema errado. Por isso uma pergunta simples no início do projeto muda bastante o escopo: já sabemos qual problema precisa ser resolvido ou ainda precisamos descobrir?

UX é maior que a interface

Don Norman e Jakob Nielsen definem experiência do usuário como todos os aspectos da interação do usuário final com uma empresa, seus serviços e seus produtos. Essa definição é útil justamente porque não termina na tela. Em um SaaS B2B, a experiência pode incluir descobrir o produto, entender o preço, ser contratado, receber convite, configurar a conta, integrar dados, usar a interface, pedir ajuda, receber uma cobrança, resolver um problema e cancelar. Tudo isso participa da experiência.

É possível ter uma interface excelente e uma experiência ruim. Imagine um produto cuja tela de conciliação seja muito bem desenhada: filtros ótimos, tabela legível, estados claros. Mas os dados só atualizam no dia seguinte e o financeiro precisa fechar a operação hoje. O problema não é a tabela. A experiência daquela tarefa continua ruim.

Usabilidade também não é sinônimo de UX

Os termos frequentemente são usados como se fossem iguais. Não são. Usabilidade trata de qualidades como facilidade de aprender, eficiência e capacidade de alguém utilizar uma interface para atingir um objetivo. UX é mais ampla. Uma tarefa pode ser muito fácil de executar e ainda produzir uma experiência ruim. Por exemplo:

Cancelar assinatura

Um botão extremamente claro pode tornar o cancelamento muito fácil de executar. Mas se a empresa cobra novamente depois do cancelamento, a experiência continua péssima. O inverso também acontece: um produto pode entregar enorme valor e ainda obrigar o usuário a enfrentar uma interface ruim para chegar até ele. Uma coisa não substitui a outra.

Product Design muda a amplitude da pergunta

Aqui a distinção fica menos padronizada. Empresas usam “Product Designer”, “UX Designer”, “UX/UI Designer” e outros títulos para escopos bastante diferentes. Então eu evitaria uma definição do tipo:

UI faz tela, UX faz experiência e Product Design faz negócio.

Na prática existe bastante sobreposição. Uma forma mais útil de entender Product Design é olhar para a responsabilidade que entra no trabalho. Um Product Designer pode participar de perguntas como: qual problema vale resolver? Para qual usuário? Por que agora? Que comportamento precisa mudar? Qual hipótese estamos testando? Que restrições técnicas existem? Como isso afeta a operação? Como saberemos se funcionou? O que não deveríamos construir?

E depois levar essas decisões até fluxo, interação e interface. A diferença importante é essa: o trabalho não começa obrigatoriamente com uma solução já definida. Às vezes a melhor entrega inicial é uma tela. Às vezes é descobrir que a tela pedida não resolve o problema.

O mesmo pedido pode produzir três trabalhos diferentes

Imagine a seguinte reclamação:

Os clientes dizem que o relatório é difícil de usar.

Parece uma demanda de interface. Talvez seja.

Uma investigação focada em UI

O problema pode estar na própria apresentação: filtros difíceis de encontrar, hierarquia fraca, tabela ilegível, informações sem agrupamento, ações escondidas. Nesse cenário, melhorar a interface resolve um problema real.

Uma investigação de UX

Talvez o relatório seja claro, mas esteja desconectado da forma como o cliente trabalha. Durante a pesquisa aparece que quase ninguém analisa aquilo dentro do produto. Todo mundo exporta para Excel porque precisa cruzar os dados com outro sistema. Agora a pergunta mudou. Não é mais “como deixar o relatório mais fácil?”. É “por que o cliente precisa sair daqui para concluir a tarefa?”.

Uma decisão de Product Design

Agora imagine que os dados mostrem: 80% dos clientes exportam, os maiores clientes fazem o cruzamento manualmente, suporte recebe pedidos de integração toda semana. Talvez existam três opções: redesenhar o relatório, melhorar a exportação ou construir uma integração que elimina a tarefa manual. A decisão agora envolve usuário, tecnologia, esforço, estratégia e resultado esperado. E a resposta pode ser: não redesenhar o relatório. Isso também é design.

A diferença está muito em quando o designer entra na conversa

Uma pessoa pode ter repertório de Product Design e trabalhar como executora de UI. Não porque seja incapaz de fazer outra coisa, mas porque recebeu isto:

O fluxo já está definido. Precisamos dessas seis telas até sexta.

A maior decisão do projeto já aconteceu antes de ela entrar. Agora compare com:

Clientes estão abandonando esta etapa. Precisamos descobrir por quê e decidir o que mudar.

O segundo briefing abre outra responsabilidade: pesquisa, dados, hipóteses, fluxo, regra, trade-offs, interface, medição. Por isso olhar apenas para o cargo pode enganar. Escopo e autonomia dizem mais sobre a função real do que o título no LinkedIn.

UI, UX e Product Design não são níveis de senioridade

Essa distinção é importante. Product Designer não é automaticamente uma evolução de UI Designer. Uma pessoa especializada em interface pode ter enorme profundidade em sistemas visuais, acessibilidade, design systems, tipografia, motion, densidade de informação, visualização de dados e interação. Um especialista em UX Research pode ter uma profundidade completamente diferente. Product Design pede outro conjunto de competências e, dependendo da empresa, combina partes dessas disciplinas.

Não existe motivo para transformar isso numa escada:

UI → UX → Product Designer.

São campos que se sobrepõem. O que muda é o tipo de responsabilidade assumida.

O título da vaga diz menos do que a descrição

No mercado, você pode encontrar duas vagas chamadas “Product Designer”. Na primeira:

receber wireframes do PM e criar interfaces no Figma.

Na segunda:

investigar problemas, conduzir discovery, trabalhar com dados, definir hipóteses com PM e engenharia, prototipar, acompanhar desenvolvimento e medir resultados.

É o mesmo título. Não é o mesmo trabalho. Na contratação, eu olharia menos para o nome da vaga e mais para algumas perguntas: a pessoa recebe o problema ou recebe a solução? Pode questionar o escopo? Tem acesso a clientes? Tem acesso a dados? Participa de priorização? Trabalha com engenharia antes da entrega? Acompanha o que aconteceu depois que entrou em produção? As respostas mostram muito mais sobre a função.

O mesmo vale para contratar um estúdio

Imagine dois orçamentos.

Escopo A

Redesenho de 15 telas conforme fluxo fornecido pelo cliente.

Existe uma entrega clara. O problema e a solução já estão relativamente definidos.

Escopo B

Investigar por que empresas não concluem o onboarding, mapear regras e estados, identificar causas de abandono, propor alternativas, validar a direção e redesenhar o fluxo.

Aqui você não está comprando apenas tela. Está comprando participação na definição do problema e da solução. Naturalmente, prazo, processo e preço não deveriam ser os mesmos. Comparar os dois apenas pelo número de telas é comparar trabalhos diferentes.

Portfólio bonito comprova uma coisa muito específica

Uma coleção de telas excelentes demonstra capacidade visual. Isso é valioso. Mas não comprova automaticamente que aquela pessoa participou das decisões que produziram o produto. Para avaliar Product Design, eu procuraria outra coisa. Dado um projeto: qual era o problema original? Como vocês descobriram que esse era o problema? Que restrições existiam? Que alternativas foram consideradas? O que vocês decidiram não fazer? Que regra de negócio mudou? O que aconteceu depois do lançamento?

Não é necessário que todo case tenha um gráfico perfeito de crescimento. Muitas empresas nem possuem instrumentação suficiente para isso. Mas deveria existir uma história de decisões. Se o case começa no wireframe e termina no mockup final, ele conta principalmente a história da interface.

Um sinal importante: todo problema chega ao design como pedido de tela

Observe o backlog.

Criar modal de upgrade.

Fazer dashboard.

Adicionar página de relatório.

Criar tela de configurações.

Redesenhar onboarding.

Todos já são soluções. Talvez estejam corretas. Mas ninguém consegue saber porque o problema desapareceu do pedido. Uma mudança simples melhora a conversa:

Usuários não entendem por que precisam fazer upgrade.

Gestores não conseguem identificar rapidamente contas em risco.

Financeiro exporta relatório toda semana para fechar o mês.

Administradores não conseguem configurar permissões sem suporte.

Agora existe espaço para decidir. A solução pode continuar sendo um modal, dashboard ou tela. Só não está decidida antes da investigação.

Qual profissional você precisa?

Não existe um diagnóstico perfeito em três frases, mas o tipo de problema dá pistas.

Você já sabe o que precisa ser construído e a interface é o principal problema

Talvez a maior necessidade esteja em UI e Interaction Design: hierarquia, componentes, estados, responsividade, consistência, legibilidade.

A tarefa existe, mas as pessoas não conseguem concluí-la bem

O problema pede olhar de UX: fluxo, compreensão, usabilidade, informação, contexto, pesquisa.

Você ainda não sabe qual solução deveria existir

Aqui Product Design ganha mais importância. É preciso investigar comportamento, negócio, tecnologia e restrições antes de assumir que a resposta é uma interface específica.

Esses cenários podem coexistir no mesmo projeto. É normal.

Não tente descobrir tudo pelo motivo de cancelamento

Perguntar por que clientes cancelam é útil. Mas eu não usaria isso como teste definitivo para saber se o problema é UI, UX ou produto. Uma pessoa pode responder:

não vi valor.

E o motivo real estar em onboarding ruim, implementação difícil, feature incompreensível ou expectativa comercial errada. Outra pode dizer:

é difícil de usar.

Mas a dificuldade pode vir de uma regra operacional complexa que nenhuma mudança visual consegue remover. Feedback é evidência. Não diagnóstico pronto. Vale cruzá-lo com comportamento, dados, suporte, pesquisa, processo e contexto comercial. É justamente aí que a diferença entre “desenhar uma tela” e “investigar um problema de produto” fica mais clara.

A distinção que realmente importa

Se você esquecer os títulos, sobra uma pergunta melhor: até onde essa pessoa pode ir para resolver o problema? Pode alterar apenas a apresentação? Pode alterar o fluxo? Pode questionar a regra? Pode conversar com usuários? Pode propor não construir? Pode discutir impacto comercial? Pode trabalhar com engenharia na restrição? Pode acompanhar o resultado depois?

Quanto maior essa responsabilidade, mais o trabalho se aproxima do que muitas empresas hoje chamam de Product Design. Isso não torna UI menos importante. Nem UX uma etapa intermediária. Significa apenas que produtos precisam de decisões em níveis diferentes. E contratar bem começa por saber qual dessas decisões ainda está em aberto. Porque pedir “UX” quando você quer apenas novas telas produz uma expectativa ruim. E contratar alguém para fazer Product Design depois que problema, solução e escopo já foram decididos produz outra.

Na Uxbrand, o trabalho começa especialmente quando a interface ainda não é a resposta. Em SaaS, fintech e plataformas B2B, isso normalmente significa entender fluxo, regra de negócio, estados, operação e restrições antes de decidir como tudo isso deve aparecer na tela.

Sobre por que essa profundidade também pode virar vantagem comercial em SaaS, vale continuar por UX como diferencial competitivo no SaaS.

Fontes

Nielsen Norman Group. The Definition of User Experience (UX), Don Norman e Jakob Nielsen, publicado em 8 de agosto de 1998. Define experiência do usuário como abrangendo todos os aspectos da interação do usuário final com a empresa, seus serviços e seus produtos.

Nielsen Norman Group. Usability 101: Introduction to Usability, Jakob Nielsen. Referência para a distinção entre usabilidade e experiência do usuário e para atributos como facilidade de aprendizado, eficiência e satisfação durante o uso.