Salvando o Produto X - Um Estudo de Caso de Design Thinking

O que é Design Thinking?

Imagine que você tem uma ideia. Você cria um aplicativo engenhoso que acha que resolverá seus problemas de negócios. Atualmente, não existem soluções idênticas no mercado e a mais semelhante não está realmente funcionando da maneira que os clientes esperam.

Enquanto sua visão ainda está fresca, você começa a pensar na primeira pergunta fundamental que vem à mente: “Quanto tempo levará para realizá-la?”

E como raramente nos encontramos com orçamento e tempo ilimitados, a segunda pergunta consequente vem rapidamente: “Quanto me custará fazer isso?”

Ambas são questões fundamentais e cruciais na fabricação de um produto, mas muitas vezes são precisamente as perguntas erradas para começar.

Em vez disso, a pergunta mais importante a ser feita primeiro é: “Que valor posso criar para meus usuários?”

Para entender melhor o escopo de um projeto, requisitos e tempo, podemos usar uma metodologia chamada “Design Thinking”, que nos ajuda durante a “Fase de Descoberta” de um produto. Este é exatamente o momento em que precisamos entender não apenas o que fará um ótimo produto, mas também como e se devemos fazê-lo. Essa abordagem criativa e experimental nos ajuda a entender melhor como criar coisas que não são apenas usáveis, mas, acima de tudo, úteis.

O processo de Design Thinking é particularmente útil porque gera um resultado único e específico: o conhecimento.

Esta metodologia tem um escopo de uso mais amplo, mas para os propósitos deste Estudo de Caso de Design Thinking, focaremos apenas em um campo específico - Desenvolvimento de Produto de Software.

A Teoria do Design Thinking

Antes de nos aprofundarmos nas aplicações práticas do Design Thinking e na minha experiência em aplicá-lo, vamos dar uma olhada mais profunda no processo de Design Thinking.

Design Thinking é uma metodologia que fornece uma abordagem baseada em soluções para resolver problemas. Ele se concentra em entender a perspectiva do usuário, com um ponto de vista centrado no ser humano. O poder dessa metodologia é a possibilidade de testar rapidamente se uma ideia, solução ou aprimoramento pode trazer resultados reais para nossos clientes. Integrando diferentes metodologias, ferramentas e técnicas provenientes de diferentes áreas (marketing, psicologia, design, negócios), o objetivo do Design Thinking é colocar o usuário no centro do problema que temos que resolver.

O objetivo da metodologia é “encontrar o próprio usuário e definir suas necessidades” e, encontrando essas necessidades, criar uma solução ou um produto que possa ser realmente útil. Para atingir esse objetivo, todo o conceito é dividido em seis fases de design thinking.

1. Empatia: O objetivo desta fase é entender o seu cliente, pesquisando e reunindo informações sobre o seu negócio. Durante esta fase, podemos usar várias ferramentas diferentes, como entrevistas, grupos focais, observações e pesquisas.
2. Definir: Nesta fase, coletamos e categorizamos informações da fase de empatia. É aqui que definimos User Personas e User Journeys.
3. Idealizar: Usando as informações acima, aqui a equipe idealiza soluções. Não existem ideias tolas ou erradas! Tudo deve ser expresso e documentado.
4. Protótipo: Durante esta fase, é criado algo tangível, que lhe permitirá verificar a sua ideia na vida real. Não complique demais e crie este MVP o mais rápido possível.
5. Teste: verifique sua ideia na vida real com usuários reais. Obter feedback. Faça perguntas sobre como melhorá-lo.
6. Implementar: Esta é a fase em que todo o conhecimento coletado é traduzido em um produto final.

Se depois de ler isso você pode estar pensando: “Isso é ótimo, mas como isso ajudará a tornar meu aplicativo rapidamente uma realidade”. Para tornar isso mais tangível, vou analisar um estudo de caso da minha experiência pessoal que se beneficiou do processo de design thinking.

Design Thinking Aplicado - Um Estudo de Caso da Vida Real

Introdução: Projeto X

