Janeiro 17, 2024
21 Minutes

Neste artigo vou compartilhar como adaptamos a Sprint de Design às dores de negócio. O trabalho teve como objetivo estruturar uma ideia, validada e testada pelos usuários, que colaborasse para melhorar os índices de ativação de um produto.

Antes de começar vale explicar o que é uma Sprint ou Sprint de Design, um método desenvolvido/adaptado pelo Google Ventures, para testar e aplicar novas ideias, em um curto espaço de tempo, passando por cinco fases e têm como foco reduzir riscos ao desenvolver um novo produto, serviço ou recurso ao mercado.
As etapas do processo são:

  • Entendimento do problema e definição da dor chave que será trabalhada;
  • Processo de co-criação para levantamento de ideias com potencial de resolver a dor definida;
  • Decisão da ideia que melhor atende a dor da pessoa usuária do produto, serviço ou recurso;
  • Prototipação simplificada da ideia que foi projetada;
  • Validação da solução para que seja avaliada a aplicabilidade da solução para a dor identificada.

Nessa experiência ajustamos o tempo da Sprint para 11 dias, pois trabalharíamos com dias intercalados (segundas, quartas e sextas) com duas sessões pela manhã, incluindo um intervalo de 30 minutos, e no período da tarde uma sessão mais extensa dedicada às tarefas individuais de aprofundamentos e alinhamentos com outras áreas.

PRE-WORK

Dia 0

A etapa de pré-work, dedicada a organização do processo, foi importante para contextualizar o grupo sobre a abordagem da Sprint. Esse momento também foi necessário para esclarecer a função de cada membro no grupo de trabalho, definição de materiais necessários para as etapas seguintes, apresentar ferramentas, esclarecer o objetivo do trabalho e alinhar expectativas e cerimônias.

Ferramentas usadas: Miro, Google Drive, Google Planilhas, Google Apresentações, Google Documentos e Trello.

Importante: Nesse momento já buscamos reforçar com as pessoas a importância do pensamento colaborativo e otimista durante todo o processo, além de se permitirem duvidar dos problemas já existentes.

ENTENDIMENTO

Dias 1, 2 e 3

A fase de imersão trouxe ao grupo o contexto dos principais motivos que impactavam a ativação do produto. Foi o momento em que compartilhamos estudos, pesquisas, relatórios, processos de diferentes áreas, para que todos pudessem equilibrar os conhecimentos e identificar possíveis caminhos que poderiam colaborar para a definição do problema.

É um momento de exposição de dados, opiniões baseadas nas informações levantadas, captura de hipóteses e dúvidas do problema.

A Matriz CSD foi fundamental nesse processo, pois deu clareza a todas as nossas certezas, além colaborar para a criação das novas suposições e questionamentos que precisavam ser esclarecidos.

Modelo
Matriz CSD

Chegamos nas respostas e validação das hipóteses através de pesquisas qualitativas e quantitativas com clientes, pesquisas na internet (Desk Research) e análise de concorrentes.

Com os resultados consolidados em mãos, tivemos mais clareza do contexto das pessoas usuárias, bem como perfis, principais dores, objetivos, pensamentos e percepções.

Lições aprendidas:

É natural que neste momento surjam muitas ideias, pois temos contato com diversas dores e a ação natural das pessoas é pensar numa solução, mas como teríamos um momento dedicado a co-criação, guardamos em um estacionamento de ideias (Parking lot) para que não se perdessem e fossem aplicadas no momento certo da Sprint.

A imersão traz muita discussão e abundância de informações, por isso vale reforçar o foco do trabalho, que no nosso caso era melhorar a ativação de um produto e identificar o momento certo de seguir para a próxima etapa, que foi a Definição do problema.

A seleção de pessoas que conheciam sobre o problema tratado foi determinante para chegarmos no melhor resultado dentro do tempo que definimos.

Durante todo o trabalho, é fundamental alinhar a expectativa com as pessoas envolvidas direta e indiretamente no processo para que saibam sobre as evoluções do trabalho. Um e-mail com uma atualização daquilo que foi finalizado e planejado funcionou bem para nós.

