Os 3 passos do Enterprise Design Thinking da IBM.
Como a IBM divide sua metodologia de Design Thinking dentro dos seus cursos.
Agora que você já entendeu um pouco mais sobre a ideia do que o Design Thinking representa (e se ainda não entendeu, pode ler meu artigo anterior aqui), chegou a hora de entender um pouco mais sobre o Enterprise Design Thinking da IBM, ou, carinhosamente EDT.
Primeiramente, é importante saber que a IBM não apenas instaurou sua cultura própria de Design Thinking dentro de si, mas, ela também leva a metodologia para outras empresas e, além disso, existem pessoas de fora da IBM investindo em conhecer o EDT.
Basicamente o Enterprise Design Thinking da IBM visa trabalhar com equipes diversificadas de modo que todos estejam alinhados, mantenham o usuário como o foco principal de suas sessões, visando solucionar problemas em um ambiente de incertezas mirando na empatia, e assim conquistando eficiência para seus projetos.
Sendo assim, o EDT se baseia no princípio da pesquisa com os users, e da observação ativa, crendo que o design molda o que as coisas deveriam ser, levando seus praticantes a uma compreensão já conhecida, porém, pouco aprofundada sobre o que o design realmente representa: a resolução de problemas.
Se a pesquisa é a disciplina de compreensão do mundo, o design é a disciplina de modelá-lo. Enquanto a pesquisa pergunta “o que é?” design pergunta “o que deveria ser?” Problemas de design são problemas sem solução predeterminada. São perguntas sem resposta certa. Eles exigem que tomemos decisões sobre um futuro incerto.
Alguns de nós prosperam na incerteza. Alguns de nós foram para a escola por causa disso. Mas para outros de nós, o medo de fazer o movimento errado pode nos paralisar, prendendo-nos em um ciclo de dúvida e inação. Afinal, o que você faz quando não sabe o que fazer? (Enterprise Design Thinking IBM)
Para ajudar a superar essas incertezas causadas por situações que trazem vulnerabilidade para o que quer você ou eu estejamos trabalhando, existe um modelo chamado Loop: observar, refletir e fazer.
Observar:
Observar como o próprio nome já entrega é o reconhecimento do nosso usuário, mas, não apenas um reconhecimento superficial, precisamos entender quais suas dores, o que ele faz, o que ele gosta, como se comporta em determinadas ocasiões do dia a dia, você sabe o que o motiva? O que ele faz? O que ele pensa? Quais são seus medos, suas esperanças? É preciso se colocar no lugar do outro com uma grande dose de empatia para entender verdadeiramente o que ele necessita e entender seu modo de enxergar o mundo.
Além disso, entender o ambiente que seu usuário está inserido também ajuda a ter uma melhor compreensão sobre como conseguir uma solução para o que ele precisa, ele faz parte de uma rede de pessoas, que trabalham e interagem de diversas formas, como essa rede de pessoas interagem com a ferramenta ou com o problema?
É preciso dizer que nem sempre seu usuário conseguirá expressar suas reais necessidades, lembra da história da avenida com buracos (clique aqui caso não tenha visto), seu usuário pode dizer que a necessidade que ele tem é que a rua seja recapeada, quando, na verdade, o que ele precisa é que o trânsito de veículos pesados naquele local seja proibido, visto que são eles que causam os buracos contínuos na avenida, ou ainda, que o material que o asfalto da avenida está sendo feito, seja trocado por outro porque devido às chuvas fortes o asfalto sofre erosão.
Seguindo esta linha, ouça o que o seu user tem a dizer, colete seu feedback, teste suas ideias com ele, observe ele interagindo com as suas ferramentas ou soluções, veja como ele se comporta, o que ele julga que pode melhorar, o que ele não disse que pode melhorar, mas você observou durante o processo.
Basicamente você pode dividir a observação em um grupo de quatro grandes perguntas:
- Quem são nossos usuários?
- Qual o contexto?
- Quais são suas necessidades? (as que ele pensa que tem, e as que realmente tem)
- Qual seu feedback?
Durante os processos do projeto, com os insights que as pesquisas trazem, mais as novas ideias que vão surgindo para solucionar o problema, é um tanto comum que as equipes tenham tendencia a se desalinharem em seus objetivos. A etapa da reflexão serve justamente para que todos se mantenham com um mesmo propósito.
Refletir é sobre sintetizar ideias e compartilhar o que estão pensando sobre, de modo a criar um pensamento unificado para alcançar o objetivo pretendido. Nessa etapa é necessário novamente que a empatia esteja findada entre a equipe, e também que os membros sejam flexíveis para ouvir ideias fora da sua zona de conforto, sendo estas positivas ou negativas.
A reflexão também se faz necessária quando algo do contexto do projeto que estão trabalhando muda. Se a situação agora difere, aquelas ideias conversadas anteriormente precisam ser reavaliadas, porquê podem ter perdido a relevância no atual momento.
Está é uma etapa que deve ser realizada com uma certa frequência, pois é ela que garante que todos estejam alinhados para conquistar a mesma meta.
Basicamente você pode dividir a observação em um grupo de quatro grandes perguntas:
- Qual a nossa realidade?
- Nós estamos alinhados?
- O que estamos fazendo?
- Qual o nosso plano?
É chegada a hora de colocar a mão na massa e realmente fazer. Por mais que assuste muitas vezes, executar uma ideia mesmo com a incerteza de se a mesma está clara, se é palpável o suficiente se faz necessário. Colaborar com a sua equipe de modo a trazer mais ideias pode fazer com que os melhores insights apareçam, afinal já dizia nossos pais "várias cabeças pensam melhor que uma".
Ideias realizadas passam a ser resultados no final do dia, e no EDT quanto mais rápido você executar suas ideias, mais tempo terá de aprimora-las, melhorá-las, testá-las, entender como seu user a utiliza, o que está faltando e o que pode ser retirado.
Sobretudo, não tenha medo de errar. É errando que se aprende e se melhora.
Não espere uma ideia perfeita, isso não existe. O máximo que irá acontecer é você ficar parado na fase das análises e observações sem executar nada de concreto. Execute, descubra o que funciona e o que não funciona, chame outras pessoas para colaborar com você, para analisar o que você tem e recriar, e adicionar novas perspectivas próprias.
Portanto, mostre seus pontos através de uma imersão na jornada do seu user, divulgue seus objetivos, mostre o porquê o que você pensou é importante.
E finalmente, faça se protótipo, não necessariamente você precisa de um em alta fidelidade, protótipos de baixa fidelidade tem um baixo cute e podem te ajudar a validar algumas hipóteses. O protótipo ideal é aquele que te permite conseguir o feedback que você precisa.
Saiba que absolutamente tudo pode ser um protótipo, até mesmo soluções para um determinado mercado. Entretanto, tenha em mente que você vai aperfeiçoar, melhorar, entender o que funciona e o que não funciona observando seu protótipo em funcionamento, a partir dele você poderá ajustar o curso e trabalhar em detalhes da sua solução.
- O que é possível?
- Qual é a história?
- Qual é o conceito?
- Como entregamos?
Temos o Loop completo com essas três fases, mas não pense que ao chegar no fazer o mesmo se encerra. Ele é constante, você observa, reflete e faz durante todo seu projeto. A cada avanço, mudança de contexto, aplique esses conceitos e você terá um projeto consistente baseado no Enterprise Design Thinking da IBM.
Nós estamos sempre estudando e trazendo conteúdos relevantes do mercado de design e comunicação para vocês. No próximo artigo falaremos sobre as Chaves do EDT, se você não quer perder essa explicação, não deixe de seguir o nosso blog.
Todas as informações aqui contidas foram retiradas do Enterprise Design Thinking da IBM e você pode consultar mais dados aqui.
