Projeto possibilístico para as qualidades da experiência do usuário.
 Essa palavra é nova no vocabulário.
 Isso aqui é uma proposta experimental de um conceito que futuramente,
 academicamente, eu vou tentar sustentar.
 A prática e as técnicas que eu vou mostrar aqui já estão bem fundamentadas.
 Eu vou, durante essa apresentação, passar um monte de referências.
 Depois que vocês não encontrarem "googando" essas referências,
 vocês me mandem uma mensagem que eu passo ela completa para vocês.
 Então, é uma apresentação acadêmica, mas com exercícios bastante práticos.
 Bom, eu comecei a pensar nesse termo possibilístico
 quando eu comecei a olhar o que existia em qualidade de software
 por intermédio do grupo de gerencia de software do PPG.
 Eu comecei a entrar mais a fundo, já conheci a área,
 mas comecei a conhecer mais, inclusive por interação com a Karina,
 que foi muito a fundo, e levantar todas as ISO que mencionavam
 qualidades relativas à usabilidade.
 Depois, mais para frente, ela começou a falar de experiência do usuário.
 E aí, bateu, caiu a ficha para mim, puxa vida.
 Se você compara as ISOs, as normas técnicas que definem,
 ou os modelos teóricos para análise da qualidade de software,
 você vê um crescimento de um interesse cada vez maior
 nas qualidades relativas à experiência do usuário.
 Aqui tem um levantamento quantitativo, isso foi a minha observação,
 depois eu fui procurar evidências, se isso realmente tinha acontecido,
 então eu já tinha um estudo de 2000, do GoJF e colegas,
 que mostra que a quantidade de termos relativos à usabilidade
 dentro dos modelos de qualidade de software aumentou
 desde 1977 até 2010.
 Olá, Ambrosio Alberto.
 Você vai participar do curso?
 Será que...
 Voltando, então.
 Então, a gente vê aqui, na última ISO de 2010,
 que o GoJF identifica como sendo uma ISO que valoriza muito a usabilidade,
 então tem vários atributos relativos à usabilidade,
 porém, ainda não aparece nessas modelos de qualidade de software
 o termo experiência do usuário.
 Porém, no mercado, esse termo é ubíquito.
 E por mais que algumas pessoas, inclusive eu,
 tenham resistido à utilização desse termo ao longo dos anos,
 ele hoje se tornou padrão de indústria.
 Então, se você quer buscar um emprego,
 você quer encontrar um profissional especialista nessa área,
 você vai ter que usar o termo UX designer,
 ou UX alguma coisa, experiência do usuário.
 E eu acho um termo ruim, e por isso eu vim com essa camiseta,
 agora eu vou explicar, né?
 Exu.
 Desde que os brasileiros começaram a falar que eles trabalham com experiência do usuário,
 aí daqui a pouco eles falam "porque eu faço UX".
 Como assim?
 Como é que você abrevia experiência do usuário como UX?
 Se é um termo que você traduziu para o português,
 você tem que abreviar em português.
 Você abreviar experiência do usuário em português vira Exu.
 E por que Exu?
 Não só por isso, por ser logicamente uma abreviação correta da palavra,
 mas também porque ele é uma entidade da nossa cosmologia brasileira,
 que vem de uma origem brasileira, claro, tem influências africanas,
 mas é uma entidade brasileira, tipicamente, muito mal compreendida do nosso país.
 Tal como o profissional de experiência do usuário.
 Algumas pessoas dizem que ele é como o diabo, outras pessoas dizem que ele é como Deus, né?
 Então, Exu é um nome também apropriado para esse profissional que é meio indefinido, né?
 Você não sabe se ele é um designer, se ele é um programador, se ele é um arquiteto, o que ele é.
 Então, eu tenho feito essa brincadeira para provocar os profissionais e os pesquisadores
 a pensarem mais profundamente sobre esse assunto.
 A computação, ela nega mais ou menos esse termo, ela não utiliza.
 No design, na academia já se utiliza o termo experiência do usuário.
 Na computação já se fala muito de usabilidade.
 Porém, usabilidade, desde aí de 2004, o mercado já está falando que não é suficiente.
 Que usabilidade é só uma das qualidades da experiência do usuário.
 Existem outras.
 Esse modelo aqui é bastante conhecido, do User Experience Running Combo, do Peter Morville.
 Que ele sugere encontrabilidade, credibilidade, acessibilidade, desejabilidade, utilidade e valioso, né?
 O valor, que seria a principal das qualidades.
 Existem dezenas de outros modelos como esse, utilizados no mercado.
 E alguns, até alguns acadêmicos também se utilizam desses modelos.
 Porém, uma das grandes dificuldades desses modelos feitos com base na intuição,
 nas heurísticas dos pesquisadores ou dos praticantes que criaram,
 é que eles não permitem uma mensuração muito clara dessas variáveis.
 Se você colocar essas qualidades como variáveis num possível experimento.
 Então, não se faz esse tipo de atividade de avaliação com base nesses modelos no mercado.
 Recentemente, começaram a se desenvolver os primeiros modelos que podem ser mensuráveis.
 Também uma dica da Karina, né?
 Eu fui pesquisar um pouco mais sobre o MeoQ, né?
 Que é uma ferramenta baseada em questionário, que já consegue mensurar todas essas variáveis aqui.
 Tá? Uma variedade bem maior do que tinha no modelo ali do ISO Experience Run and Combi.
 E mais abrangente também do que hoje tem na ISO e nas outras normas técnicas.
 Então, tem utilidade e usabilidade, que já está contemplado nas normas.
 Já é meio que, já existem dezenas de ferramentas bem validadas para avaliar essas qualidades.
 Mas, para avaliar a estética visual, status, né?
 O status social e o comprometimento que a pessoa tem com aquela atividade, com aquela experiência.
 Isso aqui é novidade, são atributos novos.
 Ou emoções positivas, emoções negativas, também novidades para as normas técnicas.
 Ou até mesmo qualidades que só se revelam depois de muito tempo que você vai interagir com um determinado aplicativo.
 Por exemplo, a lealdade ou a intenção de usar de novo ou de recomendar para uma outra pessoa.
 Então, esse modelo aqui já tem muito mais elementos novos.
 Então, já demonstra, de novo, o que eu estava falando.
 Uma expansão do interesse e uma diversificação de qualidades da experiência do usuário.
 E eu recomendo altamente para quem tiver interesse em mensurar essas qualidades da experiência do usuário.
 Utilizar essa ferramenta, até porque ela é open source.
 Você pode baixar ela no meq.ti, você tem acesso também às pesquisas que já foram feitas validando esse modelo.
 Recomendo, a Karina vai utilizar também, né? Na pesquisa dela.
 E depois vai trazer esses dados.
 Olá, Erica, seja bem-vinda. Olá, Matheus. Sejam bem-vindos.
 A gente começou agora há pouquinho, tá?
 Esse modelo que eu passei, o MeQ, é pouco conhecido na indústria.
 Ele é um modelo mais acadêmico.
 Eu acho que ele é aplicável na indústria também.
 Só cabe a gente a divulgar, né?
 Mas o modelo que é mais conhecido na indústria é o HEART.
 É um framework que pesquisadores da Google, UX researchers, né?
 Que são pesquisadores aplicados dentro da Google.
 Não é bem um pesquisador, assim, acadêmico.
 Não precisa ter um doutorado para ser um UX researcher.
 É um termo, assim, eu acho pomposo demais para o tipo de trabalho.
 Mas é o que se usa também na indústria.
 Seria equivalente aos pesquisadores do marketing, né?
 Que faz pesquisa de marketing.
 É um UX researcher, só que com outro foco.
 Esses pesquisadores lá da Google montaram esse framework HEART,
 que tem cinco palavras-chave.
 Happiness, Engagement, Adoption, Retention, Task, Success.
 E eles propõem que você utilize essas palavras-chave como heurísticas
 para você encontrar quais seriam as métricas mais adequadas
 para o seu caso específico, do seu aplicativo, no seu contexto.
 Então, um pouquinho diferente do modelo que eu mostrei anteriormente,
 do MEIQ, aqui você tem um framework adaptável
 para montar a sua abordagem de mensuração.
 No MEIQ é tudo pré-definido.
 Ou você aplica aquelas variáveis que estão ali, ou você não aplica.
 Aqui você escolhe e utiliza um método de definição
 de objetivos da mensuração, os sinais que você já tem.
 E aí, por fim, você define as métricas.
 Eu não vou entrar muito em detalhe nesse framework,
 mas eu vou voltar para a academia para mostrar uma evidência interessante
 de que por mais que existam alguns modelos e existam um interesse
 por discutir qualidades da experiência do usuário,
 a maior parte dos especialistas da prática, dos praticantes,
 não acreditam que seja possível mensurar todos os aspectos da experiência do usuário.
 Então, Loh e colegas fizeram uma pesquisa em 2014
 e perguntaram para os profissionais de UX, os Exus, os especialistas Exus,
 que características, que qualidades da experiência do usuário
 você acha que podem ser mensuráveis e que qualidades são imensuráveis
 ou não são mensuráveis.
 E aí apareceu que é fácil de você mensurar a eficiência,
 10 pessoas mencionaram a eficiência,
 mas algumas pessoas mencionaram que,
 uma pessoa disse que, melhor dizendo,
 3 pessoas falaram que não é possível mensurar a usabilidade.
 2 pessoas falaram que era possível, por isso fica aqui no meio.
 É um pouquinho difícil de ler esse mapa aqui,
 mas o que ele significa?
 Se está aqui é porque os profissionais acreditam que é possível mensurar aqui.
 Não é possível aqui, alguns acham que sim, outros acham que não.
 Então, aqui aparecem características interessantes que não podem ser mensuradas,
 mas que os profissionais de experiência do usuário dizem que conseguem melhorar,
 que conseguem impactar, que conseguem, enfim, valorizam,
 se gabam de poderem atingir esses efeitos.
 Por exemplo, encantamento, ajudar as pessoas a se autorealizarem,
 se identificarem com alguma coisa, ou mesmo amar alguma coisa.
 Tem muitos profissionais de experiência de usuário que fazem,
 dizem "não, eu vou fazer os nossos usuários amarem o nosso software".
 Mas se você não consegue mensurar amor, como é que você mensura?
 E "heart", o nome "heart" também do Google tem uma,
 por trás a escolha dessas palavras tem a ver com isso.
 É uma tentativa de vender a experiência do usuário como algo que consegue trabalhar
 com coisas que são imensuráveis, impomensuráveis.
 Enfim, agora vem a parte que a gente começa a distanciar-se um pouco do discurso
 e da abordagem da engenharia de software,
 que fala muito sobre mensurar qualidades da experiência do usuário.
 Mas mensurar, gente, é a parte importante para você obter reconhecimento para a área,
 para você ter "accountability", para você, muitas vezes, se justificar dentro de uma organização.
 Mas uma vez que você conquista esse espaço, o que você faz com ele?
 Ok, a métrica de experiência do usuário começa a ser valorizada pela organização.
 E agora, o que você faz além de mensurar?
 [inaudível]
 Exatamente, mas para você ter uma decisão, primeiro você tem que ter alguma coisa para decidir.
 E aí você tem que criar essa coisa para decidir.
 Então o desafio maior, é claro, a primeira fase é mensurar,
 porque com a mensuração a organização vai ver,
 quem está lá em cima, que não está vendo os detalhes da operação,
 vai conseguir ver o que é a experiência do usuário.
 Porém, quando você adquire o espaço, adquire equipe, adquire projeto,
 tempo ou lugar dentro de um processo, você precisa saber como criar essas qualidades da experiência do usuário.
 E isso aqui que é um assunto muito pouco discutido na engenharia de software,
 e mesmo na interação mano-computador, que é a área dentro da computação que trabalha mais com esses assuntos.
 Esse assunto é um assunto muito discutido, mais discutido, eu diria, na área do design e também na área da arte.
 Por isso que eu vou trazer essas referências nessa apresentação.
 Visando com isso, é estabelecer um diálogo maior entre essas áreas.
 Aqui tem uma historinha do Gilbert, que é muito engraçada,
 que ele fala assim para o chefe dele, olha, nós, desculpa, o cliente dele,
 os seus requisitos de usuário, eles têm mais de 400 funcionalidades.
 Aí ele fala, você não acha que isso vai ter uma complexidade muito grande para o usuário?
 400 funcionalidades não é demais? Ah, bom ponto.
 Então é melhor adicionar na lista de requisitos, tem que ser fácil de usar.
 Por que que é engraçado? De onde vem o humor dessa piada?
 Porque essa facilidade de uso, ela não é mais uma funcionalidade.
 Ela é um efeito que vem da junção de várias funcionalidades.
 E é um algo a mais, digamos assim, que você não consegue controlar diretamente.
 Então essas métricas que a gente falou anteriormente, elas começam a falar de emoções, sensações,
 características subjetivas da experiência, que você, não é um atributo do software.
 É um atributo de uma relação entre o software e o usuário.
 Sendo assim, você não consegue controlar essas qualidades completamente,
 muito menos especificar elas com definição e garantir que você vai atingir aqueles requisitos.
 Que é a função de uma lista como essa.
 Então adicionar qualidades da experiência do usuário na lista de requisitos,
 não garante que o software tenha tais qualidades.
 Pois elas dependem também do que o usuário faz com o software.
 Então a abordagem que eu tenho para trabalhar com vocês é para essa situação de incerteza,
 onde você não sabe o que o usuário vai fazer,
 porque você assume que é incontrolável a experiência do usuário e imprevisível.
 Quem pode me explicar por que esses dois jogadores de videogame colocaram esse papelão no meio da tela?
 Quem que sabe explicar por quê?
 Eu já fiz isso.
 Você já fez isso?
 Então explica, vai.
 Eu não sei qual jogo é esse, mas era muito comum antigamente ter jogos multiplayer local,
 duas pessoas jogando no mesmo mapa e elas tinham que se matar no mesmo jogo.
 Então você não viu o que o outro jogador estava fazendo,
 você dividia a tela e impedia o outro jogador de ver.
 Então a única forma de fazer isso era com esse papelão no meio da tela,
 porque o jogador de baixo viu só a tela dele e o de cima viu só a tela dele também.
 Então aqui está uma gambiarra,
 que os desenvolvedores de jogos não imaginaram que fosse possível você ter esse acesso exclusivo.
 Hoje em dia, com as LAN houses ou mesmo com o próprio multiplayer online,
 as pessoas conseguem jogar sem ver a tela do outro.
 Mas nessa época antigamente era a única maneira de você separar.
 E aqui você tem um ato criativo, você tem uma adaptação
 e você tem uma intervenção do próprio usuário que afeta a experiência de uso.
 Jogar desse jeito é muito mais...
 O que você diria?
 Qual a diferença do impacto de jogar dessa maneira?
 - É surpreendente, né? - Exatamente.
 - É um fator surpresa. - Fator surpresa.
 Você não sabe de onde está vindo o outro jogador.
 Então você tem uma ação do usuário impactando na qualidade da experiência dele.
 Se não fosse legal, melhor jogar assim,
 eu tenho certeza que esses dois jovens não iam pagar esse nico de ficar com essa caixa de papelão na cabeça.
 Pode ter certeza.
 Agora, quem tentou no passado controlar experiências humanas, falhou.
 E ainda foi considerado antiético.
 Aqui tem um caso extremo que é o Project MK Ultra.
 É um projeto escondido que a CIA desenvolveu entre os anos 50 e 70 nos Estados Unidos,
 que tentou controlar as experiências das pessoas
 para ver se era possível você ter controle sobre a mente das pessoas.
 Isso foi recentemente, esses arquivos vieram a público.
 É uma situação bizarra em que eles colocavam pessoas que, sem autorização, sem consentimento,
 colocavam essas pessoas em situações de deprivação dos sentidos,
 e enviavam para elas drogas psicotrópicas, como LSD e outras,
 para ver se conseguiam, utilizando isso de maneira controlada e metódica,
 fazer uma pessoa executar exatamente o que eles pediam para elas executarem,
 sem perguntar, sem questionar,
 ou para ver se essa pessoa revelava uma informação através de uma espécie de tortura psicológica, e por aí vai.
 Então, hoje em dia, dentro da psicologia, dentro das ciências que lidam com, estudam as experiências humanas,
 tentar controlar a experiência de alguém é considerado uma atividade antiética,
 se não ilegal em alguns países.
 [Inaudível]
 Não sei do que você está falando.
 [Inaudível]
 Como não conheço, alguém conhece?
 Não sei dizer exatamente, mas...
 [Inaudível]
 Mas eu acho que sim, eu acho que inclusive foi inspirado nesse...
 Eu sei que vários filmes foram inspirados nesse project MK Ultra.
 [Inaudível]
 Ah, sim, pesquisa, você tem que fazer uma solicitação ao comitê de ética,
 toda vez que você vai fazer uma pesquisa com humanos, inclusive pesquisas na área de interação com o computador,
 elas muitas vezes precisam, mas tem os critérios, não é qualquer pesquisa que precisa.
 [Inaudível]
 É, não precisa.
 Mas se você quiser fazer uma pesquisa para controlar a experiência das pessoas, eu tenho certeza que vai precisar.
 [Inaudível]
 Sim, na verdade é um problema sério isso aí, mas é uma outra discussão.
 Vamos voltar para cá.
 Uma das maneiras de você manter o controle em situações de incerteza é fazer cálculos de probabilidade.
 Isso aqui está muito em voga hoje no mercado, que são utilização de analytics, como o Google Analytics,
 mas existem outros, esse aqui é um gratuito, mas existem outros muito mais sofisticados,
 que permitem que você analise basicamente tudo o que os usuários fizeram e também o que eles não fizeram.
 Também existem algumas ferramentas de analytics que têm poder preditivo,
 então pode saber qual é o próximo passo possível, possibilidade, probabilidade na verdade da pessoa clicar.
 Isso aqui é um modelo preditivo também, o do Google Analytics, que é o fluxo de conversão.
 Então aqui ele mostra quantos por cento das pessoas saem em um determinado passo, quantas continuam.
 O vermelhinho é a pessoa saindo, desistindo, ou indo para fazer outra coisa e não prosseguindo no ciclo,
 desculpa, no fluxo de conversão que gera a venda que, por exemplo, você está interessado dentro daquele e-commerce, por aí vai.
 Essa área, desculpa, essas ferramentas estão motivando até a criação de uma nova área,
 que são os profissionais especialistas em analytics, em estatísticas de experiência do usuário, UX Analytics.
 Porém, eu sou uma das pessoas que acha que esse tipo de informação não deve ser utilizada diretamente para tomada de decisão.
 Muita gente que só toma decisão com base em testes A/B. Você faz teste de duas versões diferentes da interface,
 vê quais delas aumentam a conversão. Se aumentou a conversão, não importa o que você colocou ali,
 você vai deixar aquele elemento novo dentro da interface, criando um efeito Frankenstein,
 porque você tem uma série de elementos que foram colocados e validados separadamente,
 sem validar e entender a experiência como um todo.
 Então, o que acontece? Quando você começa a projetar para analítica, você começa a projetar,
 mesmo que você tenha perfis diferentes de usuários, você tende à média,
 porque você vai tentar agradar o máximo possível de pessoas de diferentes maneiras.
 Então, isso gera um tipo de experiência medíocre.
 Você começa a projetar para uma pessoa que tem metade de um óculos.
 Não existe uma pessoa que tem metade de um óculos.
 Ou a pessoa tem ou não tem. O usuário médio não existe.
 Ele é uma abstração à estatística que muitas vezes as pessoas utilizam erroneamente
 para tomar decisão estratégica de um projeto.
 E o resultado disso é a comoditização do software.
 Então, o aplicativo, a noção de app, que agora ficou até menorzinho, app.
 Um app, ou um app no Brasil, o pessoal fala também app.
 Um app é um software que se transforma ou num commodity, um produto de extremamente baixo valor.
 Qualquer pessoa pode fazer um aplicativo. Você pode fazer um aplicativo e colocar na App Store.
 Você pode publicar sozinho o seu aplicativo e deixar disponível para qualquer usuário.
 E quando ele entrar na App Store, ele vai concorrer com 3 bilhões já?
 3.3 bilhões de aplicativos já existem na App Store.
 Então, como que ele vai se destacar? Como é que ele vai chegar nas pessoas?
 Se ele for mais um aplicativo.
 Se você digita na App Store que você quer ver uma...
 Você quer um jogo para jogar...
 Um jogo para você jogar garrafinha d'água para cima e virar.
 Foi um aplicativo que os nossos alunos fizeram.
 Tem dez na App Store. Igualzinho.
 Não adianta você querer fazer igual, porque ele vai ser um commodity.
 Ele vai ser como café. Café tem em qualquer lugar.
 Agora, o que tem de diferente no teu café?
 Essa é a conversa que eu quero avançar com vocês.
 E aqui o exemplo do café é porque tem um livro muito interessante que para mim é um livro mais importante sobre a experiência do usuário.
 E o menos lido no Brasil, que é o "The Experience Economy".
 Que é um livro de 1999, em que dois profissionais de marketing que trabalharam na IBM,
 conseguiram fazer uma reflexão muito boa sobre um paradigma novo que estava surgindo nos Estados Unidos e no mundo todo,
 que é uma economia orientada para ofertar experiências para as pessoas.
 Não mais ofertar apenas serviços, mas ir além de serviços.
 O serviço seria um serviço customizado, é uma experiência customizada para aquela pessoa.
 E aí, quando ele se torna um serviço customizado, você consegue cobrar um valor muito maior,
 porque aquilo ali é muito mais personalizado para aquela pessoa.
 Então, o Starbucks cobra três ou quatro vezes o valor de um café que tem na padaria da esquina,
 porque ele coloca o nomezinho, o teu nome, pergunta o teu nome, escreve o teu nome e fala o teu nome em público.
 Ele tem vários lugares diferentes para você ficar sentado, ficar em pé, ficar conversando.
 Ou seja, um ambiente que permite vários tipos de posturas, permite até que você fique usando o Wi-Fi por muito tempo.
 As pessoas iam para o Starbucks, que era o único lugar que tinha Wi-Fi gratuito e aberto.
 Então, aqui você tem uma experiência completa.
 Além, fora a parte de branding, que é genial, dessa marca.
 Então, quando você tem uma perda dessa customização, dessa personalização,
 você diminui o valor, você padroniza e você torna o seu produto muito fácil de ser copiado,
 de ser tirado da sua posição de mercado por um concorrente,
 que é um commodity ou um produto de mercado.
 Então, Payne Gilmore descreve nesse livro essa progressão do valor econômico,
 em que as ofertas que têm maior diferenciação, conseguem ser mais únicas, personalizadas para cada pessoa,
 elas têm mais valor.
 E eles dizem que esse é o novo paradigma de competição que o capitalismo atual está se concentrando.
 Para o software chegar nesse nível, para ele ser considerado,
 ser uma ferramenta que permite, proporciona, possibilita uma experiência,
 ele precisa se tornar único, ele precisa se tornar diferenciado.
 Eu sei que isso aqui, o que eu estou falando, vai contra a maior parte do que se discute em gênero de software,
 que é padronizar, que é estruturar, que é reduzir a diferença, a variabilidade.
 Às vezes é visto como uma coisa negativa.
 E o que essa tendência está fazendo?
 Está transformando o software em commodity.
 Tudo bem, tem vantagens? Tem.
 Às vezes o software é necessário, assim como o café também é necessário.
 Mas as empresas, as organizações que querem ser diferencial de mercado, têm que fazer o caminho oposto.
 E a qualidade da experiência do usuário, e os profissionais especialistas em experiência do usuário,
 são aqueles que justamente estão puxando para esse lado da personalização,
 da customização, de atender necessidades específicas de usuários específicos.
 Ok?
 Vamos começar a nossa primeira experiência prática?
 Então eu vou fazer com vocês o experimento número 68.
 Vocês topam participar do experimento?
 Algumas pessoas já participaram aqui.
 Ok? Vamos lá?
 Apesar de instruções de como comer o sonho de vós,
 seriam as mesmas para todo mundo,
 mas as descrições, dados das experiências, no final eram completamente diferentes.
 Então todo mundo passou pela mesma experiência,
 mas cada um teve uma qualidade diferente,
 teve um significado diferente para aquela experiência.
 E então ela foi única, ela foi uma experiência personalizada.
 Ela foi realmente uma experiência e não simplesmente consumir um commodity.
 O preço de um sonho de valsa é aproximadamente R$ 2,00, R$ 3,00.
 É um commodity, é barato.
 Qual é o valor de uma experiência como essa, como o experimento número 68?
 Qual o valor de você estar hoje aqui,
 ter comido esse bombom desse jeito, totalmente diferente,
 que vocês comeram,
 associados a um conceito de software,
 que a princípio, o que tem a ver bombom com software?
 E agora vocês têm aí com vocês uma memória,
 para vocês levarem uma experiência realmente significativa,
 uma experiência que você lembra.
 Eu usei várias técnicas aqui,
 eu não vou descrever elas, quem quiser conhecer mais detalhes,
 porque não é o propósito discutir todas essas técnicas hoje.
 Vou discutir algumas mais para frente,
 mas só para citar.
 Ambiguidade, suspense, surpresa, estimulação multissensorial,
 orquestração, arco narrativo e várias outras ainda,
 que são difíceis de até definir em poucas palavras.
 Então nesse livro do Paine Gilmer.
 Para encenar experiências com software,
 é preciso desistir do controle e abraçar o que eu estou chamando de possibilismo.
 É um paradigma novo para design de software,
 e dentro de uma perspectiva de processo ou de abordagem,
 eu estou chamando de projeto possibilístico.
 Ele trabalha com possibilidades ao invés de certezas,
 especula cenários extremos,
 dá atenção para detalhes negligenciados pela maioria dos concorrentes,
 enfim, dos softwares existentes,
 tenta fazer o impossível e aproveita o talento artístico dos seus criadores.
 O projeto possibilístico transforma a incerteza em oportunidade para criar novos conhecimentos.
 Então existe esse diagrama bem engraçado,
 que foi desenvolvido a partir de uma fala pública do Donald Rumsfeld,
 quando ele era algum tipo de líder militar dos Estados Unidos,
 e perguntaram "Poxa, vocês sabem se tem armas no Iraque?"
 Aí ele falou "Olha, a gente não sabe, mas existem coisas que a gente não sabe que não sabe,
 a gente precisa saber.
 Por isso que a gente tem que ir para o Iraque, porque a gente tem que invadir o Iraque".
 E aí o pessoal começou a criar,
 e dentro da gestão do conhecimento até um modelo bastante utilizado.
 Existem as coisas que a gente sabe que sabe, os "known-knowns",
 tem as coisas que a gente não sabe que sabe, os "known-unknowns",
 tem as coisas que você sabe que não sabe, desculpa,
 "known-unknowns" é esse aqui, sabe que não sabe,
 e você tem os que não sei que não sei, os "unknown-unknowns",
 que são os mais perigosos, porque aqui você não tem nenhum tipo de rastreabilidade,
 e pode surgir de uma hora para outra o que uma outra pessoa chamou de "cisne negro".
 O Taleb escreveu um livro chamado "Cisne Negro", "Black Swan",
 ele é um matemático, mas ele escreveu no formato meio romancístico, ensaístico,
 e isso causou um repulisco muito grande,
 até gerou a produção de um filme bastante conhecido,
 do "Black Swan", que é a história daquela dançarina de balé,
 mas aqui no caso do livro ele está explicando um fato histórico
 que ninguém acreditava que existissem cisnes negros na Europa
 até mais ou menos o século XVII.
 Desculpa, século XVIII.
 No século XVIII, alguém foi lá para a Austrália e viu um cisne negro de verdade,
 e aí essa descoberta improvável, era improvável que existisse,
 a probabilidade de existirem cisnes negros no mundo era muito pequena
 para quem só conhecia a Europa, porque na Europa só tinha cisne branco.
 Aí quando eles descobriram, tiveram que rever toda a estratégia de classificação taxonômica,
 as ideias da biologia, que foram culminar depois de alguns anos
 nas ideias da teoria da evolução do Darwin.
 Então essa descoberta do cisne negro foi importantíssima para a biologia,
 mas ela é um exemplo metafórico e poético para outras situações
 parecidas na nossa história humana, em que alguma coisa de baixa probabilidade
 negligenciada pela maioria dos líderes da nossa sociedade,
 acaba acontecendo e isso muda o jogo completamente.
 Então no caso da Apple, temos uma mudança, eu identifico um cisne negro
 dentro da história da Apple e da própria indústria do software,
 que é o lançamento do iPod, o primeiro.
 Se você ver, o volume de vendas da Apple geral, ele vem vindo assim,
 ele baixa um pouquinho, está quase caindo, de repente surge o iPod
 e vira uma escala ascendente que não para mais e que hoje levou a Apple
 a se tornar a empresa mais valiosa do mundo.
 Então o iPod, ele era improvável que ele seria melhor do que os outros
 tocadores de música da época, MP3, porque esses outros tocadores
 tinham mais capacidade de armazenamento, a bateria durava mais,
 tinha muito mais, mais, mais, mais, só que tinha muito menos
 qualidades da experiência do usuário.
 As qualidades eram, qualidades baixas, digamos assim,
 e o iPod vem com essa proposta de a experiência do usuário ser a prioridade
 e isso causou a mudança incrível no nosso cenário e hoje a gente tem
 um curso sobre qualidade da experiência do usuário e eu acho que em partes
 por causa desse acontecimento específico, em reação em cadeia,
 acabou gerando esse interesse.
 A Apple é uma empresa que é muito conhecida pelo controle da qualidade
 dos produtos, em geral eles são mais duráveis, eles dão menos defeito
 do que os concorrentes, embora isso esteja diminuindo nos últimos anos,
 mas de qualquer forma não é esse o principal diferencial da Apple,
 que faz as pessoas estarem, acamparem na frente da loja da Apple
 quando eles vão lançar um novo produto.
 O que faz isso é a expectativa da experiência do usuário que é criada
 por um estúdio, um ateliê de projetos dentro da Apple,
 que até alguns anos atrás era completamente secreto,
 ninguém podia entrar lá, há uns 3 ou 4 anos atrás a Apple
 resolviu abrir as portas para fazer a comemoração de um livro
 que, para mostrar, um livro que eles estavam lançando,
 que é o "Designed by Apple in California" e o Jonathan Ive,
 ele vai explicar um pouquinho como que é esse ateliê de projetos,
 que é onde eles criam esses excelentes trabalhos de design de produto
 e também de experiência do usuário.
 Então esse é um dos vídeos que a Apple divulga,
 um dos poucos vídeos, uma das poucas documentações que existem
 sobre a filosofia de design da Apple, como que eles conseguem fazer
 o que eles fazem.
 E é um pouquinho também, a gente utiliza esse vídeo para introduzir
 os nossos alunos quando eles começam nesse programa
 Apple Developer Academy.
 Mas apesar de todo esse esforço da Apple de criar qualidades
 da experiência do usuário únicas e customizadas e que as pessoas
 venham em valor, ainda assim tem muita gente que se frustra
 com aparelhos da Apple.
 Mesmo lá na Apple Developer Academy, com toda a estrutura,
 de vez em quando tem um ou outro reclamando.
 Por quê?
 Porque as pessoas são diferentes, cada um tem uma experiência
 diferente, cada um come o bombom de uma maneira diferente
 e interpreta e dá significado diferente.
 Então, mesmo a empresa que é a mais valiosa do mundo,
 ela não consegue controlar e definir absolutamente
 a experiência do usuário.
 Não é a mesma coisa do que você falar do produto físico.
 O produto físico é feito de alumínio, você tem ali um objeto
 de alumínio e de alumínio é, não tem o que discutir.
 É alumínio isso aqui.
 Agora, se isso aqui é fácil de usar, se isso aqui é atrativo,
 se é sedutor, se é legal, isso sujeita à discussão,
 e varia de acordo com o usuário.
 É relativo, é uma relação que existe entre o produto
 e o usuário.
 Então, o que recomenda a Pine e Gilmore nesse livro?
 A recomendação principal, de modo geral, eu vou repetir ela aqui,
 mas vou dar um exemplo bem interessante, é que cada experiência
 seja encenada diferente para cada cliente.
 E como é que você faz isso?
 Criando aspectos diferentes no seu software, gerenciamento
 de variabilidade, ou colocando de uma maneira mais,
 um vocabulário mais comum, customização, personalização,
 adaptação e a capacidade de você mesmo poder modificar o software.
 Um exemplo mais tangível disso aqui é o palco dos cinco sentidos,
 uma casa que se define como casa de shows, mas na verdade
 é um restaurante também junto com casa de show, que tem aqui em Curitiba.
 Se você tiver um tempo livre nesse dia e está visitando a cidade,
 recomendo altamente a experiência.
 Ele tem música ao vivo, então depois você pode comer uma comida
 bem diferente, tem comida interativa e por aí vai.
 Tem várias coisas lá, tem obras de arte também maravilhosas
 nas paredes, então eles tentam estimular todos os sentidos
 e também dar um tratamento.
 Então, se você tiver tempo, também converse com o dono
 do restaurante, porque ele conta muitas histórias interessantes.
 Né, Matheus? Conhece, né?
 Essas analogias que eu estou fazendo com artes e especialmente
 com a ideia de performance, de você performar uma experiência,
 vem de um livro chamado Computer as Theater.
 Computador como se fosse um teatro, da Brenda Laurel.
 Ela é uma pesquisadora da área de computação,
 conhecida na área de interação, mas no computador,
 participou de vários projetos importantes da história
 da computação, participou daquele Xerox PARC,
 aquela unidade de pesquisa que gerou as interfaces gráficas
 que temos hoje, participou da Interval Research,
 que foi uma empresa que desenvolveu vários produtos
 experimentais no começo dos anos 90 e o trabalho mais conhecido
 dela foi um projeto transmídia com vários brinquedos, histórias,
 videogames, desenho animado, para meninas se interessarem
 mais pela computação.
 Eu não me lembro exatamente do nome agora.
 A Brenda Laurel é pouco conhecida no Brasil, pouco citada.
 É uma pena, ainda mais que ela cunhou o termo experiência
 do usuário.
 Então, o primeiro registro que você encontra na literatura
 de interação, mas no computador, sobre esse termo experiência
 do usuário vai aparecer num artigo que ela escreveu
 para o livro "User-Centered System Design", que hoje é considerado
 um livro paradigmático na história do design centrado do usuário,
 que é o livro que juntou os pesquisadores que nos anos 80
 trabalhavam com esse assunto.
 Ela foi uma desses pesquisadores e lá ela diz,
 "Quando você está buscando princípios de bom design,
 nós devemos, da minha opinião, se preocupar com o caso melhor
 e nos perguntarmos, nós não devemos projetar para o que o usuário
 está capaz de aguentar.
 Nós devemos projetar para o que seria a experiência ideal
 do usuário e que tipo de interface pode proporcionar
 essa experiência."
 Veja, aqui ela separou a discussão entre interface e experiência,
 porque nessa época muita gente falava que o que interessava
 era a interface.
 Você tinha que definir os requisitos da interface, projetar, criar,
 enfim, pintar a qualidade visual da interface.
 Aqui ela está falando de outra coisa, quando ela fala da experiência
 do usuário como outra palavra.
 É um erro muito comum atribuir o crédito desse termo ao Dono Norman,
 que é um pesquisador mais conhecido no Brasil,
 inclusive porque ele veio ao Brasil na década de 90.
 E Norman só foi utilizar pela primeira vez a experiência do usuário
 em 1995, em um texto em que ele descreve a experiência do grupo dele,
 da Apple, que ele trabalhou na Apple nessa época.
 Ele estava falando sobre o grupo que ele queria chamar de experiência
 do usuário ali dentro.
 É o departamento de experiência do usuário.
 Então, um dos primeiros lugares onde realmente teve um departamento
 de experiência do usuário foi a Apple.
 Depois, quando voltou o Steve Jobs, ele mandou embora todo mundo
 desse equipe, inclusive o próprio Dono Norman.
 Mas isso é uma outra discussão que não cabe aqui.
 O que é importante citar é uma mulher que criou esse termo
 de experiência do usuário.
 Porque normalmente os homens são atribuídos, tem muitos créditos
 na computação, muito comum isso.
 Depois de um tempo, descobre-se que uma mulher fez antes de um homem.
 Ah, agora vamos valorizar as mulheres.
 Então, é importante que esse caso aqui não fique em branco.
 Mas o que a Brenda Lora fez, mais importante, eu acho até
 do que cunhar esse termo, é propor um modelo para pensar a interação
 entre pessoas e máquinas e computadores, melhor dizendo,
 como um palco de teatral.
 Então, a interface, ela seria um espaço onde você teria vários agentes.
 Esses agentes seriam esses triângulos.
 Esses agentes podem ser humanos ou podem ser não humanos.
 Podem ser agentes de software inteligentes.
 Por exemplo, um NPC, um Non-Playable Character, um inimigo,
 um chefão do jogo que você está jogando.
 Ele pode ser um agente.
 E aqui, você tem vários objetos.
 E esses agentes vão interagir para transformar esses objetos
 dentro desse palco.
 Então, a interação com o computador visa representar uma ação humana
 que está acontecendo num espaço virtual, mas que tem efeitos e resultados
 no espaço físico ou no mundo real, se quer colocar essa diferença.
 Eu não vou entrar em muitos detalhes, porque essa é uma discussão até mesmo
 filosófica, mas a parte prática do livro dela começa a falar que, ok,
 se existem várias possibilidades de ação num espaço teatral,
 você pode fazer o que você quiser num palco, o software se torna
 muito complexo, porque ele teria que permitir que a cada interação
 que você fizesse, abrisse de novo o campo de possibilidades para mais coisas
 que você vai poder fazer, mais coisas a cada árvore.
 Então, a cada vez que você abre numa árvore de decisão mais um galho,
 você vai dando mais opções para o usuário e a complexidade
 desse software vai aumentando.
 Então, ela propõe que o projeto software deva tender ao que é mais
 provável de acontecer até chegar no que é necessário.
 Isso aqui é um diagrama que faz todo sentido quando você descreve software,
 mas é um diagrama originalmente criado para descrever o que acontece no teatro.
 Então, essa analogia entre teatro e software é muito produtiva.
 Esse livro é muito bacana e bem pouco conhecido no Brasil.
 Porém, eu tenho algum tipo de...
 algumas... apesar de gostar muito desse trabalho, tem algumas reservas
 e eu acho que a gente tem que pensar fora do cone.
 Tal como o Ginsberg, que propõe que a gente deve pensar um cone expansivo,
 que se abre, não um cone que se fecha.
 Que você tem que considerar situações improváveis, implausíveis, impossíveis.
 Porque a tendência do usuário, quando ele está usando,
 é fazer o impossível mesmo.
 Nem vocês viram lá o caso dos jogadores jogando com a divisória do papelão.
 Então, uma vez eu estava testando esse aparelho telefônico
 para ver o que era possível fazer com ele, e eu cliquei em alguma coisa
 e ele me disse "Impossível".
 Isso ficou na minha mente.
 Eu tirei uma foto e falei "Gente, o software está me dizendo que é impossível fazer alguma coisa.
 Como assim impossível? Eu faço o que eu posso, eu faço o que eu quero,
 eu consigo fazer isso aqui.
 Não é possível que um software me diga o que não é possível fazer".
 Gente, eu posso criar software, eu sei fazer isso.
 Então, não existe nada impossível para mim.
 Daí eu tirei essa foto e falei "Olha, a gente tem que começar a pensar software
 como um software que abre as possibilidades para o usuário e não fecha,
 não diz o que é impossível".
 Sei que isso é um pouco filosófico, um pouco idealista,
 mas lembra-se da Brenda Lória falando "A gente não tem que fazer aquilo que é o menos pior,
 a gente tem que fazer o que é o ideal para o usuário".
 Então, o software não é uma experiência inteira, ele é um material para a experiência.
 Essa definição que vem aí dos estudos do design de interação,
 depois eu vou falar mais um pouquinho sobre essa abordagem,
 ela se tornou agora super conhecida através do material design do Google.
 O Google falou que interfaces podem ser projetadas como um material físico.
 Você pode ter uma analogia, assim como o papel fica em cima e você sente a fisicalidade do papel,
 você vê a sombra, você vê o relevo,
 o software, um aplicativo pode ser projetado desta maneira.
 Essa é uma ideia, na verdade, antiga do design de interação,
 depois eu vou abordar em mais detalhes nos próximos slides.
 Vamos então a mais um exercício.
 Vamos lá, dessa vez não vai ser uma experiência que requer tanto de vocês, eu espero.
 Enfim, é bem simples.
 Ok, então vocês tiveram, eu imagino, uma discussão sobre qualidades da experiência,
 vocês viram que um software que você usa de um jeito, a pessoa usa de outro,
 e às vezes você observando a qualidade, observando a experiência do uso da outra pessoa,
 você também não entende tudo o que está acontecendo,
 você precisa conversar depois para entender a ação.
 Então aqui agora vocês tiveram um material, uma experiência em primeira mão,
 agora eu vou propor um modelo que tenta explicar o que aconteceu aqui com vocês.
 Vocês tiveram um tipo de experiência emergente,
 esse tipo aqui, daqui a pouco eu vou falar sobre experiências projetadas,
 e a gente vai ter esse tipo de experiência, mas agora vocês tiveram esse tipo de experiência aqui.
 Esse modelo que eu ainda estou trabalhando em cima e desenvolvendo,
 ele define o software como um material para a experiência,
 a interação como processo de interação entre o usuário e o software,
 que resulta numa experiência.
 E aí a experiência pode ser escrutinizada,
 pode ser avaliada para identificar suas qualidades,
 mas isso numa reflexão, numa avaliação, não é um resultado.
 O resultado não é a qualidade da experiência.
 A qualidade da experiência é um processo de reflexão,
 pode ser feito pelo usuário, pode ser feito pelo designer,
 pode ser feito por um analista, pode ser feito por outros profissionais.
 O espaço de controle se restringe ao software e imparte-se a interação.
 Você consegue controlar alguns aspectos da interação,
 mas outros aspectos o usuário pode até interagir de um jeito que você não imaginava,
 pode burlar as regras, pode, enfim, hackear, fazer gambiarra, por aí vai.
 Mas você tem um certo controle sobre a interação.
 Agora, sobre a experiência,
 eu espero que esteja ficando cada vez mais claro o meu ponto,
 se não tem como controlar.
 Aqui é um espaço de possibilidades.
 A minha tese de doutorado fala muito sobre esse assunto, espaço de possibilidades,
 então eu estou tentando usar esse conceito para propor uma maneira diferente de projetar software
 em que tudo é possibilidade, inclusive o software.
 Ao invés de a gente focar na experiência emergente, que é incontrolável,
 vamos focar na experiência projetável, que é possível.
 E o possível não é menos do que o incontrolável.
 O possível é muito melhor do que o incontrolável.
 Então vamos falar sobre experiências projetadas.
 Tipos de experiências projetadas.
 Uma delas é a Vicária, que é o que vocês tiveram agora.
 Você se coloca no lugar de uma pessoa e interage como se fosse ela.
 Então você pegou o aplicativo da pessoa que você conhecia ou não conhecia, do seu colega,
 e você tentou interagir com aquele aplicativo como se fosse aquela pessoa.
 Então você tentou reconstruir a experiência dela.
 Isso se chama Vicária.
 Também quando você assiste um filme na televisão e você vê um personagem,
 você começa a sentir as emoções dele.
 Sabe aquele negócio que o personagem fica com medo e você fica com medo?
 Ele sorriu e você dá aquele sorrisinho.
 Mesmo que você está se segurando para não rir, você ri.
 Isso é a experiência Vicária.
 Um exemplo, quando eu estava bem no começo da minha carreira,
 eu fui projetar um site para a ótica de visão e eu não usava óculos na época.
 Eu queria saber o que era usar óculos.
 Então eu tinha emprestado óculos de uma colega minha, designer,
 e fiquei usando óculos por algumas horas para ver o que era usar óculos.
 E é claro que eu não enxergava direito porque eu usava de grau na época.
 Aí eu comecei a perceber como era chato você não conseguir enxergar as coisas direito.
 O óculos teve efeito oposto.
 E como que o site deveria ter textos grandes, bem visíveis para as pessoas verem,
 porque senão uma pessoa que está sem óculos e que está precisando ir na ótica para trocar o óculos,
 ou que está desajustado, ela vai ter uma experiência ruim.
 Então a partir dessa, o que hoje se chamaria de empatia,
 se colocar no lugar do usuário, ou que eu coloco uma palavra muito mais técnica,
 experiência Vicária, você pode ter um insight sobre como projetar a experiência,
 ou melhor, como projetar o software para proporcionar, possibilitar uma experiência com certas qualidades.
 Aqui, experiência observada.
 Vocês também tiveram, daí outra pessoa que estava olhando,
 observando a interação com o aplicativo novo.
 Isso aqui é um exemplo de um estudo que o Instituto Faber-Ludens,
 é uma ONG que eu trabalhei muitos anos atrás,
 estudou como, logo no começo do lançamento dos iPads,
 como é que os leitores liam o jornal digital do Globo.
 Então a gente foi lá na casa dos leitores, tiramos fotos, perguntando "onde você lê?"
 Aí a pessoa ia lá e mostrava onde ela lia.
 E uma coisa que a gente descobriu, que a gente já tinha ouvido falar desse fenômeno fora do Brasil,
 que era a segunda tela, "second screen".
 A gente descobriu que alguns usuários no Brasil já estavam fazendo "second screen",
 que é você assistir televisão enquanto você fica lendo notícias ou vendo informações no iPad.
 Depois, com o tempo, começou a surgir as integrações entre aplicativos móveis e smart TVs.
 Mas nessa época, acho que foi 2008 esse estudo, não existia ainda esse tipo de integração.
 E foi através da observação desse tipo de experiência,
 que os designers, os desenvolvedores do YouTube,
 de outras empresas que começaram a oferecer integrações,
 eles criaram a partir desse insight, dessa observação.
 Outro tipo de experiência projetada é a retrospectiva.
 Depois que vocês também estiveram aqui, vocês pediram para o colega,
 depois de ter interagido, dizer o que tinha interagido, o que tinha feito.
 Então, quando você pede uma pessoa para relembrar como foi a experiência dela,
 ou quando eu pedi para vocês escreverem aqui nos papéis sobre a experiência,
 no experimento número 68, isso aqui foi uma experiência retrospectiva.
 Vocês relembraram, reconstruíram aquela experiência.
 Eu tive a oportunidade de participar de um teste de usabilidade de um primeiro refrigerador brasileiro
 que tinha touchscreen.
 E eles queriam fazer um teste de usabilidade tradicional,
 mas ao ver o produto eu falei, gente, esse produto deve ter um impacto emocional
 muito interessante para o consumidor e a gente seria interessante mensurar.
 Então, a gente acrescentou uma etapa extra no final do teste de usabilidade
 chamada modelagem de emoções.
 Então, a gente pedia para as usuárias modelarem como foi a experiência delas
 usando massa de modelar, literalmente.
 E aí, depois, elas descreviam isso para a câmera e a gente colocou essas palavras
 para resumir, digamos assim, o que foi dito.
 Então, cada uma dessas usuárias teve uma experiência diferente,
 mas todas elas ficaram bastante atraídas pelo aspecto emocional e não funcional
 daquele produto.
 Experiência prospectiva.
 Aqui é um caso bem raro, mas muito interessante.
 Eu também acho pouco explorado.
 Poderia ser mais explorado no design de software,
 mas foi uma das ferramentas mais importantes para a história do software.
 Foi com essa ferramenta, com esse tipo de experiência,
 que foi criada a primeira interface,
 uma das primeiras interfaces gráficas de processamento de texto.
 Então, tinham dois desenvolvedores, pesquisadores da Xerox PARC,
 nos anos 70, trabalhando com um editor gipsy,
 era um editor de texto que tinha a proposta de ser "what you see is what you get".
 Ele tem a mesma aparência visual do que teria um documento impresso
 dentro do Xerox Alto, que foi o primeiro computador que a Xerox produziu
 que tinha interface gráfica.
 Eles criaram a interface colocando uma secretária na frente desse computador,
 desligado, com tela desligada, com o mouse do lado.
 Explicaram o que era um mouse para uma secretária que nunca viu um mouse,
 nunca viu um teclado.
 Isso é um mouse, isso é um teclado, ele faz isso, faz aquilo.
 Agora, se você fosse escrever um texto, como é que você faria?
 Então, a secretária utilizou a experiência prévia que ela tinha
 de datilografar em máquina de escrever,
 foi falando "ah, eu digitaria aqui porque isso é parecido com uma máquina de escrever".
 E se você quisesse mudar uma coisa que você já viu,
 uma coisa que você já escreveu, como é que você faria?
 Ela "ah, eu teria que dar uma girada".
 Não, não tem negócio para girar.
 Então, se não tem negócio para girar, que na máquina de escrever você gira,
 e solta o papel e tal, aí o pesquisador fala "olha, você pode usar esse outro dispositivo
 aqui que aponta, cria um ponteiro na tela, é como se fosse um ponteiro no papel".
 "Ah, é? Ah, então eu apontaria aqui onde eu quero e apertaria esse botão".
 "Ah, é? Ah, então tá, você apertaria o botão".
 E depois, se você quisesse apagar essa palavra que você escreveu errada,
 "ah, eu apertaria duas vezes o botão, aí selecionaria a palavra".
 Quem criou isso não foi o desenvolvedor, foi o usuário.
 O usuário inventou isso.
 E várias outras conceitos que hoje a gente acha banal de interface,
 do tipo selecionar uma frase, clicar três vezes, selecionar o parágrafo todo.
 Até o copiar e colar apareceu nesse exercício de experiência prospectiva.
 O termo técnico que ele utiliza não é esse, é fantasia guiada, ou guided fantasy.
 Um método pouco conhecido, pouco utilizado, mas fundamental para a história
 da interação no computador.
 O outro tipo de experiência muito inspirado no teatro é a experiência encenada.
 Então você atua dentro de um espaço significativo, pode ser um espaço
 metafórico físico, então você pode imaginar que o espaço físico é um espaço
 de software. Então aqui nesse caso, os nossos estudantes do bachilado em engenharia
 de software estão experimentando uma interface de comando de voz,
 atendimento telefônico, usando apenas o espaço da sala de áudio.
 Então eles criaram essa barreira para que o usuário que está aqui não veja
 a interface, porque é uma interface auditiva, sonora, um menu telefônico.
 E aqui estão desse lado os outros estudantes que são a máquina,
 que representam aquele menu e que só falam o que o menu fala.
 Eles têm dentro do computador toda a árvore de decisão escrita e eles vão
 de acordo com a resposta do usuário, pesquisando lá e em tempo real
 improvisando uma resposta do que seria um menu telefônico.
 Para quê? Para testar através dessa encenação se esse usuário encontraria
 o que ele está procurando quando ele vai acessar o menu telefônico,
 se ele não fica perdido, se a qualidade dessa experiência do usuário é boa.
 Então a gente usa bastante essa técnica, eu pelo menos uso bastante e vou usar
 com vocês daqui a pouco também. A gente vai fazer um pouco de teatro e é por isso
 que a gente tem essa mala gigante aqui.
 O último tipo de experiência que eu queria passar para vocês é a co-criada.
 Então aqui temos uma integrante aqui, a Erika está aparecendo aqui na foto.
 A Erika, assim como eu, faz parte de um projeto, sim, como a Anne também,
 um projeto chamado Copel+ que a gente está criando uma plataforma de inovação
 aberta para startups de estudantes. E além da participação da Erika,
 que não é designer, não é programadora, é pedagoga, que está participando
 do projeto de software, tem a participação do próprio usuário.
 O próprio usuário, no caso um startupero aqui da PUC, um estudante muito conhecido
 aqui na universidade, o Kevin, e ele está dando várias ideias de como
 poderia ser essa plataforma. Então aqui tem vários desenhos que ele criou,
 ele criou em cima dos nossos desenhos, a gente continuou o desenho dele.
 E a gente disse que nesse projeto a gente está tendo várias experiências co-criadas.
 Uma parte da experiência é uma pessoa que tem, outra parte é outra.
 A gente chama isso também tecnicamente de design participativo.
 Ah, desculpa, tem mais uma, que é a experiência criticada, que vocês também tiveram aqui
 no final do último exercício, que é você olhar para a interface,
 o Everton também já sofreu muito com isso, quando era meu aluno,
 a Patrícia também, não sei, acho que você não teve nem tanto,
 mas na época do Everton eu era mais duro com os alunos,
 que criticava intensamente os trabalhos da Academy, moleza o que vocês levavam lá.
 Isso aqui, para vocês terem uma noção, assim que a gente avalia os trabalhos
 aqui no design digital, a gente colocava em uma mesa e o aluno tinha que se defender
 com o que ele tinha de proposta de experiência, com o que ele tinha de evidências da interface.
 Então os rabiscos, antes de produzir realmente um protótipo,
 eles mostravam os rabiscos e as propostas do que eles viam como uma possível experiência.
 E aí os professores imaginavam que se eles fossem um homem de negócios,
 tentando interagir, eu não conseguiria usar isso aqui, eu não entenderia isso.
 Ou então, se eu fosse uma pessoa que não entende muito bem das coisas,
 que é meio confusa, um bobo, eu teria essa dúvida, eu teria aquela dúvida.
 E aí a gente utiliza uma técnica que é tradicional dos ateliês de projetos,
 do design, da arquitetura e das artes plásticas, que é chamada sabatina,
 ou em inglês design critique, que é uma técnica para você ter experiências criticadas,
 em que o professor se coloca no lugar do usuário, muitas vezes ele cria uma crítica que não é,
 não tem fundamento, mas ele ajuda o estudante a ver uma qualidade que não está explícita no software,
 porque ela não está desenhada na interface.
 Como eu falei, a qualidade é algo um pouco mais intangível,
 é uma característica emergente que você não consegue tocar.
 Mas através do discurso, da crítica do professor, da interação,
 o estudante consegue entender um pouquinho melhor do que é essa característica.
 E isso é feito de maneira bastante tácita dentro das escolas de arquitetura e design.
 É muito raro esse tipo de teorização que eu estou apresentando aqui,
 e essa teorização com certeza vem pela minha experiência com engenharia de software.
 Normalmente dentro das escolas de design isso é, digamos, uma...
 sempre foi assim, é normal, é desse jeito que é nas escolas de arquitetura e design.
 Não se questiona muito isso, por que o professor vem e critica.
 Agora quando você está em um outro contexto, por exemplo, lá na Apple Developer Academy,
 tem alunos que não são estudantes que têm experiência com design.
 E aí você critica o trabalho deles para tentar pegar e discutir as qualidades da experiência do usuário,
 e eles acham que a crítica é contra eles.
 E daí ficam às vezes até meio ofendidos, né?
 Mas fecha parênteses.
 Ok.
 Então, resumindo, experiências projetadas são intersubjetivas, tá?
 Elas envolvem vários sujeitos.
 Muita gente fala que "Ah, se a experiência do usuário é uma coisa subjetiva,
 a gente não pode discutir isso dentro do conceito da engenharia,
 porque engenharia é para coisas objetivas".
 Mas não é só subjetivo, é intersubjetivo.
 O que a gente discutiu aqui até agora, a gente falou,
 a gente tem esses rituais dentro do design, da crítica, né?
 A cocriação, tudo isso é intersubjetivo, tem vários sujeitos.
 Quando tem vários sujeitos, o que que começa a acontecer?
 Começa a se tornar objetivo.
 A hora que você fala uma coisa, a fala é objetivo.
 A fala você pode transcrever, você pode colocar num papel,
 você pode analisar a incidência da fala, quantas vezes a pessoa falou, por aí vai.
 A participação de pessoas diversas na experiência projetada,
 ela expande o espaço de possibilidades consideradas.
 Quanto mais gente diferente, mais possibilidades se considera.
 Isso pode ajudar você a lidar melhor com essa incerteza.
 Então, várias perspectivas, pensando sobre a experiência do usuário,
 pode ajudar você a tornar o seu software mais robusto, mais flexível,
 mais resiliente ao que pode vir a acontecer.
 Isso não significa que as experiências projetadas serão iguais às experiências emergentes.
 Mas isso não é necessariamente uma coisa ruim que elas sejam diferentes.
 Pode ser bom até, porque pode ser uma experiência muito melhor do que você tinha imaginado.
 Então, o que que seriam qualidades da experiência do usuário da maneira como eu estou propondo aqui?
 Óbvio que isso aqui é uma visão bem diferente de qualidade de software que normalmente se trabalha.
 Qualidades da experiência projetada são sempre possibilidades, não certezas.
 Mas as qualidades da experiência emergente também são possibilidades.
 Não existe certeza quando você fala de experiência.
 Existem qualidades comuns entre softwares, como usabilidade, utilidade, acessibilidade,
 atratividade e encontrabilidade.
 Essas palavras foram propostas por pesquisadores e praticantes,
 e hoje elas integram o vocabulário de quem trabalha com experiência do usuário,
 utiliza-se essas palavras e porque existem essas palavras nós conseguimos falar
 e projetar muito melhor essas qualidades.
 Só que existem várias qualidades para a experiência do usuário que não tem palavras ainda.
 Muitos atributos dessa experiência do usuário que a gente ainda precisa definir melhor.
 Porque não se restringe, como começou o movimento e o termo experiência do usuário,
 começou a ser utilizado pelo dono Norman porque ele queria falar de algo a mais do que usabilidade.
 No caso da Brenda Lauren, um pouquinho diferente,
 ela queria enfatizar aquela questão da experiência ser teatral, do usuário ter várias possibilidades.
 Mas no caso do dono Norman, ele queria falar de algo a mais do que usabilidade.
 Por isso que eu comecei a usar experiência do usuário dentro da Apple, que era tudo.
 Tinha que pensar a experiência como um todo, não só a funcionalidade.
 Hoje nós temos palavras como acessibilidade, que nos ajudam a incluir pessoas com deficiência no projeto,
 a pensar nesse aspecto, mas e as outras?
 As outras qualidades da experiência do usuário que ainda não tem nome.
 E às vezes é difícil de escrever em palavras.
 Eu gosto bastante do trabalho de um pesquisador sueco chamado Jonas Lufgren,
 que em 2004 escreveu um livro chamado Thoughtful Interaction Design,
 que mudou minha vida e que me fez decidir que eu queria trabalhar com isso.
 Enfim, ele tem uma pesquisa muito interessante sobre estética da interação,
 em que ele tenta ajudar a criar vocabulários, palavras para novas qualidades.
 Então ele fez esse mapinha aqui em 2002, numa publicação interessante,
 que ele fala sobre qualidades de uso.
 Ele usa esse termo bem diferente de como se usa qualidade em uso dentro da engenharia de software.
 Mas o que ele queria falar aqui eram de características da experiência do usuário
 que estavam sendo perdidas por focar só em utilidade ou eficiência.
 Ele chegou à conclusão que existe, por exemplo, uma maleabilidade, pliability,
 o software ser maleável para os seus inputs e respondes, outputs.
 Então antigamente, quando foi lançado o iPhone,
 muita gente ficava se divertindo com vários aplicativos que usavam acelerômetro,
 um clássico inútil, o mais inútil era o de beber cerveja.
 Você fazia assim, virava, aí aparecia uma cerveja descendo.
 Eu tinha um outro que era o de aguinha, que era de graça, do cerveja tinha que pagar.
 Um dia eu tinha uma aguinha, você chacoalhava assim, as pessoas "oh, nossa", chacoalhou.
 O que é aquilo ali? Maleabilidade.
 Essa é a qualidade da experiência do usuário que chamava atenção nesse produto
 e que é totalmente perdida quando você está discutindo apenas usabilidade.
 E aí ele levantou várias outras. Influência, para-funcionalidade, imersão, por aí vai.
 Bom, antes de eu explicar, e eu não vou explicar na verdade,
 vocês vão ter uma experiência direta com essas qualidades.
 Então agora o último exercício antes de a gente sair para o recreio,
 é mostrar para a sua dupla, aquela mesma que você trabalhou anteriormente,
 como que você produz essas qualidades, uma dessas qualidades,
 que você olhe para ela e fale "puxa, essa aqui eu entendi o que é".
 Mostra um aplicativo que você tenha e mostra como você produz essa qualidade
 quando você usa esse aplicativo.
 E aí depois troca, depois outra pessoa mostra a mesma coisa no seu aplicativo.
 Ok? Vamos lá? Dez minutinhos para essa atividade e acabou.
 Então espero que agora, depois da experiência do Coffee Break,
 eu consegui finalmente uma cópia do livro da história da Ada Lovelace.
 É uma amiga minha que fez.
 Ah, é? A ilustradora é tua amiga?
 Ah, que legal, parabéns. O trabalho dela é muito bom.
 Então vamos lá.
 Vamos prosseguir com essa discussão sobre qualidades da experiência do usuário
 e as pessoas que já discutiram esse assunto.
 Seja bem-vindo, fique à vontade.
 Quem começou a discutir esse assunto antes mesmo do Jonas Lufgren,
 que eu mencionei agora há pouco, né?
 Que é o cara do design de interação, que fez esse mapinha aqui de palavras
 que definem qualidades da experiência do usuário.
 Antes muito disso, lá nos anos 60 e 70,
 um arquiteto chamado Christopher Alexander começou a pensar
 que existia uma qualidade relativa a um lugar que você estava,
 a um ambiente físico, e a arquitetura não estava descrevendo,
 não estava discutindo e nem se preocupando suficientemente com essa qualidade.
 Na arquitetura se falava muito sobre taxa de ocupação,
 sobre dimensões, sobre insolação, que é a capacidade de receber o sol,
 conforto térmico, mas existiam várias outras qualidades da experiência do usuário
 que não se discutia.
 E aí ele sentia uma dificuldade quando ele se sentava com o cliente
 para fazer o projeto da casa dele, do ambiente de trabalho, da escola, enfim,
 e aí quando ia projetar ele não tinha base,
 porque ele queria proporcionar aquelas qualidades da experiência,
 mas o cliente não podia dizer quais eram, não tinha um vocabulário comum.
 E aí ele resolveu, junto com um grupo de pesquisadores na universidade,
 se não me engano de Oregon, começou a pesquisar o que depois ficou conhecido como patterns.
 Na verdade ele deu o nome, patterns, que são padrões recorrentes,
 estratégias recorrentes que as pessoas utilizam para construir ambientes.
 Então ele chama isso de uma maneira atemporal, porque sempre foi assim,
 é uma característica já cultural, que as pessoas vão reproduzindo esses padrões.
 E aí ele organizou esses padrões numa linguagem e escreveu esse livro aqui,
 Pattern Language, e um outro chamado Timeless Way of Building,
 que explicam essa abordagem de arquitetônica.
 Esses livros foram feitos, escritos para que um cliente, um usuário,
 que não sabe nada do processo construtivo,
 possa dizer quais são as qualidades que ele deseja na sua construção.
 Então, por exemplo, um exemplo de um pattern é o Beer Hill,
 que é o lugar onde você, também chama Beer Garden, tem vários outros nomes,
 que é o lugar onde você senta com os seus colegas para bater um papo,
 bem regado a álcool, regado a cerveja.
 Então ele tem essa característica, esse espaço amplo,
 onde as pessoas sentam coletivamente, onde tem bastante reverberação do som,
 você sente aquele clamor, onde está todo mundo "vá, vá, vá", falando alto.
 Isso são todas as qualidades da experiência do usuário que são,
 de uma certa maneira, proporcionadas ou possibilitadas
 pelo tipo de arquitetura, pelo tipo de construção.
 E esse livro, o Pattern Language, ele teve mais influência,
 por incrível que pareça, na computação do que na própria arquitetura.
 O Christopher Alexander foi mais lido na computação
 pelo intermédio de um trabalho que apresentou o trabalho dele,
 o pensamento arquitetônico dele, adaptou para a engenharia de software,
 que foi o trabalho do Gang of Four, que escreveu Design Patterns,
 que é o conceito fundamental de identificação de padrão de projetos,
 em português, entre diferentes softwares.
 Você encontrar estratégias, como por exemplo, o padrão Factory Method,
 que você cria um método para construir outras partes do software,
 e vários outros métodos, desculpa, vários outros patterns.
 Só que nessa abordagem, nessa apresentação que o Gang of Four faz
 dos patterns, não apresenta a filosofia que está por trás.
 Só pega esse pedaço de uma estrutura recorrente de software,
 então, estudando como que a maior parte dos programadores que trabalharam
 eles criaram esses patterns.
 Mas toda essa parte de qualidades da experiência do usuário
 que a gente discutia, foi deixada de lado.
 Mais alguns anos se passaram e os pesquisadores da linha do design de interação,
 da interação no computador, começaram a pesquisar patterns também.
 Só que aí, patterns de interface, padrões de interface,
 padrões visuais que mostravam ali, como que as pessoas interagiam
 usando o software.
 Daí, mais parecido com o conceito original lá do Alexander.
 E eu, por acaso, tenho, ou por acaso não, com bastante paciência,
 procurando na internet, encontrei esses cards, estão aparecendo nessa foto.
 São cards com, cada um com um pattern diferente de interface.
 É uma referência muito bacana, que eu passo para os meus estudantes
 que estão começando a aprender a desenvolver um vocabulário para criar software.
 Primeiro pensar na interface, porque a interface é o ponto de contato
 mais próximo com o usuário e para pensar como possibilitar a experiência do usuário.
 Depois, vai entender como criar, usar os patterns de programação.
 Eu acho mais importante primeiro ter esse aspecto mais concreto e tangível.
 Então tá, vamos continuar.
 Os patterns, eles servem para pegar uma qualidade.
 O próprio Christopher Alexander falou o seguinte,
 quando eu criei os patterns, eu não queria criar uma única qualidade.
 Eu não queria criar uma qualidade para cada pattern.
 Eu queria que os patterns fossem combinados, sobrepostos, para produzir uma única qualidade.
 Uma qualidade de estar num lugar que você se sente totalmente conectado com aquele lugar,
 você se sente totalmente parte daquele lugar.
 Você se sente como se estivesse no melhor lugar do mundo.
 E ele falou, essa qualidade não tem nome.
 Não tem como nomear essa qualidade.
 Ela é extremamente objetiva, porque quando você está lá, você sente,
 você sabe que você está lá, você sabe que aquele lugar é incrível,
 é maravilhoso, como esse lugar aqui.
 Nossa, é um tipo de sensação difícil de descrever.
 Enfim, isso é um arquiteto falando.
 Arquitetos têm essa característica de serem meio vagos às vezes.
 Agora vamos para os designers.
 Os designers são bem mais objetivos.
 Então, os designers pensando nesse mesmo assunto,
 eles deram um nome para essa coisa, essa qualidade que você não consegue dar nome,
 e chamaram isso de gestalt.
 Então, o que os designers chamam de gestalt é a mesma coisa que o gestalt, em alemão,
 que é uma sensação do todo.
 Aquela coisa holística, aquela coisa que você só consegue sentir
 depois que você entendeu um produto por completo, todas as suas características.
 E no caso do software, a gestalt que você propõe é uma gestalt interativa,
 é uma gestalt da interação.
 E ela é produzida pela relação entre a experiência do usuário
 e o artefato interativo, no caso o software.
 Então, você tem aqui as propriedades do artefato, que são bem objetivas,
 tem o tamanho do artefato, tem que aquele artefato é transportável.
 Aí você tem uma aplicação móvel que está dentro desse artefato,
 que é o smartphone, é a mobile pay,
 e ela produz esse tipo de gestalt,
 de ser uma interação que é conectada, que é separada,
 que é direta, que é ordenada, precisa, rápida, sequencial.
 Todas essas são características da interação que fazem parte de um todo.
 E a experiência do usuário é basicamente o que você fez.
 Você perguntar para o usuário e falar "eu transferi dinheiro para uma pessoa,
 para uma outra pessoa", fazendo um swipe, fazendo esse gesto.
 Mas na verdade o que ela sentiu foi essa gestalt como um todo.
 E você pode depois pedir para ela analisar e dar qualidades,
 do tipo fácil, difícil.
 Então esse aqui é um modelo bem interessante,
 que faz a união entre as qualidades da experiência do usuário,
 as qualidades do artefato e essa qualidade sem nome,
 essa coisa mais holística, mais ampla,
 que eles chamam de gestalt da interação.
 Por que é importante pensar no todo, quando você pensa em experiência do usuário?
 Porque a experiência não se restringe ao software.
 Isso é uma coisa que muitas vezes é difícil de aceitar,
 mas muito mais difícil de entender o que acontece depois que a pessoa está interagindo com o software.
 E como que uma organização pensa como possibilitar uma experiência que seja fluida
 entre os diferentes pontos de contato que essa empresa tem com os seus clientes.
 Então, às vezes, um cliente vai ter um acesso inicial por uma web,
 como o serviço da empresa,
 depois ela vai usar um aplicativo móvel,
 depois ela vai em um balcão, vai pedir alguma coisa pessoalmente,
 vai na loja física, vai ter uma interação com uma pessoa,
 depois ela vai comprar algum produto da empresa, de repente,
 vai ter acesso a um tipo de marketing, pode ser impresso, pode ser pela televisão,
 depois pode ter acesso a outros serviços que se conectam com esses serviços da tua empresa
 e os materiais impressos.
 Então, nesse fluxo inteiro aqui que eu passei,
 não necessariamente acontece nessa ordem com todos os clientes,
 mas para demonstrar que existem transições na experiência do usuário de uma mídia para outra,
 um ponto de contato para outro.
 E as empresas que pensam na experiência do usuário como prioridade,
 elas pensam nessas transições e tentam torná-las muito fluidas.
 A Apple, por exemplo, ela desenvolveu várias tecnologias de integração
 entre as suas plataformas que permite que você comece uma atividade em um dispositivo
 e continue em outro.
 Por exemplo, você está ouvindo uma música no seu Macbook,
 aí você quer continuar ouvindo ela no seu iPhone,
 você tem uma conexão, não é tão fluida assim, dá alguns problemas,
 mas teoricamente isso seria possível.
 Você desconectou do computador e colocou no smartphone,
 plugou o fone de ouvido e você continua ouvindo do ponto onde você parou aquela música.
 Foram outras tecnologias que eles estão desenvolvendo,
 mas que ainda não funcionam muito bem,
 mesmo dentro de um cenário onde ela constrói todos os artefatos.
 É bem difícil fazer esse tipo de integração funcionar do ponto de vista técnico.
 Agora, é muito mais fácil você fazer isso funcionar do ponto de vista humano.
 E você tem uma pessoa que entende aquela integração e faz essa conexão,
 "stitch together" em inglês, que ela conecta as partes.
 Por exemplo, uma pessoa que no call center atende e diz assim,
 "Olha, eu já vi aqui que você andou buscando tal coisa no nosso site,
 você quer que eu te dê mais informações sobre isso?"
 "Puxa vida, é exatamente isso que eu queria e tal."
 Então, evitar aquele tipo de atendimento em que a pessoa te pergunta quem você é,
 qual o seu nome, seu CPF,
 de novo, a cada vez, "Ah, infelizmente não posso te atender,
 vou te passar para o departamento responsável."
 Aí, quando passa para o departamento responsável,
 ele não...
 Dilui de novo os mesmos dados e muitas vezes isso poderia ser desenvolvido no software.
 O software poderia ajudar nisso,
 mas o mais importante mesmo é as pessoas conseguirem perceber e criar essa empatia com o usuário
 e perceber que ele, às vezes, está passando por uma...
 não uma jornada, mas uma romaria do usuário,
 para poder conseguir o que ele precisa fazer.
 Especialistas em experiência do usuário, profissionais de HECU,
 são pessoas que são capazes de pensar e projetar essa experiência como um todo.
 Eles se especializam nisso, entender esses diferentes pontos de contato.
 E tem até uma noção, por eles terem essa visão geral, ampla, holística,
 deles se acharem meio heróis, assim, o ex-hero.
 Existe até uma história em quadrinhos, acredite se quiser,
 dos profissionais se vendo como heróis, salvando os usuários dos pobres programadores
 que fazem mal ao usuário com interfaces horríveis.
 Então, tem essa história aí, tem essa vibe aí.
 Eu já não gosto muito dessa visão de especialista em experiência do usuário
 como uma pessoa especial ou super-herói.
 Eu acho que todas as pessoas têm experiências diversas
 e uma coisa característica do profissional de HECU é que ele busca
 ter mais experiências diversas ainda.
 Ele é uma pessoa de mente aberta, de cabeça aberta.
 Ele quer viajar o mundo.
 Então, eu tive a oportunidade de viajar o mundo e o que eu sou hoje
 é uma soma das experiências que eu trouxe dessas outras experiências.
 O que eu consigo lembrar, o que eu consigo transformar na minha própria existência.
 E quando eu projeto uma experiência, ou melhor, projeto um software,
 eu também estou aproveitando essa experiência.
 E quanto mais experiências diferentes eu tenho, mais eu consigo entender
 e projetar para outras pessoas diferentes.
 Então, essa diversidade da minha vida pessoal, da minha experiência pessoal,
 também se inflete na diversidade daquilo que eu proporciono no que eu projeto.
 Então, fica uma dica que não tem a ver explicitamente com o processo
 de desenvolvimento do software, mas tem a ver com a vida.
 Enfim, volta o parênteses aqui.
 As especialistas em experiência do usuário, eles precisam colaborar.
 Porque cada pessoa tem experiência.
 Não são só os especialistas em experiência do usuário que tem experiências diversas.
 Todo mundo tem.
 E, às vezes, tem gente que não é especialista em experiência do usuário
 e tem mais experiência que um profissional de UX.
 Então, por isso, as pessoas precisam colaborar.
 Só que, muitas vezes, cada um está olhando só para a sua especialidade,
 só para o seu departamento, a sua função, a sua responsabilidade dentro da organização.
 E a fala é um recurso muito ilimitado para permitir visualizar esse todo.
 Por isso que no design a gente desenvolveu da linguagem escrita.
 No caso da engenharia de software, existe um foco muito grande
 nesse documento famigerado "Especificação de Requisitos",
 que é um documento normalmente dezenas e dezenas de páginas.
 [Personagem respondendo]
 É, obrigado.
 Às vezes, chegando aos milhares, né?
 [Risos]
 É aquele documento que demora meses e meses e meses para elaborar
 e que no final ninguém lê.
 Nunca é utilizado.
 Mas, pelo menos, algum gestor fica tranquilo,
 que se alguém perguntar ao chefe dele, está aqui a especificação de requisitos.
 Se por acaso houver uma quebra contratual, algum problema legal,
 está aqui a especificação de requisitos.
 Ele é um tipo de ferramenta para você utilizar em caso de,
 "just in case", eu vou ter, né?
 Mas, no fundo, não contribui muito para criar, para visualizar o todo.
 Ele só representa as partes do software.
 Quando a gente quer representar o todo, a gente precisa buscar outras ferramentas.
 E no design, e na arte, e na arquitetura,
 eu busquei ao longo dos anos várias ferramentas que eu chamo de expansivas,
 que ajudam a expandir essa visão da parte para o todo.
 A primeira delas, a mais simples, mais fácil de usar,
 e mais efetiva, é o mood board, painel semântico.
 Então, quando você está pensando em uma experiência
 que você quer proporcionar, que você quer possibilitar com o software,
 antes de pensar no software, pense nessa experiência,
 mas não pensa, materializa.
 Você pode materializar isso muito facilmente
 utilizando um painel com colagem de fotos.
 Então, existe até software na web que você digita lá o que você quer juntar,
 e ele vai montando isso aqui para você.
 Mas, pode fazer manualmente também, pode imprimir, pode fazer colagem,
 pode fazer imagem recortada de revista,
 que é como antigamente se fazia esse método, o painel semântico.
 E isso aqui é um dos primeiros exercícios que se faz na faculdade de design,
 para você ter essa visão geral.
 Cada foto representa uma emoção, um sentimento, um impacto, um conceito, uma ideia.
 Você pode organizar elas assim de maneira meio caótica,
 porque você está em uma fase inicial considerando possibilidades.
 Não quer dizer que você vai fazer o que está em uma foto ou duas fotos.
 Você vai tentar pegar o que está entre as fotos.
 Né, no interstício, que é esse negócio, essa qualidade sem nome,
 essa coisa a mais que é difícil de definir.
 Tem uma maneira mais objetiva de fazer isso, que é usando palavras-chave.
 Mesma coisa, só que cada pessoa participa do projeto.
 Isso aqui é mais legal de fazer em grupo, né,
 porque às vezes escolher uma foto é difícil,
 uma pessoa que não tem, por exemplo, um background de fotografia,
 não está pensando visualmente, mas escrever uma palavra é fácil.
 E aí você bota um painel de palavras-chave na parede.
 É claro que você perde com isso a conexão entre as coisas que a foto traz, né.
 Veja que as palavras, elas estão próximas, não tem nenhuma ligação semântica,
 porque é bem difícil fazer ligação semântica entre palavras.
 Mas é muito fácil fazer ligação visual entre fotos,
 porque as fotos, você olha, né, você já vê que essa foto tem uma tonalidade parecida com essa foto,
 por isso que está aqui, né.
 Você tem um... todas essas fotos obedecem a um certo padrão de tonalidade,
 os pastéis, calmas, né, simplicidade, limpeza, tudo isso está aparecendo nessas fotos.
 E é muito óbvio isso.
 Agora, não é tão óbvio que, por exemplo, engajamento tem a ver com software livre,
 ou com ampliar a democracia, né.
 Então, nem todas essas coisas se conectam tão facilmente.
 Ou o governo... conhecer e opinar tem a ver com diálogo, né.
 Hoje em dia, nós estamos vendo aí que tem muito conhecer e opinar que não tem nada a ver com diálogo, né.
 É bem destrutivo mesmo.
 Enfim, é uma ferramenta que eu tenho usado bastante com os nossos estudantes aqui na PUC,
 experimentado bastante, é o teatro projetual que a Anny pôde participar, né.
 Estava nesse dia, né Anny.
 Se você quiser explicar um pouquinho o que a gente fez aí.
 A gente tinha que explicar...
 A gente tinha que explicar a situação do usuário por forma de um vídeo.
 Por exemplo, a gente queria mostrar a dificuldade da pessoa, acho que não enxergar, né.
 Não, era um idoso, um idoso que não... que tinha restrições, tinha uma demência, né.
 Aí ele não entendia muitas coisas, ele não esquecia, né.
 E aí o óculos era uma espécie de amplificador da capacidade cognitiva dele.
 Ele identificava os objetos, as pessoas.
 Ele esquecia o nome, né.
 Eu lembro que você era a netinha e ele era o vovô.
 Aí a netinha ia lá "Oi vovô, ooooh, você..."
 O nome dela é Anny.
 "Oi Anny, minha netinha querida, né."
 Não era isso?
 Não era isso, daí no vídeo a gente tentava mostrar como ia funcionar aquele aparelho que a gente criou.
 Pra ele enxergar e lembrar das coisas também.
 Então, aí eles imaginaram com teatro...
 É teatro misturado com filme, né.
 Porque eles estão improvisando, eles não têm script.
 Estão imaginando a sequência enquanto a gente está filmando.
 Que no caso eles estão imaginando uma situação que o vovô vai comer numa festa e o vovô tem diabetes, né.
 Então ele não pode comer qualquer coisa.
 Ele vai botar uma comida na boca.
 "Não, não, não, esse alimento não vai te fazer bem, não coma, né."
 Protege ali o vovô.
 Deu um problema.
 Ele tinha que comprar pão também e ele tinha um GPS no aparelho que ia falando como é que ele ia até a padaria e mandava pra casa pra ele se perder.
 Então essas ideias não foram desenvolvidas antes de fazer o teatro.
 O teatro ajudou a desenvolver as ideias.
 Tem um artigo que eu e o professor Gonzato aqui da PUC publicamos no IHC em 2016
 que conta como é que a gente usa teatro como uma ferramenta de projetar interações.
 O design baseado nos cenários é uma inspiração conceitual bem mais antiga do que o uso do teatro, né.
 Mas é parecido porque no design baseado nos cenários você pensa, imagina essas interações com o usuário
 só que originalmente você escreve elas e faz parte às vezes até da sua especificação de requisitos.
 A técnica de cenários também é documentação.
 Eu acho muito chato escrever, acho que nem todo mundo tem a capacidade de escrever literário assim, de criar com palavras.
 Mas a maioria das pessoas tem a capacidade de criar com bonequinhos.
 Todo mundo brincou de bonequinho quando era criança.
 Então você puxa por essa memória de contar a história com bonequinhos
 quando você propõe uma atividade como essa que eu chamo de cenário lúdico.
 Que é uma adaptação da técnica original do design baseado nos cenários, do Carol,
 para o propósito de imaginar interações com aplicativos.
 Aqui tem um cenário bem legal que os estudantes pensaram no conceito de um aplicativo
 que serve para o chamado Art Backup.
 Então no Art Backup a menininha vai para o museu,
 aí no museu ela puxa o smartphone dela e ela tira as fotos das obras.
 E cada vez que ela tira uma foto de uma obra, ela ganha dinheiro.
 Ela vai ganhando um créditozinho porque vai ter o backup lá.
 E depois que aconteceu um desastre e destruiu o museu, e pegar fogo o museu,
 aí a empresa que era dona do smartphone vai vender para o museu essas fotos.
 E aí essa usuária que tirou as fotos do museu, que ripou o museu,
 vai ganhar um dinheirinho e pode comprar um trator para ir embora.
 Melhor do que chegou com uma bicicleta e tal.
 É uma história bem engraçadinha, mas que explica esse conceito do backup da arte.
 O meu colega professor Gonzato e mais um outro colega aqui da PUC também,
 professor Glaucio Moura, a gente publicou, ou melhor, não publicamos ainda,
 porque ainda vamos apresentar semana que vem no IHC deste ano,
 um artigo só sobre vídeos improvisados.
 Esse exemplo que eu dei do cenário lúdico é um tipo,
 a gente tem mais oito tipos de vídeos improvisados.
 E aqui eu estou mostrando outro que é o Mágico de Oz.
 No Mágico de Oz você tem um estudante atuando como computador,
 e aí as interfaces são feitas de papel, são feitas de...
 Eu vou mostrar um vídeo que eu acho que uma parte do vídeo...
 Se vocês quiserem assistir no meu blog, lá no Zabidi Doido no YouTube,
 tem disponível, tá?
 Essa apresentação também já está online, eu estou vendo ela online.
 Enfim, o que acontece depois de você trabalhar com esses vários formatos de criação?
 Começa a vir uma complexidade muito grande.
 Naturalmente, as equipes começam a...
 Espera aí, espera aí, espera aí, vamos organizar a casa, né?
 E aí começam a estruturar uma visão completa da interação e da experiência
 utilizando diagramas.
 Então, lá na Apple Developer Academy nós temos várias paredes desenháveis,
 todas as paredes são de vidro.
 E isso aqui é um momento de uma equipe que está tentando estruturar
 e chegar à conclusão, chegar a um consenso, melhor dizendo,
 qual seria a estrutura mínima desse aplicativo que eles estão construindo,
 esse jogo, na verdade, né?
 Então, aos poucos, vai sedimentando essas estruturas.
 Esse processo criativo é caótico, mas ele tem também junto um processo
 de sedimentação que vai levando a uma redução da experiência ao software.
 Uma maneira bem radical de reduzir a experiência,
 que eu particularmente não gosto de fazer logo no começo,
 mas muita gente que trabalha nessa área faz isso logo no começo,
 é trabalhar com experiência linear, passo a passo.
 Isso é chamado, às vezes, Service Blueprint, Experience Map, User Journey.
 Basicamente, você coloca o Swimlane também, você coloca umas raias aqui,
 que são equivalentes a uma linha temporal, linha do tempo.
 Aqui na primeira linha, você coloca as ações que o usuário vai ter
 na sua experiência.
 Embaixo, você coloca qual ponto de contato que ele vai ter.
 Então, no caso aqui, pode ser o software, depois pode ser call center,
 depois pode ser pessoalmente, com produto.
 Aí, você começa a colocar que ações que o seu software vai fazer
 ou que ações que um funcionário da sua empresa vai ter que fazer.
 Aí, você vai colocando numa linha.
 Qual que é o problema da linearização da experiência?
 Nem sempre a pessoa vai seguir essa linha inteira.
 Às vezes, vai ter desvios, vai ter voltas da pessoa voltar a refazer,
 vai ter abandono.
 Isso não fica visível nesse formato.
 É claro que ele é interessante para pensar a tal da experiência ideal,
 que a gente falou lá no começo.
 Mas, ele não é interessante para pensar a experiência real,
 a experiência emergente.
 A maneira mais simples mesmo de pensar e mais redutiva também
 de pensar a experiência do usuário é o esboço de telas.
 A gente lutou muito para conseguir chegar no nível em que,
 hoje, vários profissionais da área trabalham realmente com esboçando interface.
 Os outros ferramentas que eu mostrei expansivas são quase,
 são pouco utilizadas ainda, com exceção dessa aqui que eu estou mostrando,
 que é muito utilizada hoje no mercado.
 Que é chamado protótipo de papel, sketch, esboço, rascunho, croquis, whatever.
 Que é você junto com uma outra pessoa ou sozinho esboçar possibilidades
 que essa interface poderia ter.
 Aqui nós estamos discutindo uma interface de votação.
 Como é que seria ela?
 O problema é que, normalmente, você consegue desenhar interface,
 mas você não consegue desenhar experiência.
 Então, é uma coisa diferente interface e experiência.
 E você pressupor que a interface controla a experiência,
 que é o que normalmente as pessoas fazem quando fazem esboço,
 pode haver algum tipo de negligência, de vocês não verem alguma coisa.
 Pensando nisso, aqui na PUC nós começamos a desenvolver uma plataforma,
 como eu falei, o Copel+.
 A Erika pôde participar também desse processo.
 A gente teve alguns esboços de tela,
 só que aí a gente falou, "Puxa, não estamos entendendo direito.
 Vamos tentar entender o que realmente está por trás desse esboço de tela".
 E aí a gente puxou o Lego, a caixa de Lego,
 e começou a inventar um método para...
 Na verdade, esse método já tinha sido criado,
 um protótipo dele lá na Apple Developer Academy.
 Mas, com o tempo, a gente ficou guardado na gaveta
 e aqui a gente teve a oportunidade de utilizar
 e continuar o desenvolvimento desse método,
 que a gente está chamando de Lego ML, ou Lego ML,
 ou Lego Modeling Language,
 que a gente combina alguns formalismos da ML,
 como, por exemplo, o diagrama de casos de uso,
 com diagramas de interação que a gente vê dentro da experiência do usuário.
 Então, aqui eu vou mostrar para vocês um trecho de um vídeo
 em que a gente tem uma sessão de discussão com os arquitetos,
 os designers, programadores e clientes,
 no caso, a Erika estava representando o cliente nesse caso.
 E aí vocês podem ver que a discussão de arquitetura,
 o propósito principal de discutir a arquitetura do software,
 ela é o tempo todo permeada por discussões sobre
 o impacto dessa arquitetura na qualidade da experiência do usuário.
 A gente está desenvolvendo ainda essa linguagem,
 esse formalismo, ou informalismo,
 então não dá para a gente aplicar como exercício aqui com vocês,
 que a gente não tem muito ainda estável.
 Mas, obviamente, se vocês quiserem ajudar a gente a desenvolver
 e fazer experimentos com Lego, nós super apoiamos e queremos colaborar.
 Diga.
 Então, Edu, eu vou contando com vocês,
 essa questão de participar de experimentos,
 se precisarem de parceiros,
 coloca essa posição e leva lá isso para Minas e sabe.
 Eu só queria ouvir a Erika,
 você que participou como cliente do processo ali,
 a gente estava em uma fase que a gente estava vendo esses formalismos oficiais,
 o Rodolfo que está aparecendo, não apareceu no vídeo ali,
 mas ele tinha criado os diagramas de UML mesmo
 e ele veio apresentar para ela, para nós.
 O que aconteceu?
 Na verdade, além de ser cliente, eu não sou da área de documento.
 Como normalmente os clientes são, né?
 É, normal.
 Então, assim, do ponto de vista de quem adquirir,
 quando a gente foi montando a ideia do software,
 ficou uma coisa assim, na minha cabeça estava,
 "nossa, vai ser assim".
 Na cabeça do Rodolfo, do Lino também estava meio, né,
 cada um com a ideia.
 Quando o Rodolfo veio, aquele monte de papel e documento,
 começou a falar, tem um monte de palavras,
 então, os técnicos estavam falando,
 eu comecei a ficar perdida, falando,
 "Meu Deus do céu, será que eu não entendi?"
 Ou se eles estão concordando, para onde eles estão indo?
 E aí tinha o Guilherme também usando o termo de engenharia,
 falando, "nossa, tá dando".
 E a gente fala disso no vídeo depois.
 Sim, é da linguagem comum, né, de quem está ali.
 Então, para o cliente ouvir aquilo, você fica assim,
 "não, espera lá, acho que eu não entendi o que eles estão falando".
 E são palavras que, se você tirar daquele contexto para o outro,
 ele tem um outro entendimento.
 São palavras comuns, assim, não é uma coisa diferente.
 Aí o Fred veio com o Lego e falou,
 "não, vamos colocar no Lego para esclarecer, nossa".
 Aí ficou comum, parece que está todo mundo falando a mesma linguagem.
 Mesmo com a tela, porque ele trouxe o papel, a telinha,
 e explicando.
 Tinha um momento ali que empacava,
 que eu falava, "deixa ele falar que eu acho que de uma hora eu entendi".
 [Risos]
 Aí deixamos, né.
 Então, o Lego, ele cria uma linguagem física, né,
 até meio manipulável, né.
 Como eu falei, é difícil, às vezes, colocar em palavras a qualidade,
 a qualidade sem nome, mas você consegue sentir quando você está lá.
 Então, o Lego, ele ajuda a sentir.
 E não só o Lego, como várias outras ferramentas
 que têm essa característica física.
 Por isso que eu não vou recomendar uma dessas ferramentas.
 Eu vou recomendar todas e mais algumas outras que você tiver,
 mas coloque elas no mesmo local.
 A minha recomendação é, use o espaço físico
 como a maneira da pessoa entrar dentro desse espaço físico
 e ter uma experiência projetada de estar dentro do software.
 Como se o software fosse um espaço de possibilidades.
 Eu sei que é abstrato isso, mas na prática, olha só,
 isso aqui é uma sala que a gente utilizou para fazer uma design sprint
 para desenvolver um software.
 Cada documento, cada dinâmica que a gente usava,
 cada jogo, cada ferramenta expansiva,
 o resultado ia para a parede, ia para a parede, ia para a parede.
 Para quê?
 Quando a gente estivesse revendo a experiência do usuário
 numa outra ferramenta, a gente olharia.
 "Não, não, espera aí, a gente fez isso aqui diferente aqui, olha aqui."
 "Ah, é mesmo, estou me esquecendo, isso aqui é importante."
 Porque, como é uma coisa abstrata,
 facilmente as pessoas perdem o fio da meada.
 Mas quando elas estão fisicamente rodeadas dessas informações
 e podem reconstruir, reviver aquelas experiências com esses documentos,
 as experiências projetadas podem ser re-encenadas,
 você consegue um processo de construção de consenso
 e evita esse tipo de problema que a Erika falou,
 de as pessoas não entenderem o que o outro está falando.
 Por quê?
 Porque um espaço de possibilidades e o outro está em outro.
 Mas quando você cria um espaço comum,
 como uma sala bagunçada como essa, e é de propósito,
 ela é bagunçada para representar o processo caótico
 inicial de exploração das possibilidades de experiência,
 que aí você consegue ter o que a gente chama de ateliê de projetos.
 E a Apple Developer Academy é um pouquinho mais organizada do que isso,
 mas os alunos, uma das grandes vantagens é que eles têm a liberdade
 de customizar o espaço, para desenhar nas paredes, para organizar,
 para sentar, para deitar, para fazer o que quiser.
 Não tudo, mas ficar, o projeto fica no mesmo lugar.
 Acho que isso é uma das grandes vantagens que a gente tem lá.
 Todo dia eles vão para, entre parênteses, aula, não é aula,
 porque é desenvolvimento de projeto, e eles reencontram esse mesmo ambiente.
 Então, quando eu volto para esse ambiente,
 eu já me reconecto a todas as experiências projetadas
 que a minha equipe teve, e posso continuar dali em diante.
 Se eu tiver que reconstruir aquilo na cabeça, ou a partir do que eu estou vendo
 no software, dentro de um aplicativo, não, pode ter lá no Asana, no Jira,
 o software que você utiliza para gerenciar documentos,
 e ter essa visão geral do software.
 Não tem a mesma efetividade que você ter isso pregado na parede.
 [inaudível]
 Isso aqui que a gente está vendo, no caso da engenharia de software profissional,
 que é o caso de muitas empresas ligadas ao governo,
 também é o meu trabalho, que é desenvolvimento clássico.
 Mesmo que a gente tenha que trazer desenvolvedores da Rádio Agência
 para dentro dessas empresas, é muito difícil você usar na sua eficiência.
 Enfim, o que eu estou querendo dizer é que, geralmente, a gente tem
 o análise de requisitos, fazendo a computadora do requisito,
 fazendo a especificação desse requisito, passando por um implementador,
 ele vai lá, implementa, e depois alguém testa, enfim, quanto quer.
 Mas, enfim, eu estou querendo dizer que haveria, então,
 haver um design de experiência do usuário dentro dessa equipe,
 ou é um análise de requisito, deveria atuar nisso, se especializar, fazer esse papel?
 Essa pergunta não tem uma resposta padrão para todas as ocasiões.
 Cada organização vai ter uma estratégia que vai funcionar melhor.
 O fato é que experiência do usuário, enquanto um resultado almejado,
 não se alcança se não houver uma mudança totalmente da cultura.
 E essa mudança cultural pode vir por entrar uma pessoa ali dentro
 que se torna uma pessoa entusiasta de mudança, convence várias pessoas,
 ela se torna um centro das atrações, de repente junta uma equipe,
 daí cresce, e aquilo espalha. Isso é um caso raro, muito raro.
 A maior parte dos casos vai acontecer essa mudança quando houver um concorrente
 que começar a ganhar clientes porque tem esse diferencial.
 Aí a empresa mais, normalmente esse concorrente já nasceu com a experiência do usuário
 como sendo uma prioridade, e aí a empresa antiga vai ter que se atualizar.
 Às vezes vem também por uma norma oficial do governo, também pode ser o caso.
 Tem N caminhos diferentes. Você quer falar, Zabutinho?
 Eu vou aproveitar o caso da minha empresa lá. Por lá a gente não precisa identificar pessoas
 que tinham afinco com as questões de identificar quem eram mais da partilhar de negócios,
 ou da lista de requisitos, mas que tinham um afinco maior em tentar entender
 as necessidades do usuário, mas que já tinham uma proximidade maior com isso,
 a gente está possibilitando treinamento deles para que eles se aproximem mais
 das técnicas dos clientes e dos usuários. Então a gente tem um grupo de facilitadores,
 nós chamamos lá, são 10 pessoas, e toda semana nós temos um encontro semanal
 de uma hora, e que eu mostro para eles técnicas, provém algumas dinâmicas,
 e eu vou treinando eles, que aos poucos eles vão disseminando dentro dos trabalhos
 as técnicas. Eu sei que eles não vão fazer com criação já no automático,
 eu sei que eles não vão sair do zero, UXers, ou Extrus do zero, da noite para o dia,
 mas já no dimensionamento hoje dos projetos, eles já conseguem fazer,
 ao invés de users e stories direto, ou as coisas bem requisitos, levantadas,
 eles já conseguem fazer uma entrevista mais natural com os clientes,
 conseguem tirar umas coisas mais empáticas com as pessoas, não é aquela coisa
 então tipo, "ah, o que você quer dizer?" "ah, isso". Aí vai lá depois, vai ao comercial,
 depois vai na lista de negócio, depois vai na lista de requisitos.
 Entendi. Então, na verdade, isso vem para a proposta, é uma substituição,
 não complementação das práticas e métricos que a gente tem.
 Exatamente. Eu acho que muda o processo, muda a organização, muda a cultura.
 Agora, a porta de entrada, como vai começar, é variada. Por exemplo, na Coppel,
 estamos discutindo inovação, não estamos discutindo experiências usadas naquele projeto,
 mas a estrutura organizacional que a gente está criando ali,
 ela é propensa para que se pense sobre isso mais para frente.
 Então, é um caminho que a gente entrou ali, digamos, na mudança organizacional.
 Em outra empresa, é outro caminho. A gente tem que descobrir...
 Qual o caminho daquele lugar...
 Quem são as pessoas que a gente consegue, basicamente, a principal coisa,
 pessoas que transformam organizações. Então, você tem que encontrar outras pessoas
 que também consigam ver valor nesse tipo de trabalho.
 Aí, você vai conquistando e vai crescendo o movimento até que você tem uma oficialização.
 Mas, primeiro, tem que ter um movimento.
 Sim, agora, é importante considerar ainda a questão das gerações também.
 Ah, com certeza.
 Eu tenho examinado os setores que têm gerações mais antigas, que não tiveram, por exemplo,
 ninguém brincou com o lego. Então, aquilo não tem significado para ele.
 Ele não consegue entender aquela pecinha para que ela serve naquele contexto.
 E aí, depois, você tem gerações que brincaram com o lego.
 E hoje, você começa a ter gerações que já nascem com o celular touch na mão
 e o lego para ele, para esse de hoje também, essa criança atual,
 talvez ela não vá usar também. Então, quem vai ser o usuário do futuro?
 Será que há 10 anos, por exemplo? Entendeu?
 Então, tem isso também, essa questão da geração. O que a geração tem experiência em quê?
 Qual o conhecimento dela?
 Posso ponderar só um pouquinho?
 Eu estou em uma empresa que tem gente de muito tempo de casa.
 A Copela tem gente de 40 anos.
 Saí uma senhora que tem 44 anos de vida.
 A Copela é uma CNG elétrica aqui.
 Sim, eu tenho 52.
 E aí, assim, a gente aplicou.
 O crédito foi lá, aplicava em todo dia junto com o lego e abriu para a galera.
 Quem quer participar?
 E teve muita gente de tempos de empresa que quis experimentar.
 Eu acho assim, não é a questão do lúdico.
 A ferramenta lúdico, usar o lúdico, que é o caso do post-it,
 é usar o... mexer com as coisas, brincar um pouco, isso é natural do ser humano.
 Todo mundo já brincou alguma vez, seja com o lego ou não.
 E também acho que não tem a ver bem com geração.
 Eu acho que o mais difícil é você tirar aquela capa de que eu tenho que ser sério.
 Tudo tem que ser muito sério, tudo tem que ser muito daquele jeito.
 Porque se eu consigo construir brincando, conversando, dando risada,
 e aquilo ainda botar um resultado, não me importa muito bem como eu faço.
 Eu vejo que a resistência maior lá, pelo menos, é essa.
 "Ah, se eu quiser isso, vamos tirar a capa de ser serio."
 [Risos]
 Porque assim, fica aquela sensação de que,
 "Ah, então quer dizer que eu não sou profissional suficiente,
 quer dizer que não vou me respeitar mais."
 Eu acho que essa é a pior barreira, essa não é a difícil.
 É o que a gente mais enfrenta ali.
 Porque quem estava perto foi, sabe assim,
 brotou coisas legais pra mim pra todo mundo.
 Mas voltando aqui, essa discussão é longa.
 É um outro tema também, que é a mudança organizacional.
 Aqui eu estou falando mais, dando um "un passant"
 e explicando especificamente a relação entre software e qualidade do usuário.
 Mas depois a gente pode pensar nisso pra um futuro minicurso.
 Eu vou ter que pular esse exercício, porque a gente não vai ter mais tempo.
 Mas tudo bem, a gente faz um fechamento aqui.
 Se vocês tem os vídeos, vocês podem realizar esse exercício com o Lego e tal, por aí.
 Não, pera aí, vamos fazer um exercício com o Lego, né?
 [Risos]
 Fala, fala, fala do Lego.
 Tem ainda mais um pouquinho de tempo aqui, tem mais...
 [Barulho de conversa]
 Parabéns de... e cadê a pessoa que tá assistindo?
 É o esquerdoso, ó.
 [Risos]
 Tá, essa aqui vai ser nossa plataforma, então.
 [Barulho de conversa]
 Tá acabando o tempo.
 [Barulho de conversa]
 Tá, tá chegando.
 [Risos]
 [Barulho de conversa]
 Vamos lá, acabou o tempo aí.
 Acabou, acabou?
 [Barulho de conversa]
 Vamos apresentar?
 [Barulho de conversa]
 Podemos apresentar?
 [Barulho de conversa]
 Meu Deus, ninguém mais me ouve aqui.
 [Risos]
 Tô tão brincando agora.
 [Barulho de conversa]
 Acabou, acabou, acabou.
 Quem quer apresentar primeiro?
 Quem quer apresentar primeiro?
 Hein?
 Vocês?
 Tá, aqui?
 Pessoal, na apresentação, todo mundo tem que se levantar e vir aqui, hein?
 Venham ver a apresentação.
 [Barulho de conversa]
 A designer, né?
 [Risos]
 É, não dá nada, né?
 [Barulho de conversa]
 Então, quando a pessoa separa o lixo, né?
 Aí é feita a coleta do lixo e tal.
 [Barulho de conversa]
 E aí a pontuação do colorido vai crescendo.
 E aí a pessoa que coleta o lixo individualmente, ela ganha uma bonificação também, uma identificação.
 Tipo, ó, essa pessoa tá ajudando na coleta.
 Então, isso, e aí...
 [Barulho de conversa]
 É o acesso de pertencimento, né?
 Que é a questão do coletivo, do condomínio, né?
 A self-respect também, quando a pessoa ajuda, ela ganha esse conhecimento não só por meio do lixo, mas por meio do lixo individual também.
 E amizade também, que você consegue se conectar com o seu lixo individual também.
 [Aplausos]
 Vamos aqui desse lado?
 [Barulho de conversa]
 Então, a ideia é, tipo, um aplicativo que a pessoa possa escolher os lugares, parques, com opções que ela gostaria de ter nesses parques.
 Tipo, ah, ela quer um parque que tenha algum tipo de espécie, tipo, que dê pra descobrir qual árvore que é.
 Ou então, ela quer um parque que tenha animais e que é um parque que ela tenha...
 Curação.
 É, que tenha acessibilidade pro amigo e companheiro.
 E também, é um aplicativo pra ela se encontrar com os amigos dentro de parques, assim, que tenham essas opções.
 É, e a ideia do semáforo foi finalizar se, quando ela escolhesse algo, se tava ok, médio, atendendo médio.
 A necessidade.
 A necessidade, é. Ou se pode ir pra tal lugar.
 Ela poderia ir.
 [Aplausos]
 Vamos lá, ali no meio. Vamos lá.
 Ô, louco.
 Surreal.
 E aí?
 Tá.
 É, nosso aplicativo, basicamente, ele poderia tratar de honra aos idosos, moderação pra evitar pessoas que se disputem ou tem ações contra a própria vida e curiosidade.
 Então, a gente trata de um sistema que, basicamente, respeitaria os idosos, fazendo com que suas histórias de vida fossem tratadas como testemunhos de que a vida vale a pena.
 Que fossem levadas a esses jovens, que poderiam dar algum tipo de nota a essas histórias.
 E conforme essas histórias recebissem as notas, elas iam se despertar, iam se dividir no aplicativo, né, lá, no rating do aplicativo.
 Iam acabar vindo cards que iam chegar ao conhecimento geral da situação e ganhar mais notas.
 E conforme elas foram ganhando notas, as pessoas poderiam dar pequenos tips.
 Corjetas.
 Corjetas.
 Corjetas.
 Corjetas.
 E ganhar pequenos valores pra elas e reta alimentar o sistema como um meio de moderação pra que esses dinheiros alimentassem a ONG e pudesse voltar pra outras ONGs que mantém os idosos que escrevem as histórias.
 [Aplausos]
 Ó, vamos lá aqui.
 [Aplausos]
 [Inaudível]
 Quando ele fosse escrever alguma coisa, que fosse uma coisa meio ruim, ele ia dizer "Ó, colega, tá infringindo uma lei, não é legal você escrever isso, vai baixar o...
 Você vai responder algum processo ou não, isso aí tá ok, vai sair..."
 Você tem certeza mesmo que você quer mandar essa mensagem misógina, fascista?
 Você vai ser responsabilizado por isso, se quiser. Mas mesmo se você quiser fazer, a introdução é de voltar e pedir perdão.
 [Risos]
 Nossa, muito boa!
 Botãozinho do perdão.
 [Risos]
 Essa ideia é muito boa, né?
 [Aplausos]
 Vamos demandar pro Facebook essa daí, ó.
 [Risos]
 O que é o botãozinho do perdão, hein?
 [Risos]
 Vem pra cá, vem, vem.
 [Inaudível]
 É envolvendo os riscos, a espiritualidade, né, que seria o fator humano, o fator dos riscos, né, que seria o técnico, a gente botou o cara com a arma, e esse daqui é mais, é tipo, ele...
 [Inaudível]
 Olha só, é isso aí.
 [Aplausos]
 Ótimo, valeu a pena.
 [Risos]
 Ficar de lega é...
 O legal do Lega, é que é uma técnica muito rápida de explicar.
 Eu prefiro que não demorou nem um minuto pra explicar como se comunicar com o Lego.
 Eu sei que, eu concordo com a colega ali que realmente não é todo mundo que consegue se dar bem com o Lego Series Play, mas é sempre um desafio, como vários outros que existem dentro do nosso dia a dia, né.
 Vamos então fazer um fechamento aqui, conceitual.
 [Silêncio]
 Então essa prática que a gente fez em várias ferramentas, várias técnicas hoje durante a oficina, eu descrevo muito bem na minha tese de doutorado, se chama design expansivo, é você sempre colocar mais no projeto.
 Não, não, não, não vamos fechar os copos, não bota mais, põe mais, põe, põe, pode pôr, traz mais pessoas pra participar, traz mais qualidades da experiência do usuário.
 Não tem problema, vamos botar, encruçar o caldo.
 É claro que isso gera um caos e chega uma hora que se torna inviável, né, você não consegue mais acrescentar.
 E aí naturalmente as pessoas vão começar a reclamar, ficar cansadas e vão acabar reduzindo.
 Então eu também descrevo dentro da minha tese de doutorado a prática oposta do design redutivo.
 E eu não digo que design expansivo ele é melhor do que o redutivo, eu digo que ele é necessário e que muitas vezes as empresas passam direto pro redutivo sem ter essa fase de expansão, de ampliação do espaço de possibilidades.
 Elas vão direto ao que é muito provável e às vezes nem o provável, mas somente o que era necessário, sem considerar se aquele necessário é necessário de fato pra outra pessoa, no caso o usuário.
 Então agora eu vou pular essa discussão sobre protótipos, depois se vocês quiserem ver.
 E vou fechar com métodos para avaliar qualidades da experiência do usuário.
 Eu vou passar aqui quatro métodos que são alguns conhecidos, outros nem tanto.
 Mas eu acho que existe uma demanda muito grande para novos métodos para avaliação das qualidades da experiência do usuário do jeito que eu estou apresentando aqui.
 Porque não existem muitos.
 O mais conhecido é o teste de usabilidade.
 Quando eu estava trabalhando com a mídia digital que hoje se chama Mirum, aqui em Curitiba, eu ajudei a fundar o laboratório de usabilidade deles.
 A demanda do cliente não era se o site estava usável, a demanda era se os clientes gostavam do site.
 E a gente criou uma variedade do teste de usabilidade que a gente chamou de teste de gostabilidade.
 A gente perguntava em vários momentos do teste, você gostou da experiência que você teve?
 A cada tarefa, a gente perguntava, você gostou? Você está gostando disso?
 E essa opinião impactava muito mais a decisão dos clientes dessa empresa do que se perguntasse se tinha taxa de eficácia.
 Porque muitos dos clientes visavam com seus websites, interfaces, um efeito de marketing.
 A gente usava também uma técnica chamada cartões de reações, que foi criada pelos pesquisadores da Microsoft, o Excel Search de lá.
 Que basicamente é você, depois do término do teste de usabilidade, coloca um monte de cartinhas com algumas qualidades da experiência do usuário.
 Inclusive no paper tem, nesse paper aqui tem todas essas qualidades.
 Impressas, aí o usuário escolhe cinco que ele acha que tem a ver com a experiência e descreve por que.
 Uma ferramenta muito boa para estimular o usuário a dar um feedback mais de qualidade.
 Porque as vezes o usuário, você fala, como foi a sua experiência? Você está satisfeito?
 Que é uma pergunta bem padrão, assim de debriefing depois do teste de usabilidade.
 As pessoas não sabem explicar porque elas não tem o tal do vocabulário.
 Faltam ali as palavras.
 Isso aqui foi um dos primeiros experimentos que eu fiz, que deu para ver que precisava ter esse tipo de estimulação.
 Depois isso evoluiu para a utilização de massa de modelar.
 Então como eu já comentei para vocês anteriormente, a gente usou isso para avaliar as reações emocionais,
 as experiências que os usuários tinham tido com o refrigerador com touchscreen.
 Então aqui tem uma variedade de emoções, de histórias.
 E uma outra ferramenta, já menos conhecida, chamada sondas tecnológicas,
 você manda o protótipo para a casa do usuário e o usuário fica com esse protótipo lá.
 Na verdade é uma sonda, porque ele fica lá recebendo feedback.
 Então as pessoas ficam interagindo com aquele artefato como se ele fosse o produto real,
 imaginando situações em que eles usariam.
 Aqui no caso, um estudante estava explorando como é que seria um smartphone integrado com laptop e media center.
 O smartphone seria a CPU de todos esses dispositivos.
 Então você grudaria o smartphone dentro do laptop quando você fosse utilizar,
 tiraria e colocaria dentro do media center e em outros dispositivos.
 Ele fez esse protótipo de madeira, mandou para a casa de uma família e botou um monte de post-it em volta e falou,
 "Olha, se você tiver alguma ideia para usar esse tipo de integração, anota".
 E essas interfaces foram criadas pela família, não foram criadas por ele.
 E depois, é claro, ele pegou esses dados e criou uma interface oficial, a visão dele.
 Como vocês podem perceber, todos os métodos que eu apresentei para vocês são métodos qualitativos,
 porque eu acredito muito que qualidade se cria com métodos qualitativos.
 Quantidade se cria com métodos quantitativos.
 Utilizar métodos quantitativos para avaliar a qualidade é possível, só que o que acontece?
 Você vai perder alguma qualidade nesse processo.
 A quantidade sempre implica uma redução para dar escala.
 O que faz sentido, é importante e é necessário.
 Mas como eu falei, antes você precisa ter essa fase de criação que ela é qualitativa.
 Isso, olhando para uma perspectiva mais de mercado, também é equivalente ao processo mais global de evolução de uma tecnologia.
 Eu tenho esse modelo que eu desenvolvi há alguns anos atrás, que explica que uma nova tecnologia, ela cria um novo mercado,
 inicia essa competição, essa competição inicial ela é quantitativa, é por escala, é por quantidade de funcionalidades,
 é o máximo de MB pelo mínimo de dólares, mas chega uma hora que fica saturado e você não consegue mais ter um diferencial.
 E aí uma empresa vai lá e propõe um produto completamente diferente, qualitativamente diferente.
 Não só tem mais, ele tem melhor.
 E esse melhor cria um novo mercado.
 Ele amplia o mercado onde vai haver competição pela qualidade, que é o que os smartphones com tela touchscreen,
 a partir do iPhone criou.
 E nessa inovação qualitativa vai ter competição, vai chegar uma hora que fica saturado também,
 e aí vai ter a criação de uma nova tecnologia.
 O que vai vir depois do smartphone, com tela touchscreen?
 Não sei, mas ainda estamos nessa fase de inovação qualitativa.
 Por isso que a experiência do usuário hoje é um termo tão importante no mercado de tecnologia da informação.
 Saber o que reduzir e o que expandir em uma determinada situação de projeto,
 requer o que a gente chama tecnicamente de talento artístico nas disciplinas de projeto.
 São arquitetura, design, artes.
 O Donald Shown tem um livro muito bom sobre educação do profissional reflexivo,
 que está servindo de base para uma dissertação de mestrado da Tânia,
 que é a nossa mestranda do PPGIA.
 Ela está estudando a Apple Developer Academy, inclusive esses meninos, entrevistando eles,
 observando eles trabalhando lá, e vendo como isso se parece,
 tentando justificar e mostrar evidências de que a maneira como eles trabalham
 é muito parecida com a maneira como se trabalha dentro de uma escola de arquitetura,
 uma escola de design, e justificando porque as escolas de computação
 poderiam utilizar esse método de ensino, de aprendizado,
 que se chama ateliê de projetos, que está super fundamentado dentro do design da arquitetura,
 para ensinar a aprender, ou melhor, criar oportunidade para os estudantes
 aprenderem a desenvolver software como uma arte, como uma atividade criativa,
 como uma atividade empreendedora, e por aí vai.
 Então, aqui tem uma foto do lugar onde fica a Apple Developer Academy aqui no campus.
 Infelizmente, não é possível a visitação lá, existe todo um protocolo burocrático da Apple
 para permitir acesso a esse ambiente, mas vocês podem conversar com os colegas,
 que eu acho que é o mais próximo que vocês podem ter agora.
 Se alguém quiser muito lá, a gente pode solicitar a Apple, demora umas semanas,
 às vezes para ter autorização e tal, pode ser que seja negado.
 O que eu venho propor para vocês aqui, como fechamento, é modelagem de software
 que precisa dialogar mais com arte e design.
 Nós temos muito a colaborar, tenho certeza, eu que já transitei em todas essas áreas,
 já vi, transitei em outras áreas também que não estão aí, não sei onde fui parar,
 mas às vezes eu vou nos lugares bem distantes.
 Precisa diálogo porque os desafios complexos que hoje traz a produção de software
 não são desafios intrínsecos do software, são desafios da nossa sociedade,
 porque software hoje não é software, software é sociedade.
 A gente depende quase de tudo na nossa sociedade do software.
 Então, se a gente discutir software como uma coisa isolada, pensar só no nosso métier,
 a gente vai perder todas as relações que trazem essa riqueza
 e que proporcionam qualidades da experiência do usuário únicas.
 Isso aqui é um diagrama do MIT, que é uma das universidades que tem levado bem a sério
 esse tipo de diálogo interdisciplinar.
 Bom, é isso. Muito obrigado.
 [aplausos]