As Qualidades da Experiência do Usuário são diversas. Algumas são previsíveis e controláveis, como a Usabilidade e a Acessibilidade. Outras são menos previsíveis e deveras incontroláveis, como a Afetividade e a Beleza. Essas qualidades difíceis de mensurar costumam ser desconsideradas no projeto de software por serem "subjetivas demais" ou irrelevantes. O resultado disso é a redução do software ao status de commodity em nossa sociedade, ou seja, um objeto sem qualidades únicas.
Para recuperar o valor social do software, é preciso reposicioná-lo como uma oferta na Economia da Experiência, servindo como palco para interações estéticas e transformadoras. Isso implica em projetar software de uma maneira completamente diferente do paradigma de controle que orienta a maior parte dos projetos de software hoje.
Neste minicurso oferecido no XVII Simpósio Brasileiro de Qualidade de Software, foi apresentada uma abordagem de projeto de software baseada no paradigma da possibilidade. Essa abordagem inclui não só técnicas de avaliação, mas também de observação, percepção, sensação e criação das Qualidades da Experiência do Usuário. As técnicas aproveitam habilidades como a intuição, o talento artístico e a criatividade para lidar com as qualidades imprevisíveis e incontroláveis. O objetivo desta abordagem é produzir softwares que tenham tantos sentidos quanto uma obra de arte e tantos usos quanto um objeto de design.
Slides
Download dos slides em PDF
Áudio
Projeto Possibilístico para as Qualidades da Experiência do Usuário [MP3] 2h05min
Transcrição
Projeto possibilístico para as qualidades da experiência do usuário é um conceito ainda experimental, que pretendo sustentar academicamente no futuro. As práticas e técnicas apresentadas já possuem fundamentação, e ao longo da exposição são mencionadas diversas referências que podem ser fornecidas posteriormente. Trata-se, portanto, de uma apresentação acadêmica com caráter prático.
O termo "possibilístico" surgiu a partir de um aprofundamento nos estudos sobre qualidade de software, especialmente por meio das normas ISO. Ao analisar esses modelos -- com apoio de pesquisas e interações no grupo de Engenharia de Software -- torna-se evidente um aumento progressivo do interesse por qualidades relacionadas à usabilidade ao longo do tempo. Um estudo de 2000, de Gordieiev et al (2015) e colegas, confirma esse crescimento entre 1977 e 2010. No entanto, mesmo nas normas mais recentes, como a ISO de 2010, o termo "experiência do usuário" ainda não aparece explicitamente.
Em contraste, no mercado esse termo se tornou ubíquo e praticamente obrigatório. Apesar de resistências iniciais, consolidou-se como padrão da indústria, especialmente em cargos como "UX designer". Ainda assim, trata-se de um termo problemático. A provocação proposta é a adoção da abreviação "Exu" para "experiência do usuário" em português, não apenas como correção linguística, mas também como referência à entidade da cosmologia brasileira frequentemente mal compreendida -- analogia ao próprio papel ambíguo e indefinido do profissional de UX, que transita entre diferentes áreas sem uma definição clara.
Essa provocação busca estimular uma reflexão mais profunda sobre o campo. Enquanto o design acadêmico já incorpora o conceito de experiência do usuário, a computação ainda privilegia a usabilidade. Contudo, desde meados dos anos 2000, o próprio mercado reconhece que usabilidade é apenas uma dimensão entre várias que compõem a experiência do usuário.
Peter Morville propõe um modelo bastante difundido no mercado -- o UX Honeycomb -- que organiza a experiência do usuário em qualidades como encontrabilidade, credibilidade, acessibilidade, desejabilidade, utilidade e valor. Existem diversos modelos semelhantes, muitos baseados na intuição e na experiência de seus criadores. O principal problema desses modelos é a dificuldade de mensuração: embora úteis como referência conceitual, eles não permitem avaliar de forma precisa essas qualidades em contextos experimentais ou operacionais.
Mais recentemente, surgem tentativas de tornar essas qualidades mensuráveis. Um exemplo é o meCUE (http://mecue.de), uma ferramenta baseada em questionários que permite avaliar não apenas utilidade e usabilidade -- já consolidadas -- mas também aspectos mais recentes, como estética visual, status social, comprometimento, emoções positivas e negativas, além de qualidades que emergem no longo prazo, como lealdade e intenção de recomendação. Trata-se de um modelo mais abrangente que as normas ISO e que outros frameworks tradicionais, com a vantagem de ser open source e validado academicamente.
Apesar disso, o MEQ ainda é pouco conhecido na indústria. No mercado, o modelo mais difundido é o HEART, desenvolvido por pesquisadores da Google. Ele organiza a experiência em cinco dimensões: Happiness, Engagement, Adoption, Retention e Task Success. Diferentemente do MEQ, o HEART não define métricas diretamente; funciona como um framework heurístico que orienta a definição de objetivos, sinais e métricas específicas para cada contexto. Esses modelos evidenciam uma expansão contínua das qualidades associadas à experiência do usuário. No entanto, também revelam uma tensão central: embora haja um esforço crescente para medir essas qualidades, permanece a dificuldade de capturá-las de forma clara e operacional, especialmente aquelas mais subjetivas e contextuais.
Um estudo conduzido por Law e colegas, em 2014, investigou a percepção de profissionais de UX sobre a mensurabilidade das qualidades da experiência do usuário. Os resultados mostram um cenário ambíguo: algumas qualidades, como eficiência, são amplamente consideradas mensuráveis, enquanto outras, como usabilidade, geram discordância. Há ainda um conjunto significativo de qualidades que muitos profissionais consideram não mensuráveis.
Entre essas qualidades estão aspectos como encantamento, identificação, autorrealização e até amor. Paradoxalmente, são justamente essas dimensões que os profissionais afirmam conseguir influenciar e valorizar em seus projetos. É comum, por exemplo, a promessa de que um produto fará os usuários "amarem" a experiência -- mesmo sem uma forma clara de mensurar esse efeito. Essa tensão também aparece no próprio nome do framework HEART, que sugere uma aproximação com dimensões emocionais e subjetivas. Há uma tentativa implícita de legitimar a atuação em aspectos que escapam à mensuração tradicional.
A partir disso, emerge uma questão central: embora mensurar seja importante para garantir reconhecimento, justificar decisões e obter espaço dentro das organizações, a mensuração não responde ao problema fundamental. Uma vez que a experiência do usuário passa a ser valorizada, surge o desafio de como, de fato, criar essas qualidades.
Esse deslocamento -- da mensuração para a criação -- marca uma mudança importante de enfoque. Enquanto a engenharia de software tende a privilegiar o que pode ser medido, a discussão sobre como produzir experiências significativas permanece pouco desenvolvida nesse campo, sendo mais explorada em áreas como design e arte.
A dificuldade de tratar a experiência do usuário como requisito pode ser ilustrada por uma piada do Dilbert: diante de um sistema com mais de 400 funcionalidades, alguém sugere adicionar à lista de requisitos que ele deve ser "fácil de usar". O humor está no fato de que facilidade de uso não é uma funcionalidade isolada, mas um efeito emergente da combinação de várias decisões de projeto. Ou seja, não é algo que se possa especificar diretamente como requisito e garantir sua realização.
As qualidades da experiência do usuário -- incluindo emoções, sensações e percepções subjetivas -- não são atributos do software em si, mas da relação entre usuário e sistema. Por isso, não podem ser completamente controladas nem asseguradas apenas por especificação. Elas dependem também do que o usuário faz com o software, frequentemente de maneira imprevisível.
Um exemplo dessa imprevisibilidade é o uso de uma divisória de papelão entre jogadores em jogos multiplayer locais. Essa solução improvisada impede que um jogador veja a tela do outro, criando um novo tipo de experiência, baseada em surpresa e incerteza. Trata-se de uma adaptação criativa dos próprios usuários, não prevista pelos desenvolvedores, que altera significativamente a qualidade da experiência. Esse tipo de intervenção evidencia que a experiência do usuário não é determinada apenas pelo design do sistema, mas também pelas apropriações e invenções dos usuários. Em vez de seguir passivamente o que foi projetado, eles reinterpretam e transformam o uso, produzindo novas possibilidades de experiência.
A tentativa de controlar diretamente a experiência humana encontra limites não apenas técnicos, mas também éticos. Um exemplo extremo é o Project MKUltra, conduzido entre as décadas de 1950 e 1970, no qual a CIA realizou experimentos sem consentimento para tentar controlar a mente das pessoas. Hoje, esse tipo de abordagem é amplamente considerado antiético, especialmente nas ciências que estudam a experiência humana.
Diante dessa impossibilidade de controle, uma alternativa recorrente é o uso de modelos probabilísticos e ferramentas de analytics, como as da Google, que permitem rastrear comportamentos e prever ações dos usuários. Esses sistemas analisam fluxos de interação, taxas de conversão e padrões de abandono, oferecendo uma base quantitativa para tomada de decisão. No entanto, o uso direto desses dados apresenta problemas. Práticas como testes A/B tendem a validar elementos isolados sem considerar a experiência como um todo, resultando em interfaces fragmentadas -- um "efeito Frankenstein". Além disso, ao buscar otimizar métricas agregadas, o design passa a se orientar por uma média estatística que não corresponde a nenhum usuário real.
Esse foco no "usuário médio" leva à padronização excessiva e à perda de diferenciação. Em vez de criar experiências significativas, o projeto tende a produzir soluções genéricas, pouco marcantes e facilmente substituíveis. Assim, embora analytics ofereça ferramentas poderosas de observação e previsão, seu uso indiscriminado pode reduzir a qualidade da experiência ao nivelá-la por baixo.
A orientação por médias estatísticas e otimização de métricas tende a produzir experiências genéricas, contribuindo para a comoditização do software. Aplicativos tornam-se facilmente replicáveis, com baixo valor percebido e pouca diferenciação. Em mercados saturados -- como lojas de apps com milhões de opções -- criar "mais um" produto semelhante não é suficiente para se destacar.
Essa lógica pode ser compreendida à luz do livro The Experience Economy, que descreve uma mudança de paradigma: da oferta de produtos e serviços para a oferta de experiências. Serviços já representam um nível de customização, mas experiências vão além, sendo estruturadas de forma única e personalizada para cada pessoa -- o que permite agregar valor e justificar preços mais altos.
O exemplo clássico é o da Starbucks, que cobra múltiplas vezes o preço de um café comum não apenas pela bebida, mas pela experiência: personalização (nome no copo), ambiente, possibilidade de permanência, acesso a Wi-Fi e construção de marca. O produto em si é um commodity, mas a experiência o diferencia. Quando essa personalização se perde, o valor também diminui. Produtos padronizados tornam-se facilmente copiáveis e substituíveis. Portanto, para evitar a comoditização, é necessário investir em diferenciação por meio da experiência -- criando ofertas únicas, ajustadas a contextos e usuários específicos. Nesse sentido, a experiência do usuário deixa de ser apenas um conjunto de métricas e passa a ser um vetor estratégico de valor, orientando o design para a customização, singularidade e relevância contextual.
A discussão sobre experiência ganha concretude com um experimento prático envolvendo o consumo de um bombom. Embora todos sigam as mesmas instruções, as experiências resultantes são distintas: cada pessoa atribui significados próprios, produzindo vivências únicas. Isso evidencia que a experiência não está no objeto em si, mas na forma como ele é vivido e interpretado. O contraste entre o bombom como commodity (baixo custo, consumo padronizado) e como experiência (memória significativa, contexto narrativo, estímulos sensoriais) revela como o valor pode ser ampliado. Técnicas como ambiguidade, suspense, surpresa, estimulação multissensorial e construção narrativa são utilizadas para transformar uma ação trivial em uma experiência marcante.
A partir disso, propõe-se o conceito de projeto possibilístico, que abandona a ideia de controle total e trabalha com incerteza. Em vez de buscar garantir resultados específicos, esse tipo de projeto explora possibilidades, especula cenários -- inclusive extremos -- e valoriza aspectos negligenciados pelos concorrentes. Há também uma abertura para o uso de sensibilidade artística no processo de criação. Nesse paradigma, a incerteza deixa de ser um problema a ser eliminado e passa a ser um recurso. O projeto não busca prever exatamente o que o usuário fará, mas criar condições para que experiências relevantes possam emergir. Assim, o foco desloca-se da definição de resultados para a ampliação do espaço de possibilidades.
A incerteza pode ser compreendida por meio de um modelo popularizado por Donald Rumsfeld, que distingue entre o que se sabe que se sabe, o que se sabe que não se sabe e o que não se sabe que não se sabe. Este último grupo -- os "unknown unknowns" -- representa os maiores riscos, pois escapa completamente à previsão e ao controle.
Essa ideia é aprofundada por Nassim Nicholas Taleb no livro The Black Swan, que descreve eventos raros e improváveis que, quando ocorrem, têm impacto transformador. O exemplo histórico do cisne negro -- cuja existência era considerada impossível até ser observado na Austrália -- ilustra como uma única ocorrência pode reconfigurar completamente um sistema de conhecimento.
No contexto do software, esses eventos também ocorrem. Um exemplo é o lançamento do iPod pela Apple, que pode ser interpretado como um "cisne negro" na indústria. Embora tecnicamente inferior em alguns aspectos aos concorrentes da época, destacou-se por priorizar a experiência do usuário, desencadeando uma mudança significativa no mercado e contribuindo para a ascensão da empresa. Esse tipo de ruptura evidencia que a inovação não decorre apenas de otimizações incrementais ou previsíveis, mas da capacidade de lidar com o inesperado. Projetar considerando apenas o provável limita o potencial de transformação; incorporar o improvável amplia o espaço de possibilidades e abre caminho para mudanças estruturais.
Mesmo organizações reconhecidas pelo alto controle de qualidade, como a Apple, não conseguem garantir a experiência do usuário. Embora seus produtos sejam, em geral, mais consistentes e confiáveis, isso não explica por que pessoas se engajam intensamente com a marca -- como ao esperar em filas para lançamentos. Esse engajamento está mais relacionado à expectativa de uma experiência diferenciada do que às propriedades técnicas do produto.
Ainda assim, nem todos os usuários têm experiências positivas com esses produtos. Isso ocorre porque a experiência varia de pessoa para pessoa: cada usuário interpreta, utiliza e atribui significado de maneira distinta. O mesmo artefato pode gerar percepções divergentes, reforçando que a experiência não é uma propriedade fixa do produto. Há, portanto, uma distinção fundamental entre características objetivas -- como material, durabilidade ou funcionamento -- e qualidades da experiência, como facilidade de uso, atratividade ou prazer. Enquanto as primeiras podem ser controladas e verificadas, as segundas são relativas e emergem da interação entre usuário e sistema. Assim, mesmo com alto nível de controle sobre o produto, não é possível controlar plenamente a experiência. Ela permanece contingente, variável e dependente do contexto e do sujeito que a vivencia.
Brenda Laurel foi uma das primeiras pesquisadoras a formular o conceito de experiência do usuário no campo da interação humano-computador. Em seu livro Computer as Theater, propõe compreender o software como um espaço performático, no qual a interação se assemelha a uma encenação. Nesse modelo, a interface funciona como um palco onde diferentes agentes -- humanos e não humanos -- atuam sobre objetos, produzindo ações com efeitos no mundo.
Essa abordagem desloca o foco da interface enquanto objeto para a experiência enquanto processo. Em vez de projetar apenas elementos visuais ou funcionais, o objetivo passa a ser imaginar e estruturar as ações possíveis nesse "palco" interativo. A interação é vista como representação de ações humanas em um ambiente virtual, com consequências que podem extrapolar o sistema.
Um ponto central dessa proposta é a distinção entre interface e experiência. Enquanto a interface pode ser projetada diretamente, a experiência resulta da dinâmica entre múltiplos elementos e não pode ser totalmente determinada. Ainda assim, é possível projetar condições que favoreçam determinadas experiências, considerando o que seria ideal para o usuário -- e não apenas o mínimo aceitável. Esse entendimento também corrige uma atribuição comum: embora Don Norman tenha popularizado o termo "experiência do usuário" nos anos 1990, especialmente durante sua atuação na Apple, registros anteriores mostram que o conceito já havia sido articulado por Laurel. Sua contribuição vai além da terminologia, oferecendo um modelo conceitual que amplia significativamente a compreensão da interação como experiência.
A analogia entre software e teatro, proposta por Brenda Laurel, também revela um problema: ao considerar todas as possibilidades de ação em um "palco" interativo, a complexidade do sistema cresce rapidamente. Cada nova interação abre novas ramificações, ampliando exponencialmente o número de possibilidades que o software deveria suportar. Para lidar com isso, a autora sugere que o projeto de software se concentre no que é mais provável de acontecer, priorizando ações esperadas até chegar ao que é necessário. Esse raciocínio, embora útil para controlar a complexidade, tende a limitar o espaço de possibilidades, favorecendo previsibilidade em detrimento da abertura.
Em contraposição, propõe-se aqui uma inversão dessa lógica: em vez de restringir o projeto ao provável, é necessário também considerar o improvável, o implausível e até o aparentemente impossível. Isso se justifica porque os usuários frequentemente utilizam sistemas de maneiras não previstas, criando soluções improvisadas, adaptações e usos inesperados. Essa perspectiva crítica se expressa na rejeição de sistemas que impõem limites rígidos -- como quando um software informa que determinada ação é "impossível". Do ponto de vista do projeto possibilístico, o software não deveria restringir, mas expandir o campo de ação do usuário, abrindo espaço para exploração e invenção. Assim, em vez de fechar possibilidades para garantir controle, o design passa a operar como um dispositivo de abertura, permitindo que diferentes formas de uso emerjam, inclusive aquelas não antecipadas pelo projetista.
O modelo aqui proposto parte de uma distinção conceitual rigorosa: software, interação e experiência não são a mesma coisa. O software deve ser entendido como um material para a experiência -- um artefato com propriedades estruturais (funções, interface, regras), mas que por si só não contém a experiência. A interação é o processo que ocorre quando o usuário se engaja com esse material, e a experiência é o efeito emergente dessa relação, construído pelo sujeito a partir da ação.
Essa separação implica que as qualidades da experiência do usuário -- como prazer, frustração, engajamento ou sentido -- não são propriedades intrínsecas do sistema. Elas não podem ser diretamente implementadas, nem garantidas. O que pode ser projetado são condições materiais e interacionais que possibilitam a emergência dessas qualidades, mas nunca sua determinação. A avaliação dessas qualidades ocorre sempre a posteriori, como interpretação, seja pelo próprio usuário, seja por analistas ou designers.
A partir disso, o modelo introduz a distinção entre dois domínios: o espaço de controle e o espaço de possibilidades. O espaço de controle abrange aquilo que o projetista consegue definir com relativa precisão -- o software e certos aspectos da interação (fluxos, restrições, affordances). Ainda assim, esse controle é parcial: usuários podem contornar regras, reinterpretar funcionalidades ou produzir usos não previstos. Já o espaço de possibilidades corresponde ao campo da experiência -- aberto, contingente e indeterminado, onde múltiplos resultados podem emergir a partir da mesma configuração.
Diante dessa assimetria, a proposta desloca o foco do projeto: em vez de tentar controlar a experiência emergente (o que é epistemologicamente e pragmaticamente inviável), passa-se a trabalhar com a experiência projetada. Isso significa construir cenários, simulações e dispositivos que antecipem possíveis formas de vivência, sem pretender esgotá-las. O projeto deixa de ser prescritivo e passa a ser exploratório, operando por meio de hipóteses, encenações e variações.
Nesse enquadramento, o possível não é uma limitação do projeto, mas sua principal alavanca. Projetar torna-se um exercício de configuração de possibilidades, em que o designer atua como alguém que estrutura um campo de ação -- delimitando, expandindo ou tensionando o que pode acontecer -- em vez de definir resultados fixos. A incerteza, longe de ser eliminada, é incorporada como condição constitutiva do processo projetual e como fonte de criação.
Quando eu falo de experiências projetadas, eu não estou falando de produzir diretamente a experiência do usuário, porque isso a gente já viu que não dá para controlar. O que eu estou propondo são formas de acessar, simular ou reconstruir a experiência. São maneiras de trabalhar com algo que é, por natureza, imprevisível.
Um primeiro tipo é a experiência vicária. É quando eu tento me colocar no lugar de outra pessoa para entender como ela vive aquela situação. No design, isso significa assumir o papel do usuário e tentar reproduzir suas condições. Eu já fiz isso, por exemplo, quando fui projetar um site para uma ótica e eu não usava óculos. Eu peguei um óculos emprestado e fiquei usando por algumas horas. Claro que eu não enxergava direito, porque o grau não era o meu, mas justamente isso me fez perceber o quanto é desconfortável não conseguir ver bem. A partir disso, eu entendi melhor por que o site precisava ter textos maiores, mais legíveis. Então não é só imaginar o usuário, é tentar viver, ainda que parcialmente, a condição dele.
Outro tipo é a experiência observada. Aqui eu não tento me colocar no lugar do outro, eu observo o que ele faz na prática. Eu acompanho como as pessoas usam o sistema, em que contexto, com quais adaptações. Um exemplo foi um estudo que a gente fez com leitores de iPad. A gente foi até a casa das pessoas e observou como elas liam. E uma coisa que apareceu foi o uso simultâneo com a televisão, o que depois ficou conhecido como "second screen". Isso não tinha sido projetado, mas já estava acontecendo. Esse tipo de observação mostra que o uso real sempre escapa do que a gente planejou.
Tem também a experiência retrospectiva, que é quando eu peço para a pessoa reconstruir a experiência depois que ela aconteceu. Aqui eu não estou vendo a experiência em si, mas a memória dela, a interpretação. Em um teste com um refrigerador touchscreen, a gente pediu para as usuárias modelarem a experiência com massa de modelar e depois explicarem o que fizeram. Parece estranho, mas isso revelou aspectos emocionais muito fortes, que não apareceriam em um questionário tradicional. Então a experiência não é só o que acontece na hora, mas também como ela é lembrada e significada depois.
A experiência prospectiva é diferente, porque ela acontece antes da experiência existir. Eu peço para a pessoa imaginar como ela usaria algo que ainda não foi criado. Um caso clássico aconteceu no Xerox PARC, quando colocaram uma secretária na frente de um computador desligado e perguntaram como ela escreveria e editava um texto ali. A partir das respostas dela surgiram ideias como clicar, selecionar, apagar. Ou seja, várias coisas que hoje a gente considera básicas foram inventadas pelo próprio usuário nesse exercício. Então, nesse caso, a experiência não só antecipa o uso, ela ajuda a criar o próprio sistema.
Outro tipo que eu uso bastante é a experiência encenada, que vem muito dessa ideia do teatro. A gente cria uma situação artificial e atua aquela interação. Por exemplo, já fizemos simulações de atendimento telefônico em que alguns alunos faziam o papel do sistema e outros eram usuários. O sistema respondia em tempo real, como se fosse um menu automático. Isso permite testar a experiência antes de implementar qualquer coisa. É uma forma muito rápida de entender se a pessoa se perde, se entende, se consegue chegar onde quer.
Tem também a experiência co-criada, que é quando o usuário participa ativamente do projeto. Ele não é só alguém que testa ou avalia, ele ajuda a construir. Em um projeto com startups, por exemplo, os usuários desenhavam ideias em cima das nossas propostas, e a gente continuava a partir disso. O resultado não era de ninguém sozinho, era uma construção coletiva. Isso amplia muito o espaço de possibilidades, porque traz perspectivas que a gente não teria sozinho.
E, por fim, a experiência criticada, que é muito comum em ateliês de design. É quando alguém olha para a proposta e tenta imaginar como seria usar aquilo, levantando problemas, dúvidas, interpretações. Eu fazia muito isso com alunos, colocando o projeto na mesa e criticando como se eu fosse diferentes tipos de usuários. Às vezes a crítica nem era totalmente realista, mas ela ajudava a revelar qualidades que ainda não estavam claras na interface. Esse processo pode ser duro, mas ele é muito produtivo para entender a experiência antes dela acontecer.
O que todos esses tipos têm em comum é que eles trabalham com possibilidades, não com certezas. Eles são formas de explorar a experiência a partir de diferentes pontos de vista, envolvendo várias pessoas. E quando você envolve várias perspectivas, você expande o que pode acontecer. Então, em vez de tentar controlar a experiência, o que a gente faz é criar condições para que diferentes experiências possam emergir.
Então, quando eu começo a falar de qualidades da experiência do usuário dentro dessa perspectiva, eu preciso mudar um pouco a forma como a gente entende o próprio conceito de qualidade. Não dá mais para pensar qualidade como algo fixo, mensurável e garantido. As qualidades da experiência, tanto as projetadas quanto as emergentes, são sempre possibilidades, nunca certezas. Existem algumas qualidades que já fazem parte do vocabulário comum -- como usabilidade, utilidade, acessibilidade, atratividade, encontrabilidade -- e que ajudam muito porque nos dão palavras para discutir o projeto. Só que isso é apenas uma parte do problema. Existem muitas outras qualidades da experiência que ainda não têm nome, que a gente percebe, sente, mas não consegue descrever com precisão.
E aí entra uma dificuldade importante: se não existe vocabulário, fica mais difícil projetar. Porque projetar também é nomear, é conseguir dizer o que se quer alcançar. Por isso que, historicamente, o termo experiência do usuário surgiu como uma tentativa de ir além da usabilidade, de capturar algo mais amplo, mais complexo. Um trabalho que me influenciou bastante nesse sentido foi o do Jonas Löwgren, que estudou a estética da interação. Ele tentou justamente criar palavras para qualidades que não estavam sendo consideradas. Um exemplo é a ideia de maleabilidade, ou seja, o quanto o sistema responde de forma fluida às ações do usuário.
Eu gosto de dar um exemplo bem concreto disso: quando surgiram os primeiros smartphones com acelerômetro, muita gente ficava brincando com aplicativos que respondiam ao movimento -- como simular um copo de cerveja ou água. Aquilo não tinha muita utilidade prática, mas revelava uma qualidade importante da experiência: o sistema parecia "maleável", respondia ao corpo, ao gesto. Isso gerava um tipo de engajamento que não aparece quando a gente fala só de eficiência ou funcionalidade. Então, o ponto aqui é que o vocabulário que a gente tem hoje ainda é limitado para dar conta da riqueza da experiência. E, se a gente quer projetar experiências mais significativas, a gente também precisa expandir esse vocabulário, criando novas formas de descrever e reconhecer essas qualidades.
Antes mesmo dessas discussões mais recentes sobre experiência, já existia uma preocupação semelhante em outras áreas, especialmente na arquitetura. Um autor fundamental nesse sentido é o Christopher Alexander, que começou a questionar o fato de que a arquitetura tratava muito bem aspectos objetivos -- como dimensões, estrutura, conforto térmico -- mas não conseguia descrever adequadamente certas qualidades da experiência de estar em um espaço. Ele percebia isso na prática, quando precisava conversar com clientes sobre o que eles queriam para uma casa ou ambiente. Muitas vezes, as pessoas sabiam o que sentiam ou desejavam, mas não tinham palavras para expressar essas qualidades. Isso dificultava o próprio processo de projeto.
A solução que ele propôs foi o desenvolvimento dos chamados patterns, ou padrões. São estruturas recorrentes que aparecem em diferentes contextos e que ajudam a produzir certas qualidades de experiência. Ele organizou esses padrões em uma linguagem -- a chamada pattern language -- justamente para permitir que pessoas não especialistas pudessem participar do processo de projeto, expressando melhor o que desejam. Um exemplo é o "beer hall", aquele espaço coletivo onde as pessoas se reúnem para conversar, beber, compartilhar. Esse tipo de ambiente tem características específicas -- disposição das mesas, acústica, proximidade entre pessoas -- que favorecem uma certa qualidade de experiência, mais social, mais intensa. O pattern não descreve apenas a forma, mas a qualidade que emerge daquela configuração.
O interessante é que esse trabalho teve mais impacto na computação do que na própria arquitetura. Ele influenciou diretamente o desenvolvimento dos chamados design patterns na engenharia de software, especialmente a partir do trabalho do Gang of Four. No entanto, nessa transposição, grande parte da dimensão original -- ligada às qualidades da experiência -- acabou sendo deixada de lado, ficando mais o aspecto estrutural e reutilizável dos padrões.
Mais tarde, a área de interação humano-computador retomou essa ideia, desenvolvendo padrões de interface mais próximos da proposta original de Alexander. Esses padrões ajudam a pensar a interface como um meio concreto de possibilitar experiências, funcionando como um vocabulário inicial para quem está projetando.
Quando o Christopher Alexander fala de patterns, ele deixa claro que não se trata de criar uma qualidade isolada para cada padrão. O objetivo é justamente o contrário: combinar vários patterns para produzir uma qualidade única, mais ampla, que não pode ser reduzida a partes. Ele mesmo diz que essa qualidade é difícil de nomear, mas que, quando você está em um lugar que a possui, você sente -- é como se fosse o melhor lugar possível para estar.
Essa ideia foi retomada no design com o conceito de gestalt, que tenta dar conta dessa percepção do todo. Não é a soma das partes, mas uma qualidade emergente da relação entre elas. No contexto do software, isso aparece como uma gestalt da interação, ou seja, uma qualidade global que emerge da relação entre o usuário e o artefato interativo.
Nesse modelo, a gente pode até descrever propriedades objetivas do artefato -- tamanho, portabilidade, estrutura -- e também características da interação -- se ela é rápida, precisa, direta, conectada. Mas nenhuma dessas coisas isoladamente explica a experiência. O que importa é como tudo isso se articula em um todo coerente.
Por exemplo, em uma aplicação móvel de pagamento, o que o usuário faz é algo simples, como transferir dinheiro. Mas a experiência que ele tem envolve uma série de qualidades ao mesmo tempo: rapidez, fluidez, sensação de controle, clareza. Essas qualidades formam uma gestalt, uma percepção integrada que não pode ser decomposta sem perda de sentido. Isso reforça a ideia de que projetar experiência não é apenas ajustar atributos isolados, mas pensar na configuração do todo. É nesse nível que a experiência realmente acontece, e é por isso que abordagens fragmentadas -- focadas apenas em métricas ou funcionalidades -- tendem a falhar em capturar o que realmente importa.
Quando eu começo a pensar a experiência do usuário a partir dessa ideia de totalidade, fica claro que ela não se restringe ao software. A experiência acontece ao longo de vários pontos de contato, em diferentes momentos e mídias. O software é apenas um desses pontos dentro de um ecossistema mais amplo.
Um usuário pode, por exemplo, começar uma interação em um site, depois continuar em um aplicativo móvel, em seguida ir até uma loja física, conversar com um atendente, receber um material impresso ou ver uma campanha publicitária. A experiência se constrói nessa transição entre diferentes contextos, e não em um único sistema isolado.
Por isso, empresas que levam a experiência do usuário a sério tentam tornar essas transições mais fluidas. Um exemplo recorrente é o da Apple, que investe em integrar seus dispositivos e serviços para que uma atividade possa começar em um lugar e continuar em outro. Embora tecnicamente isso nem sempre funcione perfeitamente, a intenção é criar uma continuidade na experiência.
Mas essa integração não é apenas técnica, ela também pode ser humana. Um bom atendimento, por exemplo, pode reconhecer o histórico do usuário e dar continuidade a uma interação iniciada em outro canal. Isso evita que a pessoa precise repetir informações e reduz a fricção ao longo da jornada. O problema é que muitas organizações ainda pensam de forma fragmentada, com cada área cuidando apenas da sua parte. Isso gera experiências desconectadas, em que o usuário precisa "costurar" sozinho os diferentes pontos de contato. Nesse contexto, o papel de quem trabalha com experiência do usuário é justamente tentar enxergar esse todo. Não se trata apenas de projetar interfaces, mas de entender e articular os diferentes momentos da experiência. E isso exige uma visão mais ampla, que ultrapassa os limites de um único sistema ou disciplina.
Quando a gente fala desse papel mais amplo de quem trabalha com experiência do usuário, muitas vezes aparece uma visão meio romantizada, quase como se fosse um "herói" que entende tudo e resolve todos os problemas. Existe até essa ideia do UX hero, alguém que teria uma visão total da experiência e salvaria o usuário de sistemas mal projetados. Eu, particularmente, não concordo muito com essa visão. Eu vejo de outra forma. Todas as pessoas têm experiências, e muitas vezes pessoas que não são especialistas em UX têm repertórios muito mais ricos em determinados contextos do que alguém da área. Então não faz sentido centralizar essa capacidade em um único profissional. O que faz mais sentido é reconhecer que a experiência é distribuída e que o projeto precisa ser construído de forma colaborativa.
Para isso, colaboração não é opcional, é necessária. Só que, na prática, cada pessoa dentro de uma organização costuma olhar apenas para a sua especialidade, para o seu departamento, para a sua responsabilidade específica. Isso dificulta a construção de uma visão integrada da experiência. Além disso, a fala, por si só, tem limitações. Só conversar sobre a experiência muitas vezes não é suficiente para visualizar o todo. Por isso, ao longo do tempo, o design desenvolveu outras formas de representação além da linguagem verbal, enquanto na engenharia de software ainda existe uma forte dependência de documentos textuais, como a especificação de requisitos.
Documentos de especificação podem até ter utilidade formal, por exemplo, em contextos contratuais, mas raramente ajuda a construir uma visão integrada da experiência. Ele descreve partes, funcionalidades, condições, mas não consegue capturar o todo. Por isso, se a gente quer realmente trabalhar com experiência do usuário, a gente precisa de outras ferramentas, que permitam expandir essa visão. Ferramentas que não apenas descrevam, mas que ajudem a visualizar, materializar e compartilhar aquilo que ainda não está totalmente definido.
Então, para lidar com essa limitação da linguagem verbal e desses documentos mais tradicionais, eu comecei a buscar outras ferramentas que ajudem a expandir a visão do projeto. Eu chamo essas ferramentas de expansivas, porque elas permitem sair das partes e começar a visualizar o todo da experiência. Uma das mais simples e eficazes é o mood board, ou painel semântico. Em vez de começar pelo software, eu começo pela experiência que eu quero possibilitar. Só que não fico apenas pensando, eu materializo isso. Eu junto imagens, referências visuais, elementos que evocam sensações, ideias, atmosferas. Cada imagem carrega um significado, e quando você coloca várias juntas, começa a aparecer algo que não está em nenhuma delas isoladamente, mas no conjunto. Esse processo é propositalmente aberto e até um pouco caótico no início, porque a ideia não é definir, mas explorar possibilidades. O que interessa não é copiar uma imagem específica, mas capturar aquilo que emerge entre elas, essa qualidade mais difícil de nomear.
Existe também uma variação mais objetiva disso, que é trabalhar com palavras-chave. Em vez de imagens, as pessoas escrevem termos que associam à experiência que querem criar. Isso funciona muito bem em grupo, porque todo mundo consegue contribuir, mesmo sem ter repertório visual. E, ao reunir essas palavras, começa a se formar um campo semântico que orienta o projeto. O ponto principal dessas ferramentas é que elas ajudam a tornar visível algo que ainda não está definido. Elas não descrevem exatamente o que será feito, mas criam uma base compartilhada para pensar a experiência de forma mais ampla, antes de entrar nas decisões mais concretas de implementação.
Quando eu uso painéis semânticos ou palavras-chave, eu não estou definindo soluções, mas criando um campo de referência compartilhado. Esse campo orienta decisões futuras, mesmo que de forma indireta. Ele funciona quase como um norte, algo que ajuda a avaliar se uma decisão está coerente com a experiência que se quer construir.
Ao mesmo tempo, essas ferramentas ajudam a lidar com aquilo que ainda não tem nome. Muitas qualidades da experiência são difíceis de descrever diretamente, mas podem ser evocadas por imagens, metáforas ou associações. Isso amplia a capacidade do grupo de discutir aspectos mais sutis, que não apareceriam em uma especificação tradicional.
O mais importante aqui é que o projeto deixa de começar pela definição de funcionalidades e passa a começar pela construção de sentido. Antes de decidir o que o sistema faz, a gente tenta entender que tipo de experiência ele deve possibilitar. E isso muda completamente a lógica do processo de design, porque coloca a experiência -- ainda que indefinida -- como ponto de partida, e não como consequência.
À medida que o projeto avança, eu passo a usar esboços e protótipos para materializar ideias, ainda de forma aberta. Não são soluções finais, mas meios de explorar possibilidades e provocar discussão. Esses artefatos ajudam a tornar o projeto visível e coletivo, permitindo que outras pessoas critiquem e modifiquem. Assim, os protótipos deixam de ser apenas validação e passam a ser ferramentas de exploração contínua da experiência.
Então, uma ferramenta que eu tenho usado bastante com os estudantes aqui na PUC é o teatro projetual . A ideia é construir a situação do usuário por meio de encenação em vídeo, sem roteiro fechado. Em um dos exemplos, os estudantes trabalharam com um idoso com demência e imaginaram um dispositivo, como um óculos, que ajudaria a reconhecer pessoas, lembrar nomes e orientar ações. Durante a encenação, foram surgindo situações, como ele em uma festa sendo alertado sobre alimentos ou sendo guiado até a padaria. O ponto principal é que essas ideias não estavam prontas antes. Elas emergiram durante a atuação. O teatro, nesse caso, não representa a solução -- ele ajuda a criá-la, explorando possibilidades por meio da improvisação.
A partir disso, eu relaciono essa prática com o design baseado em cenários, que é uma abordagem mais antiga, em que você imagina as interações do usuário e normalmente escreve essas situações como parte da especificação . O problema é que isso depende muito da capacidade de escrever, e nem todo mundo consegue se expressar bem dessa forma. Por isso, eu proponho uma adaptação que eu chamo de cenário lúdico. Em vez de escrever, as pessoas contam a história encenando ou usando elementos simples, como se estivessem brincando, enquanto gravam um vídeo improvisado no smartphone. Isso resgata uma habilidade comum -- todo mundo já contou histórias com bonecos -- e facilita imaginar interações.
Um exemplo foi o conceito de um aplicativo de "Art Backup", em que uma pessoa fotografa obras em um museu e, depois de um desastre, essas imagens servem como backup. A história é meio absurda, mas ajuda a explicar a lógica do sistema. O importante não é a precisão, mas a capacidade de tornar a ideia compreensível por meio de uma narrativa.
Além desse tipo de cenário lúdico, eu também trabalho com diferentes formatos de vídeos improvisados, que a gente vem pesquisando e sistematizando . Um exemplo é o chamado "Mágico de Oz", em que uma pessoa faz o papel do sistema enquanto outra interage como usuário. Nesse caso, as interfaces podem ser simuladas com papel ou outros materiais simples, e o "sistema" responde em tempo real, como se fosse um software funcionando. Isso permite experimentar a interação antes de qualquer implementação, explorando como ela se desenrola na prática. O ponto central desses vídeos improvisados é que eles permitem testar e desenvolver ideias de interação de forma rápida e aberta, sem depender de protótipos técnicos. A interação é construída na hora, o que amplia as possibilidades e revela aspectos que dificilmente apareceriam em descrições formais.
O que começa a acontecer depois que a gente trabalha com esses diferentes formatos de criação é que surge uma complexidade muito grande. As ideias se multiplicam, as possibilidades aumentam, e as equipes começam a sentir necessidade de organizar isso tudo. Naturalmente, aparece um movimento de "colocar ordem na casa", em que as pessoas passam a estruturar uma visão mais completa da interação e da experiência. Isso geralmente acontece por meio de diagramas, que ajudam a reunir e organizar o que foi explorado anteriormente. Em ambientes como a Apple Developer Academy, por exemplo, isso aparece no uso intensivo de paredes para desenhar, discutir e consolidar ideias coletivamente. O objetivo passa a ser chegar a um consenso sobre a estrutura mínima do sistema, organizando as interações e definindo como as partes se conectam. Aos poucos, aquilo que era aberto e exploratório vai sendo sedimentado em uma forma mais estável.
Nesse momento, as equipes começam a usar diagramas e representações visuais para estruturar melhor o que foi explorado . Em ambientes como a Apple Developer Academy, por exemplo, isso aparece no uso intensivo de paredes para desenhar, discutir e consolidar ideias coletivamente. O objetivo passa a ser chegar a um consenso sobre a estrutura mínima do sistema, organizando as interações e definindo como as partes se conectam. Aos poucos, aquilo que era aberto e exploratório vai sendo sedimentado em uma forma mais estável. Esse movimento faz parte do processo: o projeto começa caótico, cheio de possibilidades, e vai sendo progressivamente organizado até se tornar algo mais definido.
Uma forma bastante comum -- e mais radical -- de organizar isso é linearizar a experiência, transformando-a em uma sequência passo a passo . Isso aparece em ferramentas como Service Blueprint, User Journey ou diagramas em swimlane, em que se organiza a experiência ao longo de uma linha do tempo. Nesses modelos, você descreve as ações do usuário, os pontos de contato (software, atendimento, produto físico) e também as ações do sistema ou da organização. Isso ajuda a visualizar uma experiência completa, principalmente a chamada experiência ideal. O problema é que essa representação é limitada. Ela não captura bem desvios, retornos ou abandonos, que são comuns no uso real. Ou seja, funciona para planejar um fluxo esperado, mas não dá conta da complexidade da experiência emergente.
Pensando nessas limitações, a gente começou aqui na PUC a experimentar outras formas de representar a experiência, e uma delas foi o uso de Lego como linguagem de projeto . Isso aconteceu, por exemplo, no desenvolvimento da plataforma Copel+, quando os esboços de tela não estavam sendo suficientes para entender o que estava acontecendo.
A gente então trouxe o Lego para a discussão e começou a desenvolver um método que combina elementos de modelagem mais formal -- como diagramas de casos de uso -- com representações mais próximas da experiência. Esse método foi chamado de Lego ML, ou Lego Modeling Language.
Durante as sessões, diferentes pessoas -- arquitetos, designers, programadores e clientes -- participavam juntas, e a discussão sobre a arquitetura do software era constantemente atravessada por questões sobre o impacto na experiência do usuário. Ou seja, o Lego funcionava como uma forma de integrar essas dimensões que normalmente ficam separadas.
Mais importante do que usar uma dessas técnicas é colocar todos os documentos no espaço de trabalho de forma bem visível. Em práticas como design sprint, isso cria uma espécie de memória externa do projeto. Em vez de depender da lembrança individual ou de arquivos digitais dispersos, a equipe consegue literalmente olhar ao redor e reencontrar o que já foi pensado. Isso é especialmente importante porque a experiência do usuário é algo abstrato, difícil de manter na cabeça de forma contínua. O espaço físico ajuda a sustentar essa continuidade.
Além disso, esse ambiente permite revisitar decisões e reconstruir raciocínios. Quando surge uma dúvida ou conflito, não é necessário recomeçar do zero -- é possível apontar para algo que já foi produzido, relembrar o contexto e ajustar a partir dali. Isso reduz ruídos de comunicação e evita que diferentes pessoas avancem com interpretações divergentes. Outro aspecto importante é que esse espaço possibilita uma espécie de reencenação das experiências projetadas. Ao interagir com esses materiais -- olhando, apontando, reorganizando -- a equipe revive partes do processo e consegue reinterpretar o que foi feito. Isso aproxima o trabalho da ideia de um ateliê, em que o conhecimento não está apenas em documentos, mas distribuído no ambiente e nas interações entre as pessoas.
Nesse sentido, o espaço físico funciona como um meio de alinhar perspectivas. Em vez de cada pessoa operar com um entendimento parcial ou isolado, o grupo passa a compartilhar um mesmo campo de referência. Isso facilita a construção de consenso e torna o processo mais coerente, especialmente em projetos complexos, onde a experiência não pode ser reduzida a uma única representação.
Então, como fechamento conceitual, eu apresento essa ideia de design expansivo, que é algo que eu desenvolvo melhor na minha tese de doutorado . A lógica é simples: em vez de fechar rapidamente o projeto, você começa expandindo, colocando mais possibilidades, mais perspectivas, mais qualidades da experiência. Nesse momento, vale tudo -- trazer mais pessoas, mais ideias, mais interpretações. Isso naturalmente gera um certo caos, e chega uma hora em que não dá mais para continuar expandindo. As pessoas se cansam, começam a reclamar, e o próprio processo leva a uma redução.
Então, como fechamento conceitual, eu apresento essa ideia de design expansivo, que é algo que eu desenvolvo melhor na minha tese de doutorado . A lógica é simples: em vez de fechar rapidamente o projeto, você começa expandindo, colocando mais possibilidades, mais perspectivas, mais qualidades da experiência. Nesse momento, vale tudo -- trazer mais pessoas, mais ideias, mais interpretações. Isso naturalmente gera um certo caos, e chega uma hora em que não dá mais para continuar expandindo. As pessoas se cansam, começam a reclamar, e o próprio processo leva a uma redução.
É aí que entra o design redutivo, que é o movimento oposto: organizar, selecionar, estruturar. Eu não coloco um como melhor que o outro. Os dois são necessários. O problema é que muitas vezes as organizações pulam direto para o redutivo, sem passar por essa fase de expansão. Com isso, acabam trabalhando apenas com o que é mais óbvio ou mais imediato, sem explorar de fato o espaço de possibilidades da experiência do usuário.
Para fechar, eu apresento alguns métodos para avaliar qualidades da experiência do usuário, destacando que ainda há uma carência de métodos adequados para isso . O mais conhecido é o teste de usabilidade, mas muitas vezes ele não responde à pergunta que realmente importa, que é se as pessoas gostaram da experiência.
A partir desses métodos, eu enfatizo uma distinção importante: qualidades da experiência do usuário são melhor trabalhadas com abordagens qualitativas . Isso porque qualidade envolve nuances, interpretações e significados que dificilmente podem ser reduzidos a números sem perda. Métodos quantitativos são úteis e necessários, mas operam por redução, transformando a experiência em métricas escaláveis. Nesse processo, parte da riqueza da experiência se perde. Por isso, eles são mais adequados para lidar com quantidade, não com qualidade. Então, a ideia não é descartar o quantitativo, mas reconhecer que ele cumpre outro papel. Antes de medir, é preciso criar e compreender qualitativamente. Caso contrário, corre-se o risco de medir algo empobrecido, que já não representa a complexidade da experiência original.
Para conectar isso com uma perspectiva mais ampla, eu apresento um modelo de evolução tecnológica . Quando surge uma nova tecnologia, ela cria um novo mercado e inicia uma fase de competição baseada em quantidade -- mais funcionalidades, mais desempenho, menor custo. Com o tempo, esse modelo se satura. As diferenças deixam de ser relevantes, e fica difícil se destacar apenas por métricas quantitativas. É nesse momento que surge uma inovação qualitativa, em que um produto não é apenas "mais", mas "melhor" em termos de experiência.
Essa mudança cria um novo mercado, agora orientado pela qualidade. Foi o que aconteceu, por exemplo, com os smartphones touchscreen, que reposicionaram a competição em torno da experiência do usuário. Mas esse novo ciclo também tende à saturação, o que abre espaço para uma próxima ruptura. Assim, a evolução tecnológica alterna entre fases quantitativas e qualitativas, e a experiência do usuário se torna central justamente nesses momentos de inovação qualitativa.
Diante disso, surge a questão de como lidar, na prática, com esse movimento entre expandir e reduzir, entre possibilidades e decisões . Isso não pode ser totalmente sistematizado; exige o que se pode chamar de um tipo de talento artístico dentro das disciplinas de projeto, como design, arquitetura e artes. Uma referência importante aqui é Donald Schön, que discute a formação do profissional reflexivo. Essa perspectiva está sendo aplicada, por exemplo, em estudos sobre a Apple Developer Academy, observando como os estudantes aprendem a desenvolver software de maneira semelhante ao que acontece em ateliês de design.
Nesses contextos, o aprendizado não se baseia apenas em teoria ou procedimentos, mas em prática contínua, reflexão e experimentação. O ateliê de projeto funciona como um ambiente onde se aprende fazendo, explorando e ajustando. A proposta, então, é aproximar o ensino e a prática de desenvolvimento de software dessas abordagens, tratando o desenvolvimento não apenas como uma atividade técnica, mas como um processo criativo, reflexivo e, em certa medida, artístico.
Como fechamento, eu proponho que a modelagem de software precisa dialogar mais com áreas como design e arte . Os desafios envolvidos hoje não são apenas técnicos, mas sociais, porque o software está profundamente integrado à vida cotidiana. Pensar o software de forma isolada, apenas dentro da lógica da engenharia, limita a capacidade de lidar com essa complexidade. É nas relações com outras áreas que surgem as possibilidades de enriquecer o projeto e produzir experiências mais significativas. Nesse sentido, o desenvolvimento de software deixa de ser apenas uma questão técnica e passa a ser uma prática interdisciplinar, que envolve compreender e atuar sobre a sociedade.
