Transcrição de vídeo

Entenda o IBM Design Thinking em 10 minutos?

É tão engraçado, quando vou a um museu de design e eles colocam esses artefatos, esses produtos acabados de
design e os nomeiam de design. Não são, eles são o resultado do design. São os produtos do design. Mas o design
era tudo, menos pensar no trabalho duro das situações estressantes que passaram até chegar à decisão que levou
a esse artefato.

Quando falamos de design na IBM, não estamos falando de designers. E acho que esse é um tipo de distinção
realmente importante que precisamos fazer. O design é muito importante apenas para designers. Então, nós
realmente temos que revelar seus segredos para todos os envolvidos nesses problemas. O pensamento mais
importante sobre o design thinking na IBM, ou o IBM design thinking, é uma espécie de como continuamos essa
conversa com nossos clientes e usuários.

Isso nos leva aos três princípios do IBM design thinking: o foco nos resultados dos usuários, as equipes diversas
capacitadas e a reinvenção da inquietação sendo essa conversa entre nossos usuários e nossas equipes. E assim,
quando falamos sobre o loop, falamos sobre um loop de entendimento contínuo, no qual toda vez que você
observa, você entende um pouco mais sobre o mundo ao seu redor. Toda vez que você reflete, entende um pouco
mais sobre sua própria equipe e o que pode fazer pelo mundo. E, toda vez que você cria, você entende um pouco
mais sobre as soluções ou possíveis soluções existentes.

Então, tratamos tudo como um protótipo no design thinking. Tratamos tudo como um produto inacabado, que
será sempre repetido, que será sempre reinventado. Para um determinado problema ainda sem solução, que
estamos tentando resolver, você sabe que uma equipe pode observar, refletir e fazer. E assim, eles literalmente
usam o loop para tentar resolver um problema ainda sem solução.

Mas, na IBM, os problemas que estamos tentando resolver são certamente muito maiores que isso. Eles exigem
equipes multidisciplinares complexas para até algumas de nossas interações mais básicas com os clientes. Então, o
que fazemos, em vez disso, é que muitas vezes dividimos os problemas de duas maneiras. Podemos dividir por
equipe. Ou seja, dependendo de como você trabalha, é possível chamar esses esquadrões ou fluxos de trabalho. E
nesse cenário, cada equipe ou fluxo de trabalho pode usar o loop para resolver sua parte do problema.

A outra maneira de gerenciarmos projetos é dividi-los por tempo. E assim, podemos dividir o problema em sprints
ou fases ou como você preferir chamar. Dependendo de como você trabalha. E assim, neste cenário, cada equipe
mais uma vez estará observando, refletindo e fazendo sua parte no quebra-cabeça. E assim, para fazer o design
thinking funcionar nessa escala, introduzimos as chaves para o IBM Design Thinking.

Os hills nos alinham entre as equipes. Eles nos ajudam a definir objetivos para cada equipe que se propõe a fazer o
trabalho. As reproduções nos alinham ao longo do tempo; elas nos alinham à medida que iteramos e evoluímos
nosso entendimento da solução. E os usuários patrocinadores nos alinham à realidade de nossos usuários; os
usuários do mundo real que trazemos para os projetos, nos quais estamos trabalhando para manter contato com
as necessidades do mundo real que eles estão enfrentando.

Simplificando, os Hills alinham nossas equipes entre diferentes subequipes ou fluxos de trabalho. Muitas vezes
surge a pergunta: qual é o Hill bom o suficiente? Meu Hill favorito de todos os tempos, na verdade, vem do Geico.
15 minutos podem economizar 15% ou mais no seu seguro de carro. E se você dividir isso, não significa apenas que
você deve ser capaz de concluir uma transação em menos de 15 minutos, mas fazendo isso, deverá ser melhor do
que os seus concorrentes fazem. Quanto melhor? 15% melhor. E assim, essa afirmação simples pode alinhar uma
empresa inteira em torno de qual será sua proposta de valor em termos concretos reais, que um usuário pode
entender.

1
Um ótimo exemplo de um hill aqui na IBM seria algo como você saber que o Bluemix é o primeiro hill. Após
descobrir o Bluemix, o desenvolvedor não deve levar mais de 15 minutos para construir e implementar um
aplicativo usando serviços IBM e de terceiros. O que é importante observar sobre todos esses hills, seja o hill do
Geico ou o hill do Bluemix, é que nada aqui diz algo sobre como isso será feito, eles são completamente
independentes da implementação. Então, eles dizem para onde ir, mas não como chegar lá, e cabe à equipe
descobrir isso.

É muito tentador tentar escrever Hills com base em uma ideia, uma noção preconcebida que você tem da solução.
E quando isso acontece, você frequentemente vê a solução começar a se ajustar ao hill. E o que acontece, então, é
que começamos a nos concentrar mais no que podemos construir, em vez de como podemos atender ao usuário.
Então, é realmente importante que você saiba que esses hills são agnósticos de implementação. Eles devem
oferecer a uma equipe que saiba muito melhor do que nossos gerentes, o espaço para fazer a coisa certa, tomar
essas decisões e ser criativo por conta própria.