Ferramentas usadas

Miro, Google Planilhas, Google Forms, Desk Research, Benchmark, Matriz CSD, Card Sorting, Pesquisa Qualitativa, Pesquisa Quantitativa, User Story e Mapa de Empatia.

DEFINIÇÃO DO PROBLEMA

Dias 4 e 5

O momento de definição do problema, ou seja, a principal dor a ser atacada, pode gerar certa insegurança por ter existido uma grande discussão sobre diversos aspectos do objetivo da Sprint, que no nosso caso era o índice de ativação do produto. Entretanto, temos muitas informações internas e externas levantadas que podem embasar a decisão do grupo em declarar o foco para a fase seguinte de Co-criação. Para isso algumas ferramentas ajudaram na tomada de decisão, como a Matriz de Risco e Importância que enquadrar melhor o problema do ponto de vista do negócio, complexidade técnica (centrado no conhecimento do grupo) e relevância para o(a) cliente.

Outra ferramenta que usamos e colaborou para o entendimento do perfil dos(as) clientes foi a Persona (baseada em dados levantados na Imersão), tornando mais tangível o impacto do problema em suas experiências.

Modelo
Persona

No quinto dia, um exercício que fizemos foi definir indicadores que gostaríamos de monitorar ao final da Sprint para mensurar o impacto que a solução poderia trazer como NPS, tempo de ativação, Contact Rate entre outros.

Ao final desta etapa, para que ficasse claro para todos o problema foco da Sprint, fizemos uma declaração neste modelo:

“Conseguimos observar que (o problema) não consegue resolver as necessidades do (cliente/usuário) e que traz dificuldades em (determinado momento da jornada).”

Ferramentas usadas

Miro, Matriz de Risco e Importância, Persona, Matriz CSD, Declaração e Definição do problema, Metas, Métricas e Indicativos e Sucesso.

IDEAÇÃO

Dia 6

Foi uma das etapas mais divertidas e colaborativas do trabalho, além de ser muito relevante para sairmos com boas propostas para as fases seguintes de Decisão e Validação com os clientes.

Uma vez declarado o problema, tivemos a necessidade de torná-lo uma oportunidade e para isso usamos a ferramenta How Might We, que estimula os participantes a formularem perguntas, baseadas na declaração do problema. Nesse processo chegamos em mais de 30 perguntas que, a partir de uma votação silenciosa (Zen Voting) chegamos na principal pergunta. A pergunta mais votada norteou o nosso processo de ideação, assim como a declaração do problema e o objetivo da Sprint.

Para a ideação escolhemos a ferramenta Crazy 8’s, que basicamente estimula os participantes a pensarem em 8 ideias diferentes e 1 minuto.

É bem divertido ver as pessoas desenhando soluções em um curto espaço de tempo, quebrando pensamentos limitantes e pensando em soluções jamais imaginadas.

Para finalizar, consolidamos e aprimoramos ideias semelhantes, fizemos uma nova sessão para criação de uma storyboard adicionando nome, contexto, dor e solução de participante.

Modelo
Storyboard

Lições aprendidas:

A etapa de imersão é embasada em exploração de dados, aprofundamento de relatórios e estudos, pesquisas com clientes, então por vezes as pessoas se sentem mais seguras sobre todo o processo. Quando desembarcamos na fase de co-criar, caso a proposta não esteja muito clara para os membros do grupo, é possível que exista certa resistência ou oscilação de engajamento. Portanto, é um momento de, mais uma vez, reforçar o pensamento otimista, colaborativo, sem bloqueios, além de mostrar o propósito de onde queremos chegar com o trabalho da Sprint, que é uma solução, validada pelos usuários, para resolver um problema específico, em um curto espaço de tempo e com baixo investimento.

É importante que depois da apresentação das ideias, todos descrevam os desenhos para que qualquer pessoa, mesmo aquelas que não fizeram parte do grupo de trabalho, entendam a solução sugerida.

Na dinâmica do How Might We, é necessário orientar os participantes que tomem cuidado para não incluírem soluções nas perguntas (que é bem comum acontecer).