Algum tempo atrás, encontrei-me em uma reunião com um empresário, alguns gerentes e muitas ideias voando pela sala. Seu concorrente direto havia lançado recentemente um novo aplicativo e a tensão era palpável. A empresa queria sair com algo novo no mercado, para não perder espaço para o concorrente.

Eles prepararam um documento com alguns requisitos, uma vaga ideia de como deveria ser o produto e quanto deveria custar.

“Temos que seguir o que os outros fizeram, com preço menor”, ​​disse o diretor de marketing. “Temos que criar um sistema mais usável, que simplifique a jornada do usuário”, acrescentou outro gerente. “Temos que mudar a forma como coletamos informações, simplificá-las e integrar nossos processos com terceiros”, disse outro. “Vamos levar meses”, o gerente técnico balançou a cabeça, que traduziu mentalmente todas aquelas solicitações em centenas de horas de código a ser implementado.

Embora eu não possa divulgar todos os detalhes do projeto, posso divulgar que o produto era um software de comunicação central. Este software gerenciava diferentes canais (e-mail para SMS, fax para VoIP) e foi criado para as plataformas web e mobile. O produto foi originalmente criado alguns anos antes, mas sua usabilidade era ruim. Na época do lançamento, o concorrente estava muito à frente em termos de experiência do usuário. Além disso, eles tinham um excelente aplicativo móvel, que estava ganhando espaço na loja de aplicativos móveis.

A empresa X era uma empresa tradicional orientada a processos, familiarizada com projetos tradicionais. Ela havia executado alguns projetos Agile no passado, mas era nova a ideia de criar um MVP e testá-lo no mercado. Mais notavelmente, eles temiam o desconhecido. E se o novo MVP tivesse um efeito indesejável ou imprevisível em sua base de usuários de clientes? Essa falta de controle não inspirava confiança.

A reunião descrita acima e as seguintes não levaram a uma definição clara do que realmente era o produto a ser alcançado. Só sabíamos que tínhamos que acertar o alvo o mais rápido possível.

No entanto, à medida que o projeto avançava e um concorrente começava a ganhar força, o consentimento da empresa se solidificava. A maioria concordou com a ideia de que: “Não podemos nos dar ao luxo de lançar um produto semi-acabado, precisamos de um produto que esteja funcionando desde o início”.

Apesar de alguma perplexidade e medo inicial, esta foi uma oportunidade de aprender o que traria valor real para sua base de usuários e potencialmente atrair mais usuários, criando um produto leve e simplificado.

Isso levou a empresa a buscar abordagens que não haviam tentado antes, a fim de ter um produto completo construído na hora, mesmo que tenha apenas recursos essenciais em seu lançamento. Decidimos usar o processo de Design Thinking e focar nas coisas que realmente trariam valor para o usuário final e, assim, vencer a concorrência trazendo apenas o necessário para o cliente.

Estágio 1 - Empatia

Fase de empatia: O objetivo desta fase é entender o seu cliente, pesquisando e reunindo informações sobre o seu negócio. Durante esta fase, podemos usar várias ferramentas diferentes, como entrevistas, grupos focais, observações e pesquisas.

No sentido mais literal, a empatia é a capacidade de entender e compartilhar as emoções dos outros. No design thinking, a empatia é uma “compreensão profunda dos problemas e realidades das pessoas para quem você está projetando”.

Nosso primeiro passo foi garantir que a opinião da pessoa mais bem paga (também conhecida como HiPPO) não prevalecesse sobre a de todos os outros. Por isso, em conjunto com os gestores e o fundador, compilamos uma lista de possíveis stakeholders a serem envolvidos no processo decisório.

Em uma reunião de um dia inteiro, compilamos a primeira lista de 30 nomes (entre funcionários, gerentes funcionais e clientes) que poderiam ser contatados diretamente e, em seguida, também escolhemos um público-alvo de 4.000 clientes (cerca de 10% de seus clientes recorrentes base).

Tentamos “normalizar” nossa base de clientes-alvo o máximo possível, incluindo a diversidade em termos de distribuição de gênero, setor e outros pontos de dados. Para adicionar um nível adicional de complexidade, a localização física da amostra a ser entrevistada foi dividida em diferentes cidades e, em alguns casos, países. Passamos a contar com pontos de contato para realização de entrevistas e questionários.

