Marcelo Szuster: Bom dia. Boa tarde. Boa noite. Vamos começar aqui mais um episódio dos Agilistas. Hoje nós vamos trazer um tema que eu acho que é extremamente relevante porque ele tem a ver com a geração de valor nos squads. Eu acho que quem acompanha Os Agilistas aí já sabe, a gente não cansa de repetir aqui que as empresas deveriam fazer squads de verdade, squads que a gente chama de rais, que são squads que são orientados a geração de valor e não escopo, são squads que tem autonomia e são squads que têm todas as capacidades necessárias instaladas para que eles possam seu autônomos e por diversos motivos muitas vezes isso não acontece. E aí a gente já falou até em um episódio isso, se não me engano, a gente fala que o squad fica tipo cristalizado, na verdade ele não consegue atingir o potencial dele. Tem várias formas disso não acontecer e uma das formas que isso não acontece, que nós vamos abordar hoje, é não se fazer bem o papel do designer dentro do squad, você não entender bem qual é o papel do designer, que ele é muito amplo do que se imagina e criar o devido espaço para o designer atuar dentro do squad. Então é sobre isso que nós vamos falar hoje e para falar sobre isso, claro, nós trouxemos três designers e aí eu vou pedir para cada um deles se apresentarem. Nós estamos aqui com o Luiz. Tudo bom, Luiz?Luiz Pimenta: Bom dia. Boa tarde. Boa noite, pessoal. Eu sempre quis falar isso. Meu nome é Luiz Pimenta, eu sou designer na DTI e também atuo como PO em um dos nossos projetos aqui, e é muito bacana a gente ter esse espaço para falar sobre a relevância não só da figura do designer, mas como pensamento de designer como um todo, não é? E como ele é crucial na transformação digital, nos ambientes ágeis e nos nossos clientes também.Marcelo Szuster: Bacana demais. Já tem uma primeira coisa interessante aí, designer atuando também como PO.Luiz Pimenta: É, como PO.Júlia: É, a gente vai flertando com esse trabalho também.Marcelo Szuster: Então só… nós estamos com a Júlia também. E aí, Júlia, tudo joia?Júlia: Meu nome é Júlia, eu não sou a Júlia do marketing. Eu trabalho na DTI aqui há algum tempinho como UX design e acho que é muito importante a gente falar tanto da importância do designer e do reconhecimento dos times com relação a isso e também de como o designer consegue se colocar também para esse time, se apresentar, não ser aquele ser quer fica um pouquinho a margem ali na medida que vai desenvolvendo o trabalho.Marcelo Szuster: E também temos aí remoto o Vini, que vai nos brindar com a sua voz de radialista, vai ser o primeiro podcast aqui que vai parecer mais profissional mesmo. Tudo bom, Vini?Vinícius: E aí, tudo bem, pessoal? Beleza. O meu nome é Vinicius, também conhecimento como Vini aí internamente. Também sou designer UX e UI, ou como eu gosto de chamar internamente de designer UXUI. A gente está aqui para conversar um pouco e falar como o mindset também, essa forma de pensar do designer pode também contaminar um pouco as equipes, os squads e até toda a organização.Marcelo Szuster: Não, bom demais. Então eu queria começar primeiro, primeiro nós vamos começar de um jeito ruim e terminar de um jeito bom (inint) [00:03:23]. Vamos começar primeiro com o que pessoal chama de anti (inint) [00:03:27], não é? Quais seriam os anti-padrões? O que é que… quando eu disse que muitas vezes o squad fica limitado ou pela forma que o cliente encara como o designer tem que agir, ou o próprio time, ou não há espaço para o designer, vai desde não entender o papel até não ter hora suficiente, tem todo tipo de questões. Vocês podem tentar clarear mais exatamente o que é isso.Júlia: Eu acho que quando… a principal dificuldade de colocar o designer é porque tem como fazer sem o designer, mas a principal questão e a importância de ter um designer dentro do processo é que quando se tem alguém para debruçar sobre a solução a gente vai ter condições de gerar possíveis soluções que são muito mais adequadas para a necessidade, porque não é que o desenvolvedor, ou o PO, ou quem for, não tem condições de chegar nessa solução, mas é porque não vai ter tempo  para poder se debruçar nesse sentido. Então o desenvolvedor ele vai estar mais alinhado com as questões técnicas, o PO ele vai estar mais alinhado ao negócio e o designer ele tem desafio de estar mais alinhado as condições de uso mesmo. Então quem é que vai entrar em contato, como que é o cenário dessa pessoa, como funciona o contexto, e aí assim, não é fazer a tela bonita, que a gente escuta muito, é fazer dentro de todas as restrições que a gente tem de contexto uma solução que se adequa para esse cenário, então o que exige, acima de tudo, muita comunicação com todo mundo, não é? E aí eu acho que a principal diferença é quando a gente sai, por exemplo, de um design sprint, num cenário feliz, que teve um design sprint, um inception no começo, a gente sabe o que vai ser feito no macro, mas o como vai ser feito ainda tem uma grande distância, a gente tem ali um roadmap geral, mas a gente não tem o detalhamento que vai encaminhar realmente para uma solução de qualidade.Marcelo Szuster: Entendi.Luiz Pimenta: Uma coisa que eu acho interessante desse assunto é que hoje se fala muito em maturidade de design, e é legal perceber, por exemplo, no nosso contexto DTI, que nós temos diversos designer atuando em projetos diferentes e a gente consegue perceber pessoas em diferentes níveis de maturidade. E maturidade vem individual de cada designer e ela vem individual da empresa que o designer está atuando. Então são dois níveis de maturidade diferente que se conflitam para a gente chegar na maturidade ali, uma média de maturidade para aquele contexto. E um dos primeiros níveis de maturidade que se fala muito hoje é o que eles chamam meio de que Lobo Solitário, que é quando uma empresa ela começa a enxergar a necessidade da atuação de um designer, igual a Júlia falou, para emergir dentro do problema, porque parte do designer não é só projetar uma tela bonita, não é só criar uma imagem bonita, mudar as cores do projeto, parte do projeto do trabalho do designer, da atuação do designer está na imersão. E aí quando as empresas começam a perceber o valor do designer elas começam a investir na figura solitária, que eles chamam de Lobo Solitário, que é uma pessoa tentando mudar tudo. Então essa pessoa vai assumir diversos pontos, esse cara vai fazer vídeo, esse cara vai fazer apresentação, esse cara vai fazer proposta comercial, esse cara vai tentar resolver tudo dentro do seu mundinho ali, só que esse cara vai ficar completamente sobrecarregado porque ele não consegue atuar da forma que ele deveria em imergir com o usuário, em realmente entregar valor, em realmente entender qual que é a necessidade do projeto para ele conseguir traduzir isso em valor para o negócio. E aí esse cara passa a ser um lobo tentando mudar todo mundo, até ele conseguir, de fato, pular pelo menos a primeira etapa,  que é passar a ser um evangelizador, que é realmente mudar o mindset da equipe que atua com ele, e aí é quando a gente começa a ter os primeiros passos de maturidade sendo mudados, em que o próprio desenvolvedor começa a se preocupar também com o designer, o PO começa a se preocupar mais com o usuário, em que as pessoas, os stakeholders passam daquelas (inint) [00:07:36] e passam a realmente entender o lado do usuário. Então o lado que realmente dá tudo errado é quando esse cara está tentando mudar o mundo sozinho, esse cara está abraçando tudo para ele conseguir mudar ou dar pelo menos o primeiro passo de maturidade dentro de uma empresa e assim, é muito comum a gente encontrar designer nesse momento, nesse passo de transição. E é legal perceber como que essas pessoas, a pequena atuação dessas pessoas dentro desses projetos é relevante, é interessante porque tudo começa a passar por ele, de certa forma, para ir para frente e aí nesse ponto que a gente começa a perceber qual é a relevância do designer para o negócio, que ele passa a ser como se fosse o primeiro passo antes de ser traduzido para a equipe de desenvolvimento ou para a equipe de negócio, e é aí quando a gente começa a mudar a maturidade das empresas.Marcelo Szuster: Interessante. Ou seja, a Júlia comentou quase que como se fosse assim, como existe uma… como você não faz um teste AB, não é, vamos supor, faz o produto por duas equipes diferentes e ver qual ficou melhor, a pessoa as vezes faz de um jeito sem designer e acha que aquele jeito é o suficiente, não é? Ou quando resolve colocar um designer faz um esforço de não criar aquilo como uma competência do time, mas como um cara único que faz aquilo tudo. Nós estamos começando a falar aqui quase que de sub alocação de time como um primeiro problema, não é? Seja não colocando um designer ou colocando só numa fase rápida, meio que não entendendo a importância dele, que as empresas pressionadas muitas vezes por custo, etc., elas pensam: “O cara já atuou ali naquele design sprint, agora é só fazer”.Júlia: É porque existe a condição de fazer sem ter o designer, não é?Marcelo Szuster: De algum jeito faz-se, não é?Júlia: Porque assim, acho que o designer, antes de a gente entrar até em UX, mas designer no geral é tido como criativozão assim.Luiz Pimenta: Sim.Júlia: E aí criativos todos somos, qualquer pessoa na vida tem capacidade de ser criativa, mas além de criativo o UX ele tem toda uma série de embasamento sobre leis visuais, de arquitetura de informação.Marcelo Szuster: É, tem uma técnica que vocês trazem.Júlia: Existe todo um estudo por trás, eu acho que… me corrija se eu estiver errada, mas eu gosto de brincar que assim, a parte de UX é uma das áreas dos designs que é menos aberta assim para conceito e tal, e ela tem muito embasamento teórico, então ela é muito racional nas escolhas.Marcelo Szuster: Ao contrário do que muita gente imagina. O que você acrescenta aí, Vini?Vinicius: Até casando um pouco com que o Luiz falou, não é? A gente lá atrás, na DTI, eu comecei na DTI, eu fui um dos primeiros designers lá com a Iasmin, não é?Marcelo Szuster: Sim.Vinicius: Enock também. E é engraçado ver que a evolução da DTI casou muito com a evolução do designer dentro da empresa também. No início eu participava do marketing, fazia proposta comercial, fazia um pouco de tudo e aí a gente passa a ter um papel mais estratégico dentro do levantamento de requisitos do projeto. E hoje eu vejo assim principalmente o designer como um papel de… se o Scrum Máster remove impedimentos, o designer remove incertezas, eu acho que é muito esse papel que a gente tem dentro das equipes também.Marcelo Szuster: Bacana. Eu nunca tinha visto essa definição. Fale mais sobre isso. Assim, consegue exemplificar isso para ficar mais tangível para quem está ouvindo?Vinícius: Claro, sim. Eu acho que essa remoção de certeza tem a ver com essa parte de Discovery, o cliente ele chega com o material bruto não lapidado, do que ele pensa ser uma solução, do que ele acha que é um problema, ele chega cheio de hipóteses, não é? Todo o nosso trabalho desde o design sprint até prototipação é tangibilizar essa visão, é a gente trazer um pouco mais real e um pouco mais palpável aquilo que o cliente está querendo, o que é que ele está precisando. Desde o design sprint e de forma conceitualmente trazer a hipótese do problema, confirmar a hipótese do problema e gerar um protótipo, e esse protótipo também ele remove incertezas do que é, do que seria visualmente aquele problema também. O conceito de protótipo, enfim, ele é muito abrangente, mas eu acho que tem todo esse papel de fazer essa amarração entre o que é uma incerteza até o momento que ele se torna algo palpável. Eu acho que esse é o grande papel do designer assim dentro das equipes, não é?Marcelo Szuster: É por isso que eu acho que as questões sempre têm vários… elas são complexas, ou seja, isso que você falou, muitos clientes, eu acho que isso está mudando, mas muitos clientes não acham que tem essas incertezas na verdade, a história de contratar uma solução e não…Vinícius: Exatamente.Marcelo Szuster: …Contratar um time para resolver o problema.Vinícius: O cliente normalmente ele chega querendo que a gente protótipo já o que está na cabeça deles ali, igual a gente chama de manobrista de layout, ele vai ficar ali e vai te falar o que é que tem que ter, mas a gente gosta aqui na DTI de dar um passo anterior e tentar ver qual que é o problema dele. A gente está definindo o problema da maneira certa antes de a gente passar para a solução que na cabeça talvez daquele gestor está muito clara, mas que as vezes não é a realidade de quem vai utilizar a ferramenta, não é? E aí a gente começa a trabalhar também a questão centrada no usuário, e isso é muito importante para a gente começar a levantar o produto em si, não é?Marcelo Szuster: Ou seja, o primeiro passo é o cliente reconhecer que essa incerteza existe. E que na verdade eu sempre tento hoje mostrar para os clientes isso, que hoje ele contrata uma equipe para resolver um problema e não uma equipe para desenvolver uma solução, porque assim, eu sempre falo assim, antigamente, digamos assim, você tinha um problema e aí você conseguia pensar teoricamente na solução e aí contratava alguém para desenvolver aquela solução e contratava aquilo transacionalmente. Agora você tem um problema, ele é um problema complexo, então você tem um tanto de hipótese igual o Vini colocou, e aí você contrata um time com várias capacidades para poder conseguir ir validado hipótese e vendo se está resolvendo aquele problema, não é? E uma dessas capacidades é o design.Júlia: É, exatamente. Eu acho que o que Vini comentou é o centra assim, ainda mais quando a gente pensa no time ágil, que ele está se propondo a gerar valor rapidamente, o designer está ali na linha de frente com todo mundo para poder pensar a solução e minimizar o retrabalho, ajudar a ter assertividade realmente na solução que é criada.Luiz Pimenta: Abrindo um paralelo no que a Júlia e o Vini falaram, tem umas aspas que eu acho muito interessante que eu ouvi em uma palestra uma vez do Anderson Gomes que ele dizia que designer são bons facilitadores, mas os facilitadores vão além das dinâmicas, de facilitar um designer sprint, de facilitar um Discovery, porque a facilitação ela está no dia a dia, então é como o Vini disse, é para eliminar incertezas. Então nós facilitamos os caminhos para que essas incertezas venham à tona. Então designer serem bons facilitadores facilita para a equipe de desenvolvimento, facilita para as pessoas de negócios. Então é parte intrínseca do designer essa facilitação, a facilitação dos caminhos, não é descoberta de problemas.Marcelo Szuster: E uma pergunta que é até clichê, mas é inevitável quando tem o designer. O que é o design thinking? Ainda tem muita gente que me pergunta. A gente sempre fala quem um pilar nosso aqui é usar o design thinking. Como é que vocês explicam isso? O que é o pensamento de designer?Luiz Pimenta: Quem quer pegar essa bola aí primeiro?Vinícius: Pode ser eu?Marcelo Szuster: Fala aí, Vini.Vinícius: Um design thinking ele é uma formatação de várias metodologias lúdicas de levantamento de requisitos de projetos, entendimento do usuário que datam, enfim, quase que (inint) [00:15:32] assim, uma coisa muito antiga, mas aí, enfim, nos últimos 20 anos o Tim Brown foi lá, pegou todo esse material e grampeou, cara, e chamou de design thinking. Mas vamos dizer que o Tim Brown, o cara da IDEO e outros movimentos aí, eles coletaram essas dinâmicas, essas ferramentas, esse modo de fazer e chamaram design thinking. O design thinking é uma abordagem de centralizar o seu problema em um usuário, levantar o contexto dele, quais são as dores e a partir disso entrar, enfim, na solução, na hipótese de solução e a criação de um artefato testável que confirma ou não aquela hipótese de problema e de solução, que a gente chama de protótipo. Então é ir de um entendimento até uma fase que você vai planejar, você vai (inint) [00:16:27], você vai prototipar, testar e repetir esse ciclo de novo, porque no teste você vai aprender como é que agora com aquele artefato está o seu cenário e aí você pode levantar mais melhorias para aquele produto, para aquele protótipo até, enfim, ser usado por alguém. Então é essa abordagem em etapas e sempre pensando no usuário, entender antes de fazer, acho que esse é o principal assim.Marcelo Szuster: É. E nesses tempos de necessidade de se tornar customer centric foi isso que colocou o design thinking a frente aí, acredito eu, porque as empresas sempre acostumadas a empurrar os produtos e agora elas são puxadas. Elas são puxadas por quem? Você tem que aprender a se colocar na perspectiva de quem está puxando e ter as técnicas para poder criar em torno disso, não é? Ok. Então aí eu pergunto o seguinte, nós… Beleza. Vamos supor que a gente conseguiu passar essa mensagem aí da importância do pensamento de designer e da importância de se ter até uma visão de humildade, que a gente vai explorar um problema e que, portanto, precisa de ter uma capacidade adicional no time que permite explorar esse problema, não é? Eu diria que é um bom jeito de todo mundo entender, os times ficam limitados se eles não têm isso porque falta essa capacidade adicional de explorar um problema melhor e de reduzir risco, igual o Vini colocou. Mas então quanto mais tangível fica melhor para alguém que está desconfiado, como eu sou cético eu me coloco fácil na visão dos céticos. Muita gente cética ainda vai ficar com a visão que a Júlia disse, “Cara, ok, mas a gente dá um jeito de fazer sem isso”, alguém ainda vai… O que é que o designer então pode fazer desde o começo até o fim aí? O que é que dá para ele fazer? Quais são os diversos tipos de atividades, o relacionamento dele com a equipe, com o próprio cliente? Para o pessoal entender mesmo o que é isso na prática.Júlia: Acho que a atuação do designer é muito ampla e muito maleável de acordo com a necessidade do squad, da solução que está sendo construída. Hoje a gente tem diversos tipos de especialistas dentro de UX, mas acima de tudo eu acho que quando a gente fala em colocar o designer e aí entra muito no que você acabou de comentar. Acho que existem dois lados. O primeiro lado são os produtos que são voltados para um cliente final do nosso cliente, ou a própria empresa que está construindo uma solução para o seu cliente final, nesse caso fica muito claro qual que é a necessidade. Hoje a gente tem uma série de concorrentes para todas as áreas, só oferecer um produto não é suficiente, você precisa entregar com qualidade, você precisa mostrar o seu diferencial. Então existe cada vez mais uma necessidade das empresas de investir em design para entregar soluções melhores que convençam e engajem o cliente no que eles estão construindo. E a outra vertente é quando a empresa está criando soluções para dentro dela mesma, e aí é um pouco mais… ainda está um pouco mais insipiente essa parte porque ainda bate muito naquela, “Mas eu não preciso fazer uma solução tão simpática, é para o meu funcionário”, mas o designer ele entra muito para estudar os contextos. Então estudando a realidade daquela pessoa que está trabalhando, enxergando a ponta, vai entender qual é o melhor meio para poder fazer aquela solução, como vai ajudar a minimizar erros, como vai ajudar a diminuir custos e uma série de questões alinhadas ao negócio que muitas das vezes não são consideradas.Luiz Pimenta: Aproveitando um pouco do que a Júlia falou e pegando até um podcast anterior. É nesse momento que o designer começa a alimentar os tigres. Então você começa a fazer pequenas entregas que mostram o valor realmente voltado para o cliente foco, o cliente final. E quando a empresa começa a colher os pequenos resultados dessas entregas que tem o designer envolvido, elas começam a enxergar, de fato, o valor. E como eu cometei, ele começa a escalar na maturidade, então ele deixa de ser só a pessoa que faz de tudo e começa a evangelizar, ela começa a passar essa cultura para as outras pessoas. É igual o Vini falou, é interessante trazer também que o design thinking ele não é uma ferramenta pronta, que você pega um livro e vai rodar ele do início ao fim e ele vai funcionar igual para todo mundo, porque ele muda de contexto para contexto, ele muda de empresa para empresa, consumidor para consumidor. Então ele é maleável igual a Júlia comentou. Então é nesse momento que ele começa a escalar, porque ele adapta ao contexto que ele está inserido. Então essas pequenas entregas de valor fazem com que ele comece a evangelizar as pessoas que estão em volta e essas próprias pessoas começam a se preocupar com o design. Então aquela preocupação dele que antes era muito mais palpável em termos de protótipo, ela passa a ser diluída ao longo do processo. Então os próprios desenvolvedores vão passar a se preocupar mais em manter uma coerência estética, uma coerência de arquitetura de informação e tudo mais, e ele passa a se preocupar com informações mais relevantes para o negócio. Então esses pequenos valores entregues começam a fazer ele subir uma escada de maturidade, a partir do momento que ele começa a subir essa escada as coisas vão fluindo muito naturalmente, começa a surgir a figura de novos designers ou de novas pessoas com pensamentos de design que desafogam esse designer que tinha o papel de lobo solitário lá princípio, e passa entregar cada vez mais valor voltado para o design.Marcelo Szuster: Então ele vira um guardião dentro da equipe disso, mas vocês diriam que a equipe, os desenvolvedores, os arquitetos, PO, todo mundo que está ali deve estar convertido para esse pensamento de design?Júlia: É para trabalhar em conjunto. O ideal é que a gente tenha quase uma tríade ali do negócio, da área técnica e da área do usuário para que a gente construa uma solução que seja realmente eficiente, eficaz, que atenda às necessidades.Vinicius: O designer dentro das equipes ele têm que ter essa postura de ser o responsável pelo design, garantir que as boas práticas estão sendo feitas, mas ele não é dono do design. Esse pensamento tem que estar distribuído dentro da equipe e de forma que ele abra um espaço para criar junto mesmo, poder bater no ombro de todo mundo da equipe e virar para resolver uma solução e deixar todo mundo (inint) [00:22:43], criar e poder propor soluções melhores, porque por muitas vezes as pessoas estão ali, os desenvolvedores, o GP, enfim, quem tiver ali, o Scrum Máster, pode trazer muita ideia bacana e experiências legais de outros projetos. Então abrir esse espaço de ideação e cocriação eu acho que também é um papel bacana, e aí casando com o que o Luiz falou, de facilitação também.Marcelo Szuster: Vini, muito legal o que você disse, me trouxe até um insight aqui, porque uma coisa que eu sempre comento com os clientes é o seguinte, é impressionante como a gente acaba sempre voltando aos modelos tradicionais sem querer. Então, por exemplo, o PO ele virou muitas vezes no mercado alguém que encapsula a equipa toda e vira o único cara que entende de negócio, que prioriza e que sabe, não é? E aí a equipe, é como se a equipe ficasse lá esperando, sabe, o PO decidir e a equipe ficasse em uma postura assim: “Se nós não geramos valor é porque o PO priorizou direito. O PO é que sabe”. E é, poxa, tem esses movimentos aí de falar do heart of (inint) [00:23:49], vai lá no coração do (inint) [00:23:52], é o contrário disso, o coração do (inint) [00:23:55] é você saber, cara, eu tenho uma equipe multidisciplinar, eu tenho gente boa ali, todo mundo está comprometido com a entrega de valor e todo mundo pode dar ideia. Então achei muito legal o que você disse tanto do ponto de vista do que o designer não deve fazer isso com a disciplina dele, achar o seguinte, qualquer decisão de design aqui então é só minha, mas talvez ir além disso sendo também um guardião dessa atitude, sabe, de que a equipe toda está colaborando, já que ele acredita, os designers devem ser os que mais acreditam nessa colaboração, não é? Porque a essência do design thinking, se eu entendo bem, é uma colaboração multidisciplinar centrada, puxada pelo usuário, mas tem essa essência colaborativa, não é isso?Júlia: Exatamente. Quando a gente fala de facilitação, tem a facilitação do design sprint, do Lean Inception, do Discovery e por aí vai e tem essa facilitação que o Luiz comentou, que é justamente durante o dia a dia você conseguir promover diálogos, promover novas interfaces entre as pessoas envolvidas no processo para poder gerar uma solução que seja com um risco minimizado assim. Então é uma facilitação que é muito maior, não é, é um articulador, mas ao mesmo tempo todo mundo tem esse papel de articular também. O designer só não consegue fazer um bom processo de UX sentadinho na cadeira dele só tirando as coisas da cabeça, tem que dialogar com todo mundo para poder entender realmente qual que é o cenário. Porque não adianta nada, faz um uma solução incrível ali, prototipa um negócio maravilhoso, não testa com usuário para saber se ela realmente resolve a situação, não conversa com o PO para saber se o negócio alinhado com isso, não conversa com a empresa, não procura a equipe de desenvolvimento para saber se é viável fazer aquilo. E aí no final das contas fica aquele entrave assim, ao invés de criar comunicação em um trabalho de cocriação, vira uma série de muros, que aí o pessoal fala: “Não vamos chamar o designer porque vai dar trabalho”, ou então “Não, não vamos fazer desse jeito não, vamos…”, e aí não existe consenso que teria muito aprendizado. Então acho que acima de tudo é muita maturidade de todo mundo ali para construir um trabalho em conjunto.Luiz Pimenta: Parte do trabalho do designer vem de uma palavra que está muito na moda hoje em dia, que é empatia. Ter empatia com as pessoas, tem empatia com o usuário de fato, ir a fundo no problema do usuário. Tentando trazer para um contexto mais palpável assim de prática. A gente consegue ver a transformação acontecer dentro de cenários reais dos nossos clientes, então a gente teve casos lá que a gente participou de clientes que quando o designer chegou para atuar o sistema era uma bagunça, a gente não tinha coerência de cor, não tinha grid bem montado, não tinha arquitetura nenhuma de informação, fluxos muito desconexos. E quando o cara chega ele transforma tudo, ele começa, aí vai palpitar em tudo, vai reclamar do trabalho de todo mundo, vai xingar, vai querer mudar tudo, virar o sistema de cabeça para baixo. E aí a equipe de desenvolvimento fica transtornada porque o cara chegou agora e o cara quer transformar tudo, o cara quer só dar trabalho, o cara não quer… ele vai mudar tudo. Só que a partir do momento… eu vou trazer, por exemplo, um caso real que, assim, a gente fez uma pequena mudança em um projeto, por exemplo, que trazia uma animação que era muito simples, que mostrava uma variância de preço para um vendedor, era quando ele entendia que a margem dele de venda estava caindo drasticamente e que ele precisava tomar uma ação sobre aquilo. Era uma animação muito simples, um GIF criado lá de forma muito rápida, mas quando entrou em produção o diretor da empresa, o cara que paga a conta, ele ficou louco com aquela animação, porque para ele era muito visual o que estava acontecendo, para ele era muito drástica aquela mudança. Quando ele enxergava a balancinha pesando, tipo assim, ela pesava a ponto de virar a balança, o cara simplesmente enlouqueceu, ensandeceu.Marcelo Szuster: Tinha um efeito dramático ali mesmo.Luiz Pimenta: Tinha um efeito literal dramático. Então a gente tinha três estados lá da balança, um mais leve, um mediano e o grave, que a balança virava. Quando ele viu essa balancinha virando ele enlouqueceu e queria atuar em cima de todos os vendedores e tudo ele falava tipo assim: “A gente precisa lá, quando você ver aquela balancinha você tem que fazer alguma coisa, porque a sua margem está ruim. Você tem que resolver o problema”. E nesse ponto foi quando o designer começou a virar a mesa.Marcelo Szuster: Cara, esse exemplo seu é maravilhoso porque quando fala de empatia, que as palavras… sabe o que acontece assim, tudo é muito fácil de virar clichê, tudo em mundo de negócios vira muito clichê, não é? A transformação digital, a empatia, mas empatia é entender, por exemplo, como uma coisa dessa pode fazer diferença, sabe assim? E eu posso dar um depoimento. Assim, eu desenvolvi software muitos anos e sou engenheiro, e, assim, as vezes eu falo brincando, eu tenho vergonha do software que a gente fazia antigamente e do software que a gente faz hoje, sabe? Porque assim, a gente fazia realmente sistemas, tinha tudo quanto é informação ali de algum jeito, alguns sistemas até extremamente sofisticados e etc., mas realmente quando você começa a ver uma coisa que é puxada usando empatia, entender que para aquela persona na situação que ela está, o jeito que você tem de alertá-lo sobre uma situação importante é daquele jeito, não é? Isso faz toda a diferença, cara.Luiz Pimenta: Uma frase que eu também acho interessantíssima é da Vanessa Kirby, que ela diz que: “Se você diz que um produto é bom só porque ele tem uma boa usabilidade é dizer que uma comida é boa porque ela é comestível”. Você criar um produto, você tentar argumentar que um produto é bom só porque ele é fácil de ser utilizado, você não gera desejabilidade, a pessoa não tem engajamento com o produto. Então você está criando mais do mesmo.Marcelo Szuster: É, você está ignorando todo o aspecto emocional da interação, não é? Tudo que é humano mesmo.Luiz Pimenta: Tudo que é humano. Por isso que o papel da empatia ele é crucial, porque você tem que realmente entender como você resolve um problema, como que você sana uma dor, como você cria valor para o (inint) [00:30:06].Marcelo Szuster: Não, e aí é interessante, explica o que a Júlia falou, não é? Por que é que esse movimento começa mais forte na solução que é para o consumidor final? Porque para o consumidor final tem uma barra elevada e empresa está com medo, não é? Só que o que cada vez mais vai acontecer para mim é que internamente também a barra vai ficar elevada e porque não ter essa desejabilidade que você está falando também pelo que as empresas oferecem dentro, não é? Ainda é uma visão muito assim, “O cara tem que usar aquilo ali. O cliente tudo bem, o cara aqui dentro…”, mas eu acredito que essa experiência do… você quer o máximo de produtividade que é a satisfação também do seu funcionário, você quer que as coisas aconteçam bem, então esses aspectos emocionais também são importantes para dentro, não é?Júlia: Exatamente. Uma das coisas que eu mais tenho visto surgindo dentro de organizações que demandam novas soluções são justamente conseguir trazer o trabalhador que hoje tem que, para fazer o trabalho de análise, passar por uma série de trabalhos operacionais que não geram valor nenhum para a empresa e conseguir fazer com que ele passe a conseguir fazer mais esse trabalho analítico, de conseguir demonstrar, de conseguir reunir mais dados de uma maneira inteligente, de conseguir minimizar caminhos para ele. Então é muito mais do que só ser fácil de usar, porque fácil de usar ele já está, por exemplo, acostumado com 30 planilhas de Excel que ele sabe como é que ele usa. Mas vai além disso, vai em como dá para poder otimizar, em como dá para minimizar dor, gerar valor, tudo isso vai sendo englobado.Marcelo Szuster: Agora um complicador. Como é que vocês enxergam isso aí? Eu queria que o Vini falasse também. Assim, eu já falei em outros episódios também que, por exemplo, quando eu falo de um squad cristalizado, eu acho essa metáfora boa porque é um squad que não tem espaço para as coisas acontecerem, sabe? Então por exemplo quando quem está contratando enxerga que desenvolvedor só pode desenvolver, por exemplo, e aí começa a pensar em produtividade como alguma coisa que desenvolveu, o desenvolvedor não tem espaço para criar empatia, ela não tem espaço, por exemplo, para ir no campo com o vendedor, que você mencionou, e sentir a reação dele a usar isso, não é? E aí perceber, nossa, como eu posso impactar o cara aqui, porque ao invés de ficar na minha bolha ali dentro, na minha mesa eu estou… E eu fico pensando que vocês designers talvez tenha o problema também similar de as pessoas entenderem o que é que vocês estão produzindo, entendeu? Porque para quem acha que é só tela, se nessa interação teve uma tela só, o cara fala: “Você ficou esse tempo todo fazendo uma tela?”. Como é que resolve isso e o que é que vocês me dizem a respeito disso?Vinícius: Normalmente assim, e essa é a impressão quando a gente tem clientes com a relação muito recente com a gente, que acha que o designer é essa pessoa que vai entregar telas, não é? Não desmerecendo telas, porque existe toda uma ciência, enfim, existe toda uma preocupação, um estudo sobre a interface que ele demanda muito estudo e muita atenção, não é, para você resolver um desafio em termos de interface, claro. Mas eu acho que tem muito essa coisa do olhar, você ir a campo e olhar para o usuário e o cliente ele entender que você precisa fazer esse movimento, você precisa ir até o local de trabalho muitas vezes e entender como é que você vai traduzir essa ferramenta para o usuário, não é? O que a gente tem feito muito assim, e eu acho que casa muito com o nosso processo da DTI, que é casar o que a gente faz com OKR. Então quando você fala que na verdade eu não estou entregando tela, eu estou entregando um monte de objetivos de negócio, isso a equipe toda vai entregar junto, não é? Mas a partir do momento que você fala assim, que eu vou reduzir tantos Excel lá que o cara usa, vou automatizar uma pancada de coisa e a produtividade do cara aumenta, enfim, e não só isso, a alegria do cara de trabalhar com a ferramenta aumenta, então a gente começa a entregar e mostrar valor assim numericamente mesmo, através dos OKRs para o cliente, não é? Eu acho que essa é uma forma de dar essa impressão que o resultado daquela tela não é a tela, é o que ela resolve de fato.Marcelo Szuster: E que a produtividade é a produtividade do time na verdade, não é a produtividade de um. Porque é difícil, assim, na visão reducionista você tenta medir a produtividade de cada um, vou pegar a produtividade do time. Mas esse exemplo da animação é interessantíssimo. Se você pensar em resultados de negócios aquela ideia de botar aquela animação e a animação em si pode ter sido feita em um minuto, ela mexeu muito mais com OKR do que um tanto de coisa, não é? Então como é que você mediria a produtividade da tarefa? Entendeu? Eu estou tentando mais aqui é mostrar como que os clientes eles devem entender que um squad tem que ter certas competências e ficar sabatinando e vendo se os resultados estão sendo alcançados, não é? Do que tentando decompor cada papel ali e tentando ver exatamente o que cada um faz, que é, no final, uma visão reducionista.Luiz Pimenta: Um desafio muito grande que ele existe hoje que é o: como medir design? Para as empresas é muito difícil medir design, porque não necessariamente ele vai ser tangibilizado em números, mas ele pode ser tangibilizado em experiência. Mas é interessante ver como a mudança acontece quando a própria equipe de desenvolvimento ela cria expectativa, depois de uma entrega, de qual vai ser a percepção do usuário final em relação aquilo, isso a gente consegue ver na prática quando… por exemplo falando no dia a dia. Toda vez que a gente desenvolve uma nova solução, quando a gente coloca em produção a própria equipe de desenvolvimento ela gera uma expectativa tipo: “E aí, acessa em produção para a gente ver como é que foi o engajamento, como é que foi a resposta, qual que é o índice de uso da nossa plataforma”, eles mesmos acompanham esses números de acesso, de trafego para saber como é que está sendo  o engajamento em cima da solução. A própria equipe ela passa a se preocupar não só com os resultados numéricos ou tangíveis sobre isso, mas qual foi a percepção do usuário. E aí a gente tem algumas figuras-chave dentro do ágil, que são os próprios usuários-chave, que quando eles trazem feedbacks, a própria equipe assim ela se preocupa em como rotacionar, como mover em cima desses feedbacks, sejam eles positivos ou negativos, e a própria equipe ela vai da euforia para o desânimo, por exemplo, quando você lança uma nova solução que não teve engajamento. E eles vão atrás de tentar entender o porquê é que isso não está acontecendo, de qual foi a razão, onde que falhamos no meio do processo para que esse engajamento não acontecesse. E isso parte não só do design, parte de todo mundo, é igual o Vini falou, nós não somos dono do design, então parte da responsabilidade de todo mundo. E quando você a equipe mudando, a equipe preocupando com isso você começa a sentir também a maturidade subindo, que você não tem que ter o esforço solitário mais, todo mundo passa a preocupar com o problema em si, não só com a solução.Vinícius: E eu queria só complementar isso que você disse. Você falou da parte de a gente testar a solução, testar na verdade a hipótese de solução e a gente levar aquela, vamos dizer, aquela carinha de sistema que a gente entregou, aquele fluxo de trabalho que a gente achou que resolveu e entregar na mão do usuário e a gente colocar e fazer teste de usabilidade para levantar melhorias daquele cenário, porém o cliente muitas vezes ele acha assim: “Poxa, mas eu já paguei aquela solução, está pago, eu não vou fazer melhorias”. Aí você pode até levantar um backlog de melhorias que vai ficar engavetado. Hoje esse é um grande desafio nosso, a gente ter a liberdade e a autonomia para que o cliente confie na gente para a gente transformar o sistema à medida que a gente for colhendo justamente esses feedbacks assim e não achar que nós… “Eu já gastei esse dinheiro, essas sprints para resolver esse problema. Como assim você quer fazer melhorias nele?”. Então a gente ainda perde um pouco no cenário da experimentação assim, de aquilo que eu estou entregando é para sentir a temperatura da água, para saber o que é que eu posso melhorar naquilo, naquele material bruto. Então esse para mim eu acho que hoje é um dos grandes desafios em termos de teste e de percepção do usuário daquilo que a gente está entregando.Marcelo Szuster: Eu concordo, porque assim, o que é que eu fico vendo, que acho que a decisão mais difícil para os clientes, principalmente grandes empresas que tem mais a perder do que startups, é simplificar as coisas de forma que ela possa aumentar a possibilidade de experimentação, não é? Porque assim, existe um problema real aí mesmo que muitas vezes o MVP não é MVP, se gasta muito dinheiro e é extremamente frustrante ter que continuar gastando mais, porque na verdade não era um MVP. Eu sempre falo com os clientes, eu falo: “Cara, não tem jeito, um time, se você tiver acreditando que um time é produtivo, se tem muita coisa para fazer, não tem… o time não consegue fazer o milagre de diminuir as coisas que tem para fazer, o que é possível é simplificar as coisas que têm para fazer e começar a gerar valor antes e confirmar a hipótese antes. Se você consegue fazer isso você cria um ciclo virtuoso de experimentação”. Mas eu vejo essa dificuldade em empresas grandes, e não é uma crítica não, é porque realmente elas têm mais a perder, não é? Uma startup não tem nada a perder, em princípio ela bota um negócio mais rápido ali, as vezes não tem ninguém nem usando ainda, não tem jeito, uma empresa grande ela pensa, só que isso não pode ser muleta também.Júlia: É, o risco é muito grande quando a gente está falando de uma empresa grande e aí a gente tem um cenário de muitas empresas tradicionais ainda e que é realmente difícil assim você primeiro levar para o pensamento ágil. Então a gente vai gerar valor aos poucos, não vamos pensar em escopo, vamos colocar um outro tipo de pensamento, aí você fala: “Bom, o design, junto com todo time, foi lá, estudou como é melhor forma de fazer, fez”, “Mas vai ter que ter melhoria? Já não estudou qual que é a melhor forma?”. Assim, é muito mais fácil, não que seja fácil, mas é muito mais fácil vender hoje o papel do design antes da entrega, porque está justamente minimizando esse risco de fazer uma solução que realmente seja adequada, do que depois, muitas vezes é assim: “Não, esse é o produto”, e por aí vai, não só do designer, mas acho que e todo mundo, de conseguir ir fazendo melhorias e tornando a solução cada vez mais assim relevante.Marcelo Szuster: É, acho que você foi num ponto interessante, porque essa visão tradicional de só entender que ele atua antes ainda é um waterfall disfarçado, não é? A pessoa acho que está definindo a solução antes e até entende que precisa de um designer que ele sabe fazer bem o protótipo e não entende o designer naquele papel de eliminador, de diminuidor de incerteza. Pessoal, nós estamos chegando aqui no final, acho que foi uma conversa excelente. Acho que ficou muito claro aí, a gente tentou deixar muito claro que o designer traz para a equipe essa competência de criar empatia, de criar experimentação e de (inint) [00:41:23], diminuir risco e garantir que aquele squad e aquele produto digital está gerando valor, não é? E esse papel só é possível de se alcançar isso se isso for feito de forma contínua, você não consegue fazer isso num momento X ou Y, isso tem que ser feito de forma contínua. Então um squad real precisa dessa capacidade, não é?Júlia: Exatamente. Eu gosto de brincar que o designer não pode ser o Mestre dos Magos, que chega, dá um caminho assim com o protótipo.Marcelo Szuster: E vai embora.Júlia: E sai, desaparece.Marcelo Szuster: Perfeito, pessoal. Muito obrigado. Um abraço para todos.Luiz Pimenta: Muito obrigado, gente. Foi um prazer participar aqui. Queria mandar um abraço para todas as equipes da DTI que entendem muito bem qual que é o papel do designer aqui, em especial para as equipes também que trabalham comigo. E é isso aí, que todos entendam que o designer, além de uma pessoa, ele é um pensamento.Marcelo Szuster: Bom demais.Júlia: Muito obrigada, pessoal. Foi muito boa a conversa.Vinícius: Valeu, gente. Obrigadão aí. Espero não ter passado muita moto aqui.Marcelo Szuster: Valeu, Vini. Abração.