Ferramentas usadas: Miro, How Might We, Crazy 8’s e Storyboard

DECISÃO

Dia 7

A fase de Decisão traz algumas escolhas difíceis, como definir a ideia que melhor se encaixa na dor identificada. A definição é ainda mais difícil quando temos diversas ideias excelentes. O facilitador tem um papel fundamental neste momento para fomentar no grupo a discussão da solução que melhor resolverá o problema, para que na etapa seguinte não se desenvolva o protótipo errado, ou que não atenderá o problema encontrado, afinal temos pouco tempo para todo o processo da Sprint de Design.

Na escolha da solução final fizemos uma nova votação, aplicamos em um Poster Conceito, detalhando as principais funções, resumo e ilustração final da ideia, indicadores de sucesso da solução e áreas necessárias para implantação da solução.

Modelo
Concept Poster

O último passo foi criar a versão final do Storyboard da solução detalhando o contexto do cliente, a principal dor e como a solução resolveria o seu problema.

Lições aprendidas:

Testar uma solução que não é viável ou que não traz respostas necessárias para o problema declarado e, principalmente, não resolve a dor dos clientes, pode colocar boa parte do trabalho em risco. Portanto, nesse momento é necessário o envolvimento dos principais times como tecnologia, produtos e atendimento ao cliente para discussão da viabilidade da solução escolhida.

Ferramentas usadas

Miro, Zen Voting, Concept Poster e Storyboard.

PROTOTIPAÇÃO

Dias 8, 9 e 10

O nosso protótipo exigiu um esforço importante do grupo, mas a partir do conhecimento que tínhamos desenvolvemos uma solução simples, viável e que atendia às necessidades dos clientes para que pudessem realizar o uso do seu produto.

Um cronograma exclusivo para essa etapa foi necessário para garantir o prazo combinado para a Sprint e também pelo volume de micro tarefas necessárias para o sucesso do desenvolvimento do protótipo e organização dos testes de uso.

Optamos por estruturar um protótipo de média fidelidade, que permitiu testar alguns formatos de conteúdos e os nossos canais de atendimento, que trouxe um resultado bastante satisfatório.

Lições aprendidas:

Nessa etapa, mais do que fazer uma solução super refinada, lembre-se que o objetivo é testar e validar uma ideia de baixo investimento, para chegar em boas respostas para as hipóteses e dúvidas levantadas.

Ferramentas usadas

Miro, Zen Voting, Storyboard e ferramentas de prototipação.

VALIDAÇÃO

Dias 8, 9, 10 e 11

Chegamos ao momento da verdade, de testar a solução com as pessoas, mas antes passamos por algumas etapas importantes.

A etapa de teste exige um ótimo planejamento do time, que vai desde o recrutamento de entrevistados(as), até quantificar os resultados que validam ou não a solução desenhada.

Definição de objetivos

É necessário que os objetivos do teste sejam claros para o time, como: o quanto conseguimos demonstrar a funcionalidade da solução, clareza sobre os fluxos que os usuários vão passar, o nível de dificuldade e fluidez da solução, entre outros pontos alinhados ao problema principal, objetivo da sprint e resposta buscadas.

Participantes dos testes

Nesse momento definimos as pessoas do grupo que participariam dos testes como ouvintes, anotando todos os pontos capturados da experiência dos clientes, e os(as) entrevistadores(as) que conduziriam os testes.

Recrutamento

Algumas empresas que já têm o processo de pesquisa estruturado, recorrem a bases de pessoas pré-cadastradas para os testes de soluções ou contratam terceiros para o trabalho de recrutamento. Outras contactam os clientes pontualmente ou pessoas que ainda não tiveram experiência com o serviço/produto.
Independente da forma, é importante definir muito bem o perfil (cidade, segmento, hábitos etc.) das pessoas que serão entrevistadas e validar se elas realmente representam o público alvo da solução.
No nosso caso, uma vez definido e validado o perfil, seguimos para o contato com os clientes e agendamos o melhor dia, horário e formato para os testes.
Outro cuidado que tomamos foi adaptar o canal à necessidade dos usuários, pois nem todos conseguem ou têm condições de realizar um teste por videoconferência.

Comunicação

Estruturamos quatro conteúdos para uma comunicação clara e fluida com os(as) entrevistados(as):
– Roteiro para ligação de recrutamento;
– E-mail de confirmação;
– E-mail lembrete para o dia do teste;
– E-mail de envio de roteiro do teste.
A comunicação reforça o comprometimento da pessoa que realizará os testes, além de demonstrar clareza sobre todo o processo.

Roteiro

A equipe que realizará as entrevistas consegue, através de um roteiro, uma sessão objetiva e que leva em conta tudo que deve ser validado, além de orientar, se apresentar, conduzir, questionar novos pontos e estabelecer uma linha de confiança com o(a) entrevistado(a).

Tarefas

No nosso caso, as tarefas garantiram que os clientes explorassem a solução e nos dissessem abertamente suas impressões em cada etapa. Neste momento as perguntas não devem influenciar a opinião dos clientes, como, “Foi fácil entender a solução?”, mas sim “O que achou dessa solução?” para que os feedbacks sejam fiéis.

Medindo a experiência e validando o protótipo

Para quantificar o teste aplicamos no final de cada sessão, através de um formulário, o System Usabillity Scale (SUS) que analisa o nível de usabilidade de uma solução a partir da efetividade, eficiência e satisfação na visão da pessoa usuária.
São perguntas positivas e negativas que trazem uma escala de 1 a 5 e, por meio de um cálculo, chega-se em faixas que classificam a solução como Excelente, Muito boa, Dentro das Expectativas (pontuação padrão do cálculo), Ruim ou Péssima.
Através dos SUS chegamos em uma classificação Muito boa para solução, o que validou a nossa ideia para o problema que estávamos tentando resolver somadas às percepções dos entrevistadores e observadores.

System Usability Scale — fonte: UX Collective

Lições aprendidas:

O SUS é uma ótima solução para quantificar os testes de uso, entretanto é importante que sejam somados os aprendizados e percepções dos entrevistadores e observadores para uma ponderação final dos testes.

Ferramentas usadas

Miro, Ferramenta de Videoconferência, Google Planilhas, Planejamento e Roteiro para teste, Framework System Usability Scale, Google Apresentações.

LIÇÕES APRENDIDAS, A BATALHA FINAL 😅

  • Abaixo listei em tópicos, outros pontos de atenção que colaboram para se alcançar os objetivos da Sprint.
  • Criamos um grupo de mensagem (com data para acabar rs) para manter todos os participantes informados e engajados ao objetivo da Sprint.
  • As cerimônias (daily, weekly e retrospective) foram super importantes para o alinhamento com as áreas envolvidas.
  • Embora os dias intercalados tenham atendido ao que precisávamos, que era estar na Sprint e não deixar os outros projetos de lado, percebemos que fizemos um esforço maior para retomar as dinâmicas após os dias de intervalo. Talvez fosse melhor optar por 3 dias seguidos para ter ainda mais dinâmica.
  • “Ter na manga” ferramentas alternativas, que se encaixam em determinados desafios que surgiram na Sprint foi fundamental para a resolução de problemas não mapeados. No nosso caso, não tínhamos planejado aplicar a ferramenta User Story, mas ela trouxe uma visão global das ações dos clientes, além de colaborar com a seleção de dúvidas que precisávamos responder da Matriz CSD. Ajudou a ter foco.

Modelo
User Story

  • O engajamento do time em um contexto remoto exige atenção especial do facilitador, o que me trouxe um grande aprendizado. Não tínhamos uma cartilha, mas imaginamos algumas coisas que seriam importantes, como, manter a câmera ligada, aplicar intervalos entre as sessões, atenção para dar voz à todos e todas e permitir que participassem das discussões, pensamento otimista e reforçar ao máximo as comunicações em diferentes canais que decidimos usar (mensagens, e-mail, Miro, videoconferência).

Sprint de Design

Embora eu tenha tido a oportunidade de participar de workshops, em diferentes contextos no pré-pandemia, a Design Sprint aplicada remotamente trouxe um aprendizado incrível que sem dúvida será aplicado em sessões futuras.