O grupo foi organizado para realizar as entrevistas remotamente, seguindo um roteiro de perguntas e algumas regras básicas:

• Durante a entrevista, tente usar a técnica dos “5 Porquês”.
• Tente entender o principal “O que, como, por que” por trás de cada comportamento.
• Certifique-se de que o entrevistado usou uma webcam e que havia distância suficiente da câmera para poder incluir, pelo menos parcialmente, a linguagem corporal.
• Grave todas as entrevistas, caso precisem ser vistas no futuro.

Preparámos as questões da nossa entrevista com o intuito de perceber quais as principais funcionalidades que deveriam ser melhoradas ou eliminadas, para que pudéssemos construir rapidamente uma nova versão que respondesse às necessidades dos nossos utilizadores.

Para o segundo grupo de usuários, preparamos uma série de perguntas em um formulário do Google. Optamos por perguntas de múltipla escolha, com algumas perguntas abertas formuladas para facilitar mais interação dos usuários, incluindo uma pergunta que exige que o usuário experimente a nova versão do produto disponível apenas em beta fechado.

Para organizar todo o processo de coleta de informações, usamos ferramentas remotas que permitiram à equipe coletar informações com mais facilidade, incluindo Skype, Zoom, Google Forms e um Quadro Kanban digital onde colocamos todas as nossas atividades e acompanhamos seu status.

Os primeiros resultados das entrevistas foram animadores, pois os entrevistados estavam abertos a fornecer feedback sobre os pontos fracos e os pontos fortes do sistema.

No entanto, o primeiro lote de respostas ao questionário foi muito menos emocionante: de todos os 300 e-mails enviados, apenas 5 pessoas preencheram seus questionários.

Decepcionados com esse resultado, estávamos prontos para tentar novas formas de envolver a base de usuários, quando um dos gerentes de vendas nos procurou com uma ideia:

“Acho que eles não vão responder nenhum e-mail, não estão acostumados a interagir conosco. Mas, se nos comunicarmos com todos aqueles que têm uma renovação que está expirando e lhes dermos um pequeno incentivo, tenho certeza que eles nos darão uma mão”.

A ideia era simples, mas excepcional. Em poucas horas, tivemos uma nova lista de usuários (3800), que manteve a mesma divisão entre o mainstream e os extremos. No entanto, esses usuários seriam “obrigados” a interagir com o sistema, devido à proximidade de sua renovação.

Desta vez, eles foram convidados a responder a uma série de perguntas, participar do beta e, em troca, ganhar um desconto na renovação. A adesão foi completa e na primeira entrega deste novo modelo, mais de 70% dos usuários responderam e preencheram o questionário.

Após iterar e alterar algumas das perguntas, e graças a alguns usuários dispostos a entrevistar mais de uma vez, estávamos prontos para definir nossa base de usuários com mais clareza.

Etapa 2 - Definir

Estágio de Definição: Nesta fase, coletamos e categorizamos informações da fase de Empatia. É aqui que definimos User Personas e User Journeys.

O significado de definir no dicionário é determinar a identidade e as qualidades essenciais de uma noção . No nosso caso, queríamos definir o seguinte:

• nossos clientes ideais
• seus problemas
• as soluções para seus problemas
• as necessidades e medos de nossos clientes que tivemos que abordar

Nos termos do design thinking, a fase de definição é onde você analisa suas observações e as sintetiza em problemas centrais que você identificou.

Tínhamos um banco de dados suficiente para entender quais eram os problemas reais. Além do feedback recebido na fase de Empatia, continha pontos que foram destacados pelos colaboradores da Empresa X, mas nunca haviam sido apontados para a gestão, além de pontos fortes, pontos fracos e outros problemas que nunca foram levados em consideração.

A próxima ação foi criar nossas User Personas. Durante esta fase de brainstorming, envolvemos toda a equipe estendida. A fase de brainstorming sempre foi realizada remotamente, utilizando sistemas e ferramentas de videoconferência para acompanhar as personas e sua criação em tempo real.

