Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 3

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior relatamos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente insatisfeito.

Neste capítulo contaremos como trabalhamos para corrigir os nossos erros e qual foi resultado da segunda fase de testes. Relataremos também, nosso esforço para chegarmos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

Capítulo 1

Capítulo 2

Começamos tudo de novo

Após a “bronca” que levamos dos nossos clientes, vimos que a tentativa de solucionar vários problemas de uma só vez e em tão pouco tempo foi “um tiro no pé”. Assimilamos os erros cometidos e concluímos que era preciso reduzir funcionalidades, que menos era mais.

Com o foco centralizado no usuário, fizemos um Mapa de Empatia, entendendo melhor quem é o nosso cliente, o meio em que vive, suas expectativas, medos e o que ele realmente precisa. Assim, ficou mais simples entender o que realmente seria importante para ele. Decidimos então que funcionalidades deveríamos focar:

  • Acompanhar o andamento das Sprints do projeto;
  • Visualizar tarefas pendentes;
  • Acesso a documentos e protótipos;
  • Relatar problemas;

Com isso em mente, começamos os rabiscos de novo, pensando em facilitar qualquer atividade que o usuário precisaria fazer. O que antes era um tela cheia de informações que eram ignoradas, tornou-se uma tela com 4 botões simples, que levaria o usuário a um caminho mais claro antes dele concluir a tarefa desejada.

mockup_new_app
Tela principal do nosso segundo protótipo

 

Protótipo pronto, partimos para a segunda fase de testes.

Solução do problema de falta de foco

Antes de revelar como foram os testes. Contaremos como chegamos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

A Sprint 0 e Sprint Final é um período importante em que a equipe deve se concentrar. Porém poucos estavam realizando estas etapas efetivamente, por vários motivos, tais como: resolver problemas de outros projetos, distração com mídias sociais e auxílio a outros colegas quando estavam sem tempo (alguns tinham dificuldade em dizer “não”).

A solução encontrada foi identificar as equipes que estavam nestes períodos por meio de uma bandeirinha. Desta forma, quem estivesse com a bandeira teria um sinal que deveria focar no projeto em que está trabalhando e quem estivesse de fora não incomodaria o time com a identificação.

Além da sinalização da Sprint 0 e Final, sentimos a necessidade de incluir outra situação, quando a equipe está atropeladas de tarefas a serem realizadas no projeto e o tempo de entrega está quase no fim. Denominamos este caso de “Projeto Explodindo”.

O processo de produção das bandeiras foi o mais interessante, pois deixamos de criar soluções digitais para criar soluções físicas. Largamos o computador para fazer um trabalho artesanal que nos lembrou a época da escola. Recortamos papel, cortamos madeira, colamos papel e plástico, e nos divertimos muito com isso.

producao-das-bandeirinhas

Após terminar a produção, fizemos quatro bandeiras para sprint 0 e final com a cor amarela e três bandeiras para o caso de o projeto estar atrasado com a cor vermelha.

Hoje, as equipes estão utilizando as bandeiras e já tivemos bons feedbacks, muitos dizendo que as interrupções foram reduzidas e que a concentração para os projetos está sendo bem maior.

Segunda fase de testes

Ansiosos para saber como seria o resultado, colocamos o segundo protótipo para ser testado, desta vez, com pessoas que se encaixavam no perfil dos nossos clientes e com atividades mais focadas nas principais funções. Realizamos o mesmo procedimento do primeiro teste.

O resultado foi surpreendente, a diferença entre os dois testes foi “gritante”. Os usuários realizavam as tarefas rapidamente, um ou outro demoraram mais que um minuto. Um bom exemplo foi a função de visualizar as tarefas pendentes, em que a média caiu de 1min31s para apenas 17s.

Abaixo é possível visualizar a comparação da média de tempo na realização das tarefas entre o primeiro e o segundo teste:

media_testes_de_usuário
Média de tempo na realização das tarefas do primeiro e segundo protótipo

 

Mesmo com a melhora significativa, tivemos que corrigir alguns pequenos detalhes que trouxeram alguma dificuldade para os usuários.

Entrega da última sprint

Chegou a hora tão esperada. Ao mesmo tempo que estávamos confiantes pelos bons feedbacks, estávamos nervosos, porque sempre há alguma tensão quando nosso trabalho é avaliado.

Primeiro apresentamos as bandeirinhas, e tivemos uma boa resposta dos nossos clientes. Eles elogiaram a solução a que chegamos e a forma de como a executamos. Que dessa vez, deu pra ver que trabalhamos em equipe.

