Design Sprint Conversacional na prática
Como fizemos pra ganhar velocidade na entrega de uma funcionalidade importante pro Whatsapp da empresa.
Quem trabalha em produtos digitais sabe: muitas vezes o tempo é escasso. Ou melhor, quase sempre o tempo é escasso. Entre novas funcionalidades, acompanhamento de métricas e correções urgentes, convenhamos que manter uma estratégia alinhada com o seu time e a empresa é essencial.
E o que vamos falar aqui tem tudo a ver com isso.
Esse é um dos artigos de base da minha palestra no encontro presencial da comunidade Bots Brasil que aconteceu em São Paulo, dia 15 de Julho de 2023. Depois de ler, dá uma conferida 😄
Agora, de volta pro texto. Boa leitura!
O contexto
Trabalhamos em uma squad (time de produto) cujo objetivo é manter o WhatsApp da empresa com a melhor experiência possível e dar o retorno financeiro que ela precisa. Pra isso, contamos com a união da galera de produtos, desenvolvimento, UX, qualidade e curadoria. Rituais em dia, comunicação ativa e cada parte entregando o que se espera, mas…
Uma hora aperta:
“Precisamos dessa nova funcionalidade em produção o mais rápido possível.”
Essa frase é real. Isso aconteceu porque era importante pro negócio e pegou o time desprevenido. E agora?
Calma. O design tem ferramentas pra isso. É hora de colocar em prática o que toda pessoa designer cresce escutando (ou pelo menos deveria): ser ponte, não muro.
A Design Sprint Conversacional
De praxe, a ideia da Design Sprint é entender o problema, criar alguma solução que possa funcionar, testar pra ver sua efetividade e tirar algum aprendizado disso. Tudo isso, na teoria, em até 5 dias.
Ou seja: errar e aprender o quanto antes, pra conseguir criar uma solução junto das áreas de negócio envolvidas.
“Mas eu trabalho com uma interface conversacional. Só tem texto! Como faz?”
A ideia é a mesma. Mas o contexto é de um produto ou serviço que tem que virar uma conversa escrita. E é aí que fica legal!
Na prática que vou usar de exemplo, aplicamos a Design Sprint Conversacional em 4 dias usando como teste a técnica do Mágico de Oz.
Tá pronto? Então vamos nessa!
Tendo como base os 4 dias, separamos cada dia pra uma finalidade.
Dia 1 — Mapear
No primeiro dia da semana, o principal é alinhar com sua squad (time de produto) quais atividades vão ser executadas ao longo da semana e quais são as dúvidas, suposições e certezas que temos até então.
Ah, aqui eu tô falando de preencher a matriz CSD mesmo, tá?
Pra ajudar, essas são algumas perguntas que precisam ser respondidas nesse momento:
- Existem outras empresas que já praticam a funcionalidade em questão? Como fazem?
- Temos alguma pesquisa interna que pode ajudar a entender melhor nosso contexto?
- Quais áreas precisam participar da construção da solução?
- Quem são os especialistas que podem ajudar a responder nossas dúvidas?
- Como vamos conduzir nossas dinâmicas?
- Que perfil de clientes vamos chamar pra testar a solução? Conseguimos alguém disponível pra data que a gente quer?
Dia 2 — Rabiscar (manhã)
É hora de colocar todas as pessoas selecionadas numa sala — ou chamada de vídeo, como foi nosso caso. Temos perguntas precisando de respostas e regras de negócio que precisam ser atendidas. E esse é o momento.
Hora de ser ponte.
Essas são as áreas que escalamos pra esse momento:
Nessa etapa, temos que garantir que:
- Todas as pessoas envolvidas estejam alinhadas quanto ao objetivo da reunião;
- Todas as perguntas sejam respondidas;
- Todos os cenários que envolvem a solução sejam mapeados;
- Todas as pessoas sejam ouvidas.
Dia 2 — Rabiscar (tarde)
Agora que estamos alinhados e por dentro do que precisamos, hora de criar um fluxo conversacional mais macro. Ou seja, que passos, validações de negócio e interações vão ocorrer ao longo da jornada da pessoa usuária dentro desse fluxo?
Ao longo dessa construção, é normal que ainda mais dúvidas surjam. E tá tudo bem 🙃
Faça questão de ir anotando tudo pra ir atrás da resposta depois, você vai precisar.
Com o macro fluxo finalizado, é o momento de dar vida aos detalhes e construir a conversa em si.
Como tínhamos pouco tempo, acabamos optando por construir o micro fluxo apenas do caminho feliz e uma ou outra mensagem geral de erro.
Mas lembra: mantenha o tom de voz da empresa, as boas práticas de escrita e, claro, respeite as heurísticas de Nielsen.
Dia 3 — Testar
Agora sim: hora do show. Com o micro fluxo pronto e as pessoas que vão testar já com os horários agendados para o dia, é hora de ir pro teste de Mágico de Oz.
Veja no seu time quem topa ajudar nesse processo. É sempre interessante e pode ser até divertido participar dessa etapa.
Nesse teste, enquanto uma pessoa se passa pelo robô de atendimento da empresa, a outra fica interagindo com a pessoa usuária e colhendo suas percepções e entendimentos sobre o que tá sendo apresentado.
Anotem tudo pra compilar os resultados depois, combinado? 🤓
Dia 4 — Apresentar o que aprendemos
Ufa! Temos as percepções do que funcionou e o que pode melhorar. Digo mais: isso foi feito sem desenvolver nada e fazendo todas as pessoas envolvidas serem, de fato, ouvidas!
Então, é hora de mostrar pra todo mundo o que aprendemos e como ficou a proposta da solução final.
Chegou até aqui? Boa, você foi ponte!
Tentar chegar numa solução que agrade outras pessoas, áreas e o próprio negócio não é fácil. A gente sabe disso.
Mas sabe o que também não é fácil? Fazer um produto dar certo sem trabalhar em equipe 😅
Nota do autor (1): o case apresentado contou com a ajuda de muitas pessoas incríveis. Nada foi feito sozinho. Repito: nada.
Nota do autor (2): muito desse desenvolvimento foi inspirado no módulo ‘Design Sprint Conversacional’ , apresentado pela Valéria Romano no curso Design Conversacional da Arara School. Valeu, Arara e Valéria!
E aí, quer trocar uma ideia mais a fundo sobre esse processo todo? Me chama!
E se curtiu, deixa sua palminha aqui 🥰
Aquele abraço!