Para cada Persona, identificamos sua biografia, sua abordagem à tecnologia, seu uso de mídias sociais, marcas preferidas, suas necessidades e ideias e especulamos sobre qual teria sido sua jornada do cliente.

Depois disso, selecionamos as User Personas do cliente comum e tínhamos um conjunto final de dados provenientes de entrevistas e pesquisas. Este era o momento certo para sujar as mãos.

Durante a fase de definição, tentamos transformar uma definição genérica de um problema como “Precisamos de um produto que aumente nossas vendas em 10%”, em uma solução mais específica como: “Homens e mulheres adultas, entre 35 e 45 anos que estão trabalhando em um escritório precisam receber comunicações que tenham validade legal para ter certeza de que o remetente é realmente quem eles dizem ser.”

Nesse ponto do processo do projeto, concluímos sessões de brainstorming em torno de nossos usuários, soluções hipotéticas e mantivemos a mente aberta para todas as inovações possíveis. “A única ideia estúpida é aquela que nunca foi expressa” era o mantra.

Em pouco tempo, tendo em mente quem eram nossos sujeitos, tivemos uma visão clara do que era útil para nossos usuários, além de quais necessidades e medos devemos abordar ao longo da jornada do cliente.

Em seguida, nos engajamos na construção de um “Mapa da História do Usuário”, que nos permitiu categorizar o processo dos usuários, mapeando os temas. Para cada uma das personas, definimos o conjunto de atividades, histórias e tarefas que assumimos que elas deveriam completar durante a jornada. Ao fazer isso, pudemos testar rapidamente nossa ideia e entender se ela atendeu às necessidades principais. Se isso acontecesse, poderíamos trazê-lo para o mercado mais rápido do que todos os outros, o que era essencial, pois nosso concorrente estava se tornando mais bem-sucedido a cada dia.

Etapa 3 - Idealizar

Fase de Ideação: Usando as informações acima, aqui a equipe idealiza soluções. Não existem ideias tolas ou erradas! Tudo deve ser expresso e documentado.

Um passo além da definição é a fase de Ideação, onde a chave é formar conceitos e soluções reais, não apenas definições abstratas.

Em termos de design thinking, ideação é “o processo em que você gera ideias e soluções por meio de sessões como Sketching, Prototyping, Brainstorming, Brainwriting, Pior Idea Possível e uma variedade de outras técnicas de ideação”.

A nossa equipa era completamente remota, pelo que decidimos continuar a trabalhar de forma Lean na produção de materiais e na sua revisão. Por exemplo, designers e outros membros da equipe concordaram que, para ser o mais rápido possível, a melhor solução seria começar com desenhos em papel e compartilhar fotos deles no grupo. Só assim produziríamos os designs mais interessantes em Balsamiq ou Axure.

Para cada sketch produzido, recolhíamos informação dos utilizadores, definimos um conjunto de soluções e voltávamos a esses utilizadores (sempre que possível e com a maior frequência possível) para testar com eles o processo e o resultado.

Etapa 4 - Protótipo

Fase de Prototipagem: _ Durante esta fase, é criado algo tangível, que lhe permitirá verificar a sua ideia na vida real. Não complique demais e crie este MVP o mais rápido possível. _

Durante a fase de protótipo, finalmente chegou a hora de dar vida às nossas definições e ideias. Um protótipo é o primeiro modelo original de um produto proposto, e é exatamente isso que nos propusemos a construir. Pelos padrões de design thinking, o estágio de protótipo é onde você cria versões baratas e reduzidas do produto real para investigar soluções dos estágios anteriores.

Após quase 10 dias do início da nossa jornada, chegamos ao momento crucial, uma reunião com uma equipe de desenvolvedores onde tivemos a chance de verificar nossas premissas e estimativas. Após uma sessão de consulta e definição com a equipe de desenvolvedores, ponderamos as histórias e entendemos que o grande esforço do trabalho de desenvolvimento será no desenvolvimento do sistema back-end e na interface com os sistemas legados atualmente em vigor. Além disso, também percebemos que criar os sistemas front-end será um exercício muito mais curto. Assim, decidimos criar um protótipo front-end utilizando os componentes que já existiam no sistema para economizar tempo.