Depois apresentamos o aplicativo. Muita calma nessa hora. E…

O Jeff e o Ney gostaram também do resultado que apresentamos e ficaram surpreendidos com a diferença entre os dois testes. E deram sinal verde para que os desenvolvedores começassem o desenvolvimento do aplicativo. Este feedback nos deixou aliviados.

O que aprendemos

Ao utilizar metodologias do design thinking, ir a fundo no projeto, estudar e selecionar os reais problemas, propor soluções com uma base técnica bem definida, realizar testes e pesquisas com os usuários, ajudou-nos a fugir da subjetividade e tomar decisões com argumentos concretos, tendo a certeza de estar no caminho certo e entregar um produto valioso ao nosso cliente e ao usuário final dele.

A experiência de trabalhar em conjunto com os desenvolvedores trouxe-nos uma visão mais lógica na construção de um produto. Com a opinião técnica deles do que é possível ou não fazer, era fácil para nós, designers, desenharmos uma solução.

A redução de documentação também foi algo positivo, já que o desenvolvedor estava ao nosso lado e entendia o projeto todo, participando da criação, compreendendo tudo aquilo que foi feito e não simplesmente executando algo que caía em suas mãos.

O projeto New App foi um grande aprendizado para todos e levaremos este conhecimento para o restante das nossas carreiras.


É isso! Chegou ao fim nossa jornada.

Gostaríamos de receber seu feedback. O que achou do nosso processo? O que podemos melhorar? O que podemos acrescentar? O que podemos fazer de diferente?

Autores: Carol Cabral e Vinicius Rocha

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 2

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior contamos como surgiu a oportunidade de trabalhar no projeto New App e o árduo processo na escolha do nome da nossa ferramenta de gerenciamento de projetos, Active Collab.

Neste capítulo diremos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente desapontado.

Capítulo 1

Capítulo 3

Processo de Ideação — produção do app para nosso cliente

Decidido o nome e alguns problemas internos solucionados, era a hora de focarmos na falta de engajamento do cliente com a ferramenta de gerenciamento.

Desde o início do projeto, batemos na tecla que a solução poderia ser um ajuste comportamental e não necessariamente um app, mas a mão dos devs e designers coçavam para “codar” e “leiautar” e a vontade era desenvolver um aplicativo. Esta ansiedade acabou se tornando um erro, que iremos relatar mais a frente.

Resolvemos desenvolver o app, porque percebemos que ele seria um facilitador para os clientes, que em sua maioria estão ocupados e não conseguem parar, sentar em frente a um computador e acompanhar todo o processo de seu projeto. Com isso, nos concentramos em funções básicas e que gostaríamos que tivessem o engajamento do cliente:

  • Acompanhamento das discussions (conversas);
  • Pendências do próprio cliente;
  • Alternar projetos;
  • Acompanhar projetos;

Após a definição das funcionalidades, começamos a rabiscar, devs e designers desenhando e colocando suas ideias no papel. Colhemos, misturamos e discutimos as soluções, chegando a um resultado que todos julgaram a melhor alternativa.

Processo de Prototipação

Com a sensação de ter feito a escolha perfeita. Largamos o lápis e o papel e botamos a mão na massa.

Talvez por costume, dividimo-nos mais uma vez em designers e desenvolvedores, cada um sentado no seu cantinho, fazendo o que melhor sabe fazer, antes mesmo de validarmos as hipóteses apontadas. Enquanto os devs “codavam”, nós designers terminávamos de montar o protótipo (sem código) no InVision com todas as telas e simulações.

Tela principal do nosso primeiro protótipo
Tela principal do nosso primeiro protótipo

 

Primeira fase de testes

Protótipo pronto era a hora de validá-lo. Buscamos testar com pessoas próximas, pois infelizmente não foi possível entrar em contato com o nosso público alvo (clientes).

Para realizar os testes, chamamos alguns colegas e familiares para serem nossa “cobaias”. A metodologia que empregamos baseava-se em um roteiro no qual descrevíamos um cenário e tarefas que usuário deveria fazer para cada funcionalidade que queríamos por em prova.

Em uma sala privada, uma pessoa da equipe fazia o papel de facilitador, responsável por ler o roteiro e comunicar-se com o usuário e outro era o observador, responsável por analisar as ações e expressões do usuário. Para cada funcionalidade cronometrávamos o tempo.

testes com usuarios

Infelizmente o resultado não foi o esperado. A maioria dos usuários se perdiam e não conseguiam realizar a tarefa da forma que queríamos. Até mesmo para um usuário com grande afinidade com interfaces de aplicativos móveis, demorou cerca de cinco minutos para realizar uma funcionalidade. Não houve nenhuma atividade onde a média tenha sido menor que de 1min30s.