As reproduções alinham nossas equipes ao longo do tempo. Se você é uma equipe grande, nem todos têm tempo
para estar no loop de todos. E assim, uma reprodução é realmente um momento para trazer outras pessoas,
outras partes interessadas para o loop conosco. E, literalmente, uma reprodução é uma maneira de reproduzirmos
nossas observações, nossas reflexões e nossas criações de volta para outras pessoas da equipe. A parte mais
empolgante sobre uma reprodução é o fato de que, com base no que observamos, no que refletimos e no que
fizemos, você está realmente começando a contar uma história da perspectiva de um usuário final. E assim,
frequentemente, nas reproduções, contamos histórias da perspectiva dos usuários. Ao contar histórias sobre a
experiência do usuário, a discussão não é mais estruturada em torno de: "o que o SVP pensa ou o que o estagiário
pensa?" é mais sobre "bem, baseado no que sabemos sobre o usuário, o que podemos fazer? Esta é uma história
interessante para o usuário?". Isso é algo em que nós, como empresa, realmente devemos investir? Portanto, a
reprodução é apenas uma ferramenta de alinhamento incrível, para ajudar as pessoas a permanecer na pista e
manter contato com as necessidades do mundo real ao longo do tempo.

Os usuários patrocinadores nos ajudam a nos alinharmos à realidade de nossos usuários, à medida que avançamos
nessa jornada. Os usuários patrocinadores são basicamente a nossa maneira de dizer: olha, não sabemos tudo.
Vamos imaginar que você tenha o desafio de projetar uma cabine de comando para um grande avião. Você é um
piloto? Bem, se a resposta for não, então você não tem ideia de como é pousar um avião. E assim, os usuários
patrocinadores são realmente a nossa maneira de dizer: olhe, vamos pegar um piloto, levá-lo para a nossa equipe
e ele poderá nos ajudar a tomar essas decisões em tempo real. Se ele estiver na sala comigo, poderei projetar algo
bem rapidamente, apontar para ele e questionar o que ele acha. Daí, ele poderá me dizer na mesma hora que
concorda ou que discorda do design proposto. Considerando que, se eu não tivesse um usuário patrocinador na
sala, poderia continuar a iterar e ter novas ideias ou qualquer outra coisa, sem saber que estou seguindo um
caminho completamente errado. Até eu ir até o usuário e testá-lo uma ou duas semanas depois. O usuário
patrocinador realmente nos ajuda a fechar a brecha e apertar o loop. Podemos observar, refletir e fazer ali mesmo
na sala com ele.

É importante tratar os usuários patrocinadores como membros da equipe. Eles não são pessoas para quem ligamos
de vez em quando e temos conversas aleatórias. Não, são pessoas que convidamos a observar, refletir e fazer
conosco. As contribuições deles são tão valiosas quanto as contribuições de qualquer outro membro da equipe.

Passamos muito tempo tentando ensinar às pessoas sobre o design thinking. Passamos muito tempo tentando
levar as pessoas a executar o design thinking. Mas, no final das contas, como você conhece o design da IBM,
podemos dar a você o design thinking que você merece. Se você estiver em uma equipe e estiver tentando
desenvolver o IBM design thinking, não tenha medo de fazer perguntas. Acho que passamos muito tempo
assumindo que alguém tem as respostas ou que alguém já pensou nisso e que a lógica é à prova d`água e a história
acaba por aí. E, assim, muitas vezes você descobre que, como um profissional de uma equipe, na verdade, as

2
pessoas não têm a resposta. E que, ao fazer essas perguntas, eles começam a estimular as discussões reais que
precisam ser realizadas.

Se você está gerenciando uma equipe que está executando o IBM design thinking, a melhor coisa que você pode
fazer pela sua equipe é ficar tranquilo quando as coisas ficarem meio bagunçadas, quando surgir uma certa
ambiguidade ou quando a equipe chegar a você e dizer: não sabemos o que fazer. Dê a eles espaço para falhar, dê
a eles espaço para errar algumas vezes, antes que eles acertem. Não há nada como ser capaz de iterar em um
problema e ser capaz de entendê-lo, saber que você constrói seu entendimento ao longo do tempo, sem tentar
acertar na primeira vez o tempo todo. Então, quando você dá espaço para as equipes falharem, você dá espaço
para elas serem mais audaciosas e mais corajosas com as ideias que elas terão. E isso inerentemente levará a mais
resultados inovadores. Você pode não se sentir à vontade no começo. Pode parecer que você está vendo mais
falhas do que sucessos, mas, com o tempo, sua equipe terá ideias melhores. Ela será uma equipe mais feliz. E,
finalmente, seus usuários ficarão mais felizes, porque você terá ideias melhores mais rapidamente.