Tínhamos um prazo de 3 dias para ter uma primeira versão do protótipo pronta. Este protótipo tinha que refletir o produto o máximo possível e manter a funcionalidade necessária.

Após 3 dias, tínhamos nossa primeira versão do protótipo pronta. Tinha dados “falsos” que refletiam o comportamento do software que pretendíamos criar. Faltavam alguns elementos acessórios, mas o software naquele estado representava visualmente uma boa porcentagem do conteúdo total planejado.

Ao final de duas semanas de trabalho, tínhamos um software que poderíamos experimentar e testar com usuários reais. Usamos um software de monitoramento da experiência do usuário para analisar mapas de calor e atenção do usuário, enquanto eles navegavam em nosso protótipo.

Etapa 5 - Teste

Fase de teste - Verifique sua ideia na vida real com usuários reais. Obter feedback. Faça perguntas sobre como melhorá-lo.

Após as fases de definição, ideação e protótipo, finalmente chegou a hora de ver se o nosso produto realmente funcionava na vida real. Em termos de design thinking, testar significa testar o produto completo usando as melhores soluções criadas na fase de prototipagem.

No nosso caso, a fase de teste não ocorreu apenas no final, mas foi um loop constante de feedback e iteração sempre que possível. Ao final de cada etapa realizada, tentávamos obter feedback de usuários ou clientes, antes de nos convencermos a passar para a próxima fase.

Concluído o protótipo, era hora de testá-lo com o maior público possível e verificar com eles a eficácia com que ele atendeu às suas necessidades, entender sua percepção e entender se atingiu seus objetivos.

A fase de teste incluiu especificamente um protótipo de passo a passo onde os usuários puderam ver o novo fluxo de trabalho e realizar ações, juntamente com algumas sessões em que a equipe observou os usuários diretamente, enquanto rastreava suas respostas. Um questionário simples foi usado para coletar taxas de conversão em recursos específicos da plataforma, onde os usuários foram solicitados a pontuar o processo de 1 a 10.

A fase de testes foi posteriormente alargada a toda a equipa e mesmo a alguns indivíduos fora da organização (clientes e utilizadores) que, nas sessões anteriores, consentiram voluntariamente em dar o seu feedback sobre a implementação do sistema.

Os resultados deste teste foram animadores. Os stakeholders da Empresa X puderam não apenas ver as maquetes, mas também experimentar e “tocar” o produto pela primeira vez. A equipe estendida teve a oportunidade de testar e verificar suas suposições e corrigi-las ao longo do tempo no período de duas semanas.

Agora o teste final estava esperando: abri-lo para os usuários e entender o que aconteceria a seguir.

Etapa 6 - Implementar

Fase de Implementação: Esta é a fase em que todo o conhecimento coletado é traduzido em um produto final.

Tínhamos dados, ideias, personas e nosso primeiro protótipo tangível. Era hora de arregaçar as mangas e começar a desenvolver. Tivemos um mês e meio para implementar nosso novo sistema.

Definimos um conjunto de regras para implementar nosso MVP em um curto período de tempo:

• Construiremos apenas o que definimos, sem adicionar novos recursos.
• Vamos nos manter focados no objetivo principal do negócio.
• Usaremos metodologias ágeis dentro das equipes para gerenciar a carga de trabalho.

Para concluir o projeto a tempo, trouxemos alguns novos membros da equipe que não estavam envolvidos no projeto desde os estágios iniciais da fase de descoberta.

Adicionamos desenvolvedores de front-end, desenvolvedores de back-end e designers. Os novos membros da equipe estavam trabalhando remotamente e não foi possível trazê-los todos na mesma sala durante o período do projeto, por isso garantimos que temos as ferramentas certas para manter a comunicação.

O processo implementado para gerenciar o trabalho foi ágil. Dividimos o tempo restante em vários sprints curtos, com reuniões remotas todos os dias e atualizações via Slack durante o dia para trocar ideias e ajudar uns aos outros na resolução de problemas.

Não tínhamos uma documentação completa armazenada em algum lugar, mas mentalmente todos tínhamos um conjunto abrangente de ações, uma visão comum compartilhada e objetivos entre a equipe. Todos começamos a perceber as User Personas como um usuário real, com suas próprias necessidades e problemas. Assim que nossa equipe começou a ter uma visão alinhada, passamos a definir o que precisava ser feito e quando para terminar o projeto no prazo.