Entrega da sprint


Com o resultado nada bom, fomos apresentar tudo o que foi feito para o Jeff e o Ney que não gostaram do que foi entregue. E ainda levamos uma “bronca”, porque não focamos em soluções que estavam previstas, e por não trabalharmos efetivamente junto aos desenvolvedores, que começaram a “codar” antes de validarmos as hipóteses por meio do protótipo.

Depois de entregarmos um trabalho nada satisfatório, entendemos que deveríamos trabalhar juntos até chegarmos a uma solução ideal.


No último capítulo da nossa jornada, contaremos o que fizemos na terceira sprint para corrigir nossos erros. Como foi o resultado da segunda fase de testes e se os nossos clientes ficaram satisfeitos ou não com a solução que entregamos.

 

Autores: Carol Cabral e Vinicius Rocha

Como entregamos um produto valioso utilizando as metodologias do Design Thinking  –  Capítulo 1

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

Neste primeiro capítulo contaremos como surgiu a oportunidade de trabalhar neste projeto e como foi o desenrolar da nossa primeira sprint.

Capítulo 2

Capítulo 3 

Como tudo começou

Durante os cinco anos de Jera, o processo de desenvolvimento tem evoluído constantemente. Com esta crescente sentiu-se a necessidade do processo de design também acompanhar esta evolução, para entregar ao cliente uma solução de grande valor e não entregar mais só pastel de carne ou de queijo.

De olho neste aprimoramento, em setembro de 2015, nosso diretor de tecnologia (CTO) e designer, Ney Ricardo, ministrou um workshop de Design Thinking e Lean UX para todos os designers da Jera, no qual ele nos passou técnicas para centrarmos a construção de um produto no usuário.

O workshop foi ótimo, aprendemos muito, porém até o final de 2015, não tivemos oportunidade de aplicar o que nos foi ensinado. Até que apareceu a chance…

Nosso diretor de operações (COO), Jefferson Moreira (mais conhecido como Jeff), queria resolver alguns “abacaxis” que incomodavam bastante na Jera. Então, ele aproveitou que nossa equipe estava sem projeto e nos passou a grande missão: resolver estes problemas utilizando a metodologia do design thinking e, ainda, trabalhar em conjunto com os desenvolvedores durante todo o processo de design.

Iniciou-se então o projeto New App 1.0. A equipe responsável por ele foi formada por nós, designers Carol Cabral, Kevin Tosli e Vinicius Rocha e pelos desenvolvedores Vitor Mesquita e Victor Robertson. Nossos clientes foram o Jeff e o Ney e teríamos três sprints (semanas) para realizar o projeto.

Início do projeto  – levantamento de problemas

Começamos nossa jornada levantando os problemas da Jera. Em um processo de imersão, com todos da equipe do projeto, time de QA (garantia de qualidade) e o Jeff, listamos todos os problemas que incomodavam a equipe Jera, desde os pequenos até os grandes, sem julgamentos.

Após o levantamento, utilizamos um diagrama (imagem 1) para classificar os problemas em: essenciais, desejáveis e dispensáveis. Depois usamos a Matriz de Retorno (imagem 2) para avaliar o nível de retorno que a solução deles iria nos trazer.

Imagem 1
Imagem 1
Imagem 2
Imagem 2
No final decidimos solucionar os seguintes problemas, os quais, julgamos serem os mais críticos:

 

  1. Visão mal documentada;
  2. Funcionalidades feitas para uma plataforma e não na outra;
  3. Projetos sem Kickoff e Visão;
  4. Cliente não sabe onde estão os entregáveis (documentos e protótipos);
  5. Nome da ferramenta Active Collab;
  6. Cliente não participa durante o processo de desenvolvimento;
  7. Descrição e checklist de pequenos processos;
  8. Equipe Jera esquecendo algumas etapas do processo de atendimento ao cliente ou desenvolvimento;
  9. Facilitação com novos recursos na ferramenta;
  10. Falta de foco da equipe na Sprint 0 e Sprint Final.

Para os artigos não ficarem muito extensos, contaremos nossa empreitada para solucionar os três problemas que trouxeram uma ótima experiência para nós: nome da ferramenta (tratado neste primeiro capítulo), falta de engajamento do cliente e falta de foco da equipe na Sprint 0 e Sprint Final (estes dois últimos falaremos no segundo e terceiro capítulo desta série).

Escolha do nome da ferramenta

