Mobilidade urbana — Um case de Design Sprint
Pensamos em uma solução para a mobilidade urbana no país através da metodologia de Design Sprint.
No ambiente corporativo, muitas vezes as soluções precisam ser ágeis. Para que a tomada de decisão seja assertiva e eficiente diante da urgência, é necessário utilizar um processo que acelere o objetivo sem deixar de lado as etapas fundamentais. Para isso, existe o Design Sprint.
O Design Sprint é uma metodologia desenvolvida na Google Ventures por Jake Knaap, com a finalidade de validar uma ideia em um período curto e baixo orçamento. Um Sprint pode durar de 3 a 5 dias e deve contar com uma equipe multidisciplinar, para que o time possa aprender as lições necessárias antes de lançar oficialmente um produto ou serviço.
Entretanto, é preciso levar em conta que nem sempre o Design Sprint é o método mais adequado para um projeto.
Então, quando não devemos usá-lo?
Apesar de ser uma boa alternativa ao MVP (Mínimo Produto Viável), a rapidez do processo pode se tornar um fator limitante, quando o projeto demanda fases mais detalhadas e, consequentemente, um prazo maior. Por isso, dependendo da complexidade do projeto, o Design Sprint não é recomendado.
O desafio
Nossa equipe deveria trazer uma solução para a mobilidade urbana no país. Nós utilizamos o modelo de 3 dias para estruturar as fases do projeto, dividas em: entendimento e definição, sketch e decisão e protótipo e validação.
Entendimento e definição
Para ajudar a tornar a solução mais clara, é preciso pensar no objetivo do projeto. E com o desafio lançado, como fazer para ter uma meta de solução definida?
“How might we?” Ou, “como nós podemos?”
Inicialmente, uma forma de gerar insights para a solução do problema é pensar nos desafios relacionados a ele e como poderíamos solucioná-lo. Nessa atividade, cada integrante da equipe colocou no papel os desafios que achavam relevantes.
Após o grupo reunir suas ideias, agrupamos os post-its por categoria e, então, escolhemos o problema principal a ser atacado. A partir disso, torna-se mais fácil definir o principal perfil de usuário que iremos atender e a plataforma a ser utilizada no projeto.
Proto-persona
Ao contrário da persona tradicional que é realizada a partir de pesquisas com usuários e da tabulação desses resultados, a proto-persona é uma versão mais simplificada. Ela é feita a partir do colhimento de informações internas dos próprios colaboradores da empresa e da equipe envolvida no projeto.
A proto-persona é uma versão mais simplificada e financeiramente mais acessível que a persona tradicional. Ela serve, principalmente, para projetos cujo prazo e/ou orçamento são curtos.
Solução proposta
Nossa equipe escolheu um aplicativo que compilasse as opções de transporte possíveis, com tempo e gasto estimado até determinado destino. Em paralelo, apresentamos as opções de atrações e entretenimento aos arredores com tempo de distância, duração ou estadia média no local e seus valores. O intuito é que o tempo gasto em outras atividades fizesse o usuário evitar o horário de pico e, ainda assim, chegar em horário aproximado do desejado inicialmente.
Definindo KPIs
“O segredo do sucesso é definir as metas certas.” DOERR, John.
Como métricas de sucesso escolhemos mais satisfação no trânsito, melhora do índice de congestionamento e do tempo médio das jornadas de deslocamento de ida e volta do trabalho em dias úteis e horários de pico, dentro do período de 18 meses. Tempo suficiente para a curva de aderência do aplicativo. Não limitamos nossas métricas ao target e nem a uma plataforma. Isso permitiria que pudéssemos manter os KPIs, independentemente de futuras modificações no projeto.
Nossa equipe se apoiaria em pesquisas que mensurem o índice de satisfação com o trânsito e tempo médio de jornadas, feitas por empresas que já costumam realizar e lançar os resultados de pesquisas nessa área, como: Waze, FGV e Indsat.
É muito importante que as métricas não limitem ou enviesem a solução.
Sketch e Decisão
Crazy Eight
Com o problema e objetivo definidos, é hora de trabalhar nas possíveis soluções. Para isso, utilizamos a dinâmica de prototipação Crazy Eight.
O Crazy Eight é uma técnica que consiste em materializar 8 ideias de interfaces em apenas 5 minutos. Inspirada no gamestorming, ela ajuda a refinar os insights da equipe.
Prototipação
Com a interface ganhando forma após o Crazy Eight, nossa equipe se concentrou em desenvolver o protótipo de baixa fidelidade no aplicativo Marvel.
Confira o protótipo do aplicativo aqui.
Teste com usuários
Depois do protótipo pronto, realizamos testes de usabilidade nas ruas para validar nossa ideia. É muito importante deixar os usuários à vontade e, ao mesmo tempo, registrar todos os detalhes. Sem tendenciar a visão sobre a solução, explicamos que fazíamos parte de uma empresa que está testando um novo produto e, por isso, gostaríamos de entender suas impressões.
Isso evita que os usuários fiquem receosos de criticar o produto, já que não revelamos ser os criadores. Também pedimos que contassem todas as suas impressões e opiniões sobre a navegação em voz alta, como se estivessem pensando alto, para que possamos registrá-las em cada etapa.
“85% dos problemas de UX podem ser resolvidas com 5 usuários.” NIELSEN, Jakob.
Conclusão e aprendizado
Com esse workshop, concluímos que é possível utilizar abordagens que viabilizem o desenvolvimento de um projeto de maneira mais ágil. Mas é preciso seguir uma metodologia que não deixe de fora nenhuma etapa vital para sua conclusão. Apesar disso, uma Sprint não possui uma fórmula fechada. Há inúmeros caminhos e ferramentas disponíveis para cada uma dessas fases, cabe a equipe envolvida encontrar a que melhor se encaixa à necessidade do projeto. Também é importante ressaltar que o processo é iterativo. Ou seja, dependendo da necessidade de ajustes após os feedbacks colhidos com usuários, pode haver a necessidade de reiniciar o processo do início ou de algum determinado ponto.
Próximos passos
Após os testes de usabilidade, é recomendável fazer um refinamento do protótipo para testar uma segunda vez. Ou ainda, retomar o projeto do início, dependendo do tipo de feedbacks. Pode ser necessário pivotar a ideia, se houver grande incompatibilidade com a realidade dos usuários ou simplesmente fazer ajustes na apresentação da solução, caso a proposta tenha sido bem recebida em geral.
No caso do nosso projeto, a ideia foi bem recebida pelo público. No entanto, precisaríamos tornar o protótipo mais próximo da realidade para que os usuários pudessem compreender suas funcionalidades com maior facilidade, e assim podermos trabalhar mais detalhadamente sobre cada uma delas.
Por fim, vale indicar o canal da A&J Smart, experts no assunto e reconhecidos oficialmente pelo Jake Knapp na aplicação da metodologia de Design Sprint.
Esse projeto não seria possível sem a partição de Jesus Lucas, Katia Machado, Nelmo Ricalde, Ricardo Costa, Tatiana Garcia. Agradecimentos especiais a Richard Jesus e Bruno Katekawa.