As atividades foram delineadas dentro de um User Story Map, para manter a evidência original das personas e o fluxo que queremos dar ao produto.

Os mapas de histórias de usuários foram criados por meio de três etapas claras: identificar as atividades, identificar as etapas necessárias para concluir a atividade e a lista de histórias/tarefas associadas a cada uma. Classificamos as histórias de acordo com a prioridade (Must, Should, Could), que ditava quais componentes seriam incluídos no produto.

A equipe conseguiu avançar em ritmo acelerado desde o início da implementação, graças a uma visão clara compartilhada pela equipe e pelo método que empregamos, que permitiu que a equipe se mantivesse no caminho certo sem orientação direta da gestão acima. Todos que trabalhavam no projeto tinham em mente as perguntas das etapas do Design Thinking:

• Que ação cada usuário dentro de nossa plataforma deve realizar e o que eles estavam tentando alcançar?
• Quais etapas esses usuários devem seguir para atingir a meta final?
• Quais pontos de dor eles tinham antes e como devemos evitá-los?

Isso permitiu que nossa equipe tomasse suas próprias microdecisões e direcionasse o produto para seu objetivo final.

Fizemos duas revisões do trabalho em andamento no final de cada sprint e uma revisão final da versão no final do caminho, antes que o produto fosse finalmente colocado em produção. Usamos o último sprint para preparar a infraestrutura necessária para executar e lançar o produto.

Por fim, os usuários que usaram nosso produto antigo foram novamente convidados a experimentar a nova versão. Nosso produto foi lançado em produção dois meses após a reunião em que foi expressa a ideia de fazê-lo. O produto funcionou, os usuários começaram a usá-lo e progressivamente enviamos mais novos usuários para essa ferramenta em vez da antiga. Os testes A/B nos mostraram que eles preferiram o novo produto, e o projeto foi aceito na empresa como um grande sucesso.

Mais importante, uma metodologia de Design Thinking foi finalmente aceita. Acreditamos que isso terá um impacto bom e duradouro e permitirá que eles construam produtos melhores no futuro.

Conclusão

Ao longo deste estudo de caso, mostramos como a metodologia Design Thinking pode ser aplicada a um problema da vida real com tempo e orçamento limitados.

Em vez de usar abordagens mais tradicionais e produzir coisas em etapas sequenciais, optamos por iterar pelos seis estágios de design thinking. Simpatize. Definir. Idealizar. Protótipo. Teste. Implemento. Isso se tornou nosso mantra e nos permitiu produzir um produto muito bem recebido.

O uso do Design Thinking permitiu economizar tempo e, por sua vez, economizar custos gastos no projeto. Não estávamos trabalhando em milhões de recursos diferentes, mas apenas em poucos, ações bem pensadas e claras para todos na equipe. Mais importante ainda, fomos capazes de entregar o produto e o valor que os usuários precisavam.

Usar o processo de Design Thinking nos ajudou em muitas áreas diferentes:

• Do ponto de vista do gerenciamento de projetos, permitiu-nos definir claramente o escopo do projeto e evitar o aumento do escopo.
• Do ponto de vista do negócio, permitiu-nos escolher as características que trazem o valor real para o negócio.
• Do ponto de vista do desenvolvimento, isso nos ajudou a ver o objetivo claro do que temos que construir antes mesmo de começarmos a construí-lo.
• Do ponto de vista da equipe, envolveu todos os membros da equipe e permitiu que eles trabalhassem efetivamente juntos e tivessem sua opinião ouvida em todas as partes do processo.

Quando iniciamos o processo de Design Thinking fomos recebidos com ceticismo pelo cliente, mas quando terminamos e recebemos o feedback de nossos clientes, ficou imediatamente claro que as etapas que traçamos nos ajudaram a alcançar algo que teria sido muito difícil ou impossível de outra forma. Isso foi valorizado pelo cliente e tornou seu projeto interno um carro-chefe para os desafios futuros que se avizinham.