Desde que começamos a utilizar a nova versão do Active Collab  – ferramenta que utilizamos para gerenciar os projetos dos clientes e produção  – tínhamos um problema com o nome dela. O nome anterior era “Projeto”, ele causava confusão, pois quando mencionava-se o nome, não sabia-se se a pessoa estava se referindo ao projeto do cliente ou à própria ferramenta. Outra problemática era que quase todos a chamavam por “Active Collab”.

A escolha de um nome era algo que parecia ser simples e rápido no início, mas nos ocupou três dias de trabalho e algumas “dores de cabeça”.

Reunimos nossa equipe e sentamos junto ao Jeff, e fizemos um brainstorming para levantar opções de nomes. Após surgirem umas 20 ideias, selecionamos quatro alternativas: Asgard, Pipe, Oráculo e Colab. Decidimos então, lançar uma pesquisa de opinião a todos da Jera, na qual perguntamos se gostavam ou não dos nomes selecionados e o motivo.

Infelizmente tivemos uma péssima resposta, muitos reclamaram que não puderam opinar, outros simplesmente não gostaram, mas no geral obtivemos feedbacks valiosos. O importante é que entendemos que não iríamos agradar a todos, então levantamos pontos importantes para a escolha do nome:

  • Novo: não pode ser um nome que já foi utilizado pela Jera, como: “Hunter”, “Projeto” ou “Atendimento”;
  • Simples de pronunciar, escrever e lembrar;
  • Objetivo e que reflita funcionalidades da ferramenta;
  • Aderência por parte da equipe, não confundindo com outros termos já utilizados;
  • Ideia de colaboração: principal valor que a Jera quer ao implementar o uso da ferramenta;

Após o levantamento dos pontos, reunimo-nos mais uma vez para propor outras sugestões. Levamos todas as propostas para uma nova pesquisa, desta vez, a fizemos com alguns colegas e pessoalmente. Mostramos os nomes e perguntamos o que sentiam e entendiam por cada um. Pudemos avaliar as reações e sensações deles ao dizer cada nome.

Consideramos os argumentos e expressões de cada um fundamentais para tomarmos nossa decisão. E todos tiveram uma boa reação ao ouvir o nome Painel. 

Após muitas discussões, batemos o martelo. Decidimos pelo nome Painel que preenchia os requisitos que elencamos e que teve maior aceitação pelos entrevistados.

Apresentação do nome

Com o nome escolhido, era a hora de anunciar. Um momento de grande apreensão, porque o pessoal da Jera é bem crítico e se não gostassem do nome, com certeza não o utilizariam, tornando nosso duro trabalho um fracasso.

No entanto, para nossa alegria, a aceitação da equipe foi boa, e em pouco tempo já estavam utilizando o novo nome ao invés de “Active Collab”, cumprindo nosso objetivo.


No próximo capítulo contaremos como foi o desenrolar da segunda sprint, na qual trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente desapontado.

Autores: Carol Cabral e Vinicius Rocha

Tributo ao dia do programador

Sempre achei que programadores eram seres superiores. Assim como um médico e um engenheiro, devs têm o poder de transformar coisas e trazê-las à vida, ou algo do tipo…

Desde cedo me interessei por aquele amontoado de silício que mostrava na tela coisas incríveis, com tamanha precisão e velocidade. Imaginava: “Como será que essa máquina faz pra transformar eletricidade em zeros e uns e depois traduzir em imagem para que eu possa interagir com ela?”. Se você parar pra pensar, é bem louco, né?

Corri atrás e me ensinei a falar as diversas “línguas” desse bicho, para que conseguisse dar instruções que automatizassem as tarefas do dia-a-dia.

Frequentemente olham pra mim e dizem que sou nerd ou geek, sinônimos de inteligência, que me ajudam a hackear a barreira social inicial e me infiltrar em novos círculos.

Já até superei o fato dos meus pais não entenderem o meu trabalho. Hoje não preciso mais de desculpas pra não querer estudar direito ou medicina, só porque dão dinheiro. Faço o que amo, sou programador, meu negócio é codar!

Meu trabalho consiste em pegar um monte de dados abstratos e transformá-los em valor real que move pessoas, humanizar a máquina, enfim, resolver todos aqueles problemas que você não tinha.

Nesse mundo virtual eu reino absoluto, sou o criador, modificador, conselheiro, tradutor.


Dia 13 de Setembro é o Dia do Programador. Esse é um tributo que a Jera fez aos programadores que dão o sangue todo dia pra ajudar a tornar o trabalho cada vez melhor!

Veja no instagram as fotos do dia em que comemoramos: #sanguedeprogramador