O Design Sprint da Braskem foi focado em resolver dores do time de suporte da empresa que tinha desenvolvido uma solução de suporte com opções de auto atendimento, o Service NOW, mas que não performava nem convertia os usuários habituados com o atendimento telefônico para o meio digital.
Time
O DS foi organizado seguindo outras dinâmicas já executadas dentro da Dextra e contou com dois designers na execução: eu, responsável por facilitar as dinâmicas e documentar todo o material gerado pelo processo e o meu colega como apoio na facilitação e prototipação da interface que iriamos testar ao final do DS. Aqui cabe uma adendo que um profissional focado na prototipação em paralelo as dinâmicas foi muito importante para que conseguíssemos chegar nos testes finais com um bom protótipo para testes.
Execução
A dinâmica seguiu um framework já utilizado em outros clientes da Dextra, que seguia uma ordem bem parecida com a descrita no livro “Sprint: O método usado no Google para testar e aplicar novas ideias em apenas cinco dias”, porém com uma ligeira alteração para que conseguíssemos cumprir um cronograma mais apertado (somente 4 dias ao invés dos costumeiros 5 dias) e não pulássemos etapas importantes da cocriação.
Problema e Ideias
No 2º dia do DS (1º dia de dinâmica propriamente dito) tínhamos um cronograma muito apertado, tínhamos que explorar e definir as dores e objetivos do DS e cocriar as ideias para definição no dia seguinte do que iríamos validar com o DS, para tal utilizamos as seguintes dinâmicas
Depois de levantarmos os objetivos e perguntas da sprint (que neste momento se encontravam bastante abertas e pouco objetivas tal como: melhorar UX do Service NOW), confrontamos especialistas e usuários do Service NOW em busca de entender melhor as dores e oportunidades que poderíamos explorar.
A luz de novas informações conseguimos revisar os objetivos e perguntas da sprints para dores e soluções mais objetivas e que poderíamos validar com o DS:
Objetivo de longo prazo: antes / depois da entrevista com especialistas
Em 2 anos desejamos ter um ServiceNOW com UX simples, fácil e objetivo e que engaje o usuário a ser mais auto-suficiente.
Daqui a 2 anos desejamos ter o Service NOW com a comunicação mais próxima do usuário e que o ajude no entendimento das categorias.
Perguntas da sprint: antes / depois da entrevista com especialistas
- Conseguiremos traduzir para a linguagem do usuário todos os serviços e textos?
- O Mindset da empresa está ciente que temos que resolver o problema do ServiceNOW?
- O usuário vai ter a cultura de abertura de chamado mesmo com a UX boa?
- Conseguiremos traduzir para a linguagem do usuário todos os serviços e textos?
Desafio da Sprint: antes / depois da entrevista com especialistas
Desenha uma nova página inicial (home) para que os usuários solicitantes (que abrem chamados) porque queremos melhorar a UX no portal e consequentemente a satisfação do usuário.
Desenhar uma nova Home e Página de catálogo para os usuários solicitantes (que abrem chamados), porque queremos tornar a comunicação (linguagem) mais visual e próxima da linguagem do usuário.
Com os problemas bem explorados partimos para a segunda parte do dia A Ideação.
Começamos a tarde com um Lightning Demos, onde cada um trouxe referências de boas experiências que poderiam nos ajudar a definir nossa ideia de solução, nesse ponto vimos que talvez o racional por traz das classificações dos equipamentos aos quais os usuários precisavam pedir suporte poderia estar seguindo o caminho contrário do modelo mental do usuário: o usuário precisava escolher primeiro o “tipo de problema” para depois falar qual era de fato o equipamento que precisava de suporte. A inversão desse modelo foi um dos grandes pilares da ideia final.
Após as demonstrações e dinâmicas de criatividade, todos os participantes da dinâmica tinham seus protótipos bem desenvolvidos para a definição do dia seguinte.
Definindo e Roteiro
Com as ideias prontas para a exposição e análise do time fomos para a execução do mapa de calor para entender o que os participantes e o definidor num segundo momento, consideravam as partes ou ideias mais interessantes para resolver nosso desafio e os pontos que deveriam ser esclarecidos:
Em sequência, com as ideias mais interessantes passamos para definir qual seria o protótipo de fato, fazendo um storyboard das telas a serem prototipadas e um wireframe do que seria desenvolvido:
Protótipo
Em mãos de todo o material e de algumas coisas já prototipadas previamente meu colega de trabalho conseguiu dar sequencia ao protótipo enquanto eu realizava todos os preparativos para o teste de usabilidade (agendamento, infraestrutura, roteiros, etc).
Testamos nosso protótipo com 8 usuários dos mais variados perfis (secretárias, fábrica, TI e Gerência), buscando validar:
- Entendimento dos status dos chamados na Home
- Solicitar um Headset
- Solicitar PowerBI
- Solicitar App Itaú (mensagem homologação)
- Reportar furto de smartphone
Validação
Todos os participantes acompanharam os testes, enquanto eu o aplicava, fazendo cada um suas notas para consolidarmos após cada teste, fazendo com que não tenhamos ruído na comunicação e todos saibam em tempo real como a solução se saiu.
O teste foi um sucesso e validou quase que integramente a ideia de solução, adotar a categorização de equipamentos mais próxima de e-commerces e com linguagem mais acessível fez com que tivéssemos pouquíssimo atrito nos testes ao realizar as tarefas de pedido de suporte a equipamentos. Um dos poucos problemas recorrentes foi o entendimento dos contadores de chamados na home e o procedimento para informar o roubo do smartphone, mesmo assim a grande maioria dos usuários testados conseguiu concluir os cenários:
