Como as ferramentas de design te ajudam em um hackathon online?
O processo descrito aqui é o que eu uso em hackathons, e como tudo na vida, pode ser melhorado (fique a vontade para comentar a sua opinião, como você costuma fazer e se este artigo te ajudou).
Hackathons são maratonas que geralmente acontecem durante finais semanas, onde é apresentado um ou mais desafios onde os participantes precisam apresentar, no mínimo, uma solução em um protótipo navegável, com um código funcional e um vídeo pitch. A solução apresentada precisa ser inovadora, o que significa dizer que não precisa ser algo inédito, criado do zero, mas sim uma melhoria do que já existe no mercado. Portanto não é preciso reinventar a roda.
Participar de hackathons é uma experiência incrível, pois é possível fazer networking, amigos e ampliar o repertório sobre o uso da tecnologia em diferentes áreas, aumentando assim a criatividade. Por isso, para uma melhor experiência e entrega, ferramentas de design (além da colaboração do time como um todo) auxiliam muito esse processo.
Mas antes de começarmos, vejamos os principais erros cometidos na primeira etapa após a formação do time:
· Focar na solução e não no desafio
A pressa de começar direto pela solução mata a criatividade do grupo, e dependendo das pessoas começa uma discussão de horas, perdendo um tempo precioso.
· Focar na primeira ideia que aparece
Geralmente a primeira ideia é a mais óbvia e a menos criativa, portanto é bom dar espaço para outras ideias.
· Não entender bem a proposta do desafio
Assista as lives ou encontros online com os organizadores, pergunte (não fique com as dúvidas para si) e leia o edital.
· Ter um evento no mesmo final de semana do hackathon e deixar o time “na mão”
Tudo acontece rápido demais em um hackathon, seu time precisa de você, portanto comprometimento é essencial.
· Não estar aberto a ouvir opiniões diferentes da sua
Esse é um dos piores problemas atualmente, muitas pessoas apenas querem ter razão, não estão abertas a troca e ao aprendizado que o hackathon possibilita. Isso gera um desconforto geral e o projeto anda com dificuldades ou não anda.
· Não pesquisar sobre o contexto do desafio (principais problemas)
A primeira etapa (como veremos adiante) é a descoberta, portanto é preciso um mínimo de aprofundamento no contexto do desafio para que se possa entendê-lo melhor.
· Não levar mais de uma ideia para validar com o mentor da área específica do desafio
Quando não se faz uma boa pesquisa na etapa de descoberta, corre-se o risco de levar alguma ideia de solução que já exista, portanto o ideal é selecionar as duas ou três melhores ideias.
· Querer fazer itens demais, telas demais (login, senha, etc).
Alguns hackathons tem juris de desenvolvedores que vão conferir o código no GitHub, portanto o que estiver na interface do MVP deve estar funcionando no código.
· Começar o código no último dia
Sempre acontece de haver um bug no sistema, algum erro de digitação, é normal, já que o cansaço “bate forte”, por isso deixar para iniciar o código no domingo é complicado.
É notório que além de competências técnicas, competências socioemocionais também são importantes para o melhor desempenho do time, portanto, essa é uma excelente oportunidade de melhorar as suas soft skills, mas vamos ao que interessa…
Etapas do processo:
Resumidamente, podemos adaptar a metodologia do design thinking para hackathons em três etapas gerais:
1. A etapa de descoberta
Esta é a etapa em que “entramos no problema”, para isso é necessário entender muito bem o desafio do hackathon. Por isso, é necessário assistir aos vídeos ou encontros que elucidem o contexto do problema e tirar todas e quaisquer dúvidas a respeito do desafio, que podem não ter ficado claras anteriormente.
Depois de compreendido muito bem do que se trata o desafio, agora é a hora se fazer pesquisa exploratória na internet (desk research). Neste momento é interessante que cada integrante faça sua pesquisa individualmente (geralmente na própria sexta à noite ou sábado de manhã) e depois marquem um encontro para montar uma Matriz CSD. Para montar a Mariz CSD será necessário usar o Miro ou Whimsical. Serão montadas três colunas onde os participantes terão de 5 a 7 minutos para escrever suas certezas, suposições e dúvidas, individualmente.
Depois disso, é montado um questionário no Google Forms, ao colocar as perguntas, pense como um investigador, um detetive curioso que nada sabe sobre o seu investigado (usuário) e pense sempre em validar, ou não, suas suposições e responder as dúvidas levantadas na matriz CSD. Em qualquer processo de produção de produto digital, uma pesquisa com o usuário é sempre importante para entender das suas dores e da real necessidade do produto.
Enquanto o questionário está sendo distribuído na internet, o time volta para o quadro branco online (Miro ou Whimsical) para então decidir dentre as principais dúvidas e suposições quais seriam as mais importantes para o negócio. Nesta fase é bem difícil saber quais problemas são os mais importantes, pois não somos nossos usuários.
Então, para ajudar a entender melhor isso, fazemos uma jornada do usuário sprint 2.0, usando o Miro ou Whimsical. Com este exercício será mais fácil exercitar a empatia e entender melhor o contexto do usuário. Para fazer essa jornada é necessário fazer individualmente, as seguintes etapas:
· Escolha o mais importante tipo de usuário ou cliente, na sua opinião, e escreva em um post it.
· Escolha o objetivo final do cliente (desafio do hackathon), o que se deseja alcançar e escreva em um post it.
· Preencha em post its as etapas ou passos do cliente, pensando nos pontos de contato do usuário até chegar ao objetivo final.
Depois de 20mins fazendo essa atividade, cada pessoa do time apresenta a sua jornada., depois disso é feito um mapa de calor, ou seja, são colocados bolinhas nos post its e votados os melhores passos da jornada e com isso, é montada a melhor jornada (uma historia é contada). Lembrando que toda essa jornada é descrita no momento atual, ou seja, como o cliente resolve o problema sem o seu produto.
Quando definimos os atores da jornada do usuário da Sprint 2.0 e o principal usuário (cliente), podemos então montar uma persona. O uso de personas é bastante útil e importante para uma melhor compreensão do comportamento do usuário. Como pensam, o que desejam, quais serviços precisam, quais são suas aspirações, como preferem ser atendidos, que tipo de relação esperam, por quais valores estão dispostos a pagar, e como é o seu comportamento digital, como resolvem o problema delas sem a sua solução, etc.
Neste caso, não é necessário colocar foto e fazer tão belamente detalhado, mas é importante pensar nas tarefas, nas dores e nos analgésicos.
E como a jornada do usuário da sprint 2.0 e persona podem ser úteis? Elas vão te ajudar a montar um bom storytelling para o vídeo pitch, esclarecer o fluxo do usuário e a perceber as etapas que podem ser melhoradas, através da sua solução.
2. Etapa de Ideação:
Apesar de o quantitativo da pesquisa no Google Forms ainda não ser o suficiente, já se tem uma ideia se as suposições e as dúvidas foram esclarecidas. Portanto, neste momento o contexto do desafio e do usuário podem estar mais esclarecidos. Agora é possível encontrar os principais problemas ou dores do cliente para fundamentar a sua solução. Neste momento também é interessante ver ou rever os critérios de avaliação e regras do hackathon, para ajudar na escolha da solução.
Na etapa anterior foi possível identificar os principais problemas dentro desse desafio (objetivo final), então o time vai ter 5mins para votar individualmente nos problemas que julgam ser mais relevantes para o desafio. Esta etapa será realizada no Miro ou Whimsical. Deverão ser escolhidos dois problemas mais relevantes e então separá-los em colunas paralelas no quadro branco (Miro), após isso os participantes terão mais 5mins para pensar nas soluções individualmente e coloca-las em post its (brainstorm).
Após isso, será feito uma matriz de impacto x esforço onde cada solução será avaliada e serão escolhidas as três soluções que possuem um maior impacto na resolução dos problemas com um menor esforço de recursos (neste caso, o tempo). Para votar nas soluções e categorizá-las em nível de importância é necessário usar os critérios de avaliação propostos no edital do hackathon.
Depois de escolhidas às soluções o ideal é falar com algum mentor especifico, apresentar suas principais ideias e ver qual solução pode ser mais interessante desenvolver.
3. Prototipação:
Escolhida a melhor solução, agora é a hora de prototipar e neste momento menos é mais, pois somente o essencial deve ser prototipado para criar um MVP funcional. E olha que legal, se for seguido essas etapas e cumpridos os prazos, no sábado a tarde/noite já se pode começar a pensar no fluxo do usuário, na logo, no nome da solução, na identidade visual e começar a fazer o código.
O ideal é que a logo e a identidade visual sejam feitas nos programas do pacote Adobe, entretanto, caso você não tenha é possível fazer bons trabalhos de design gráfico utilizando o Canva, banco de imagens gratuitas como o Freepik e ícones em SVG como o Flaticon. Para definir as cores pode-se utilizar o Adobe Color, onde se consegue usar as regras de combinação de cores do círculo cromático e extrair gradientes e paletas de cores de imagens. Também é possível se inspirar e usar ideias de templates de aplicativos famosos com Mobbin.
Neste momento é hora de priorizar (MosCow) e devemos colocar somente o que é essencial, o mínimo possível para que o protótipo funcione e o que não tiver relevância para o MVP neste momento, deverá ser retirado.
Depois de priorizar, é necessário pensar no fluxo do usuário, parte essencial para uma melhor usabilidade do MVP. Neste momento, caso surja alguma dúvida, é interessante voltar na jornada do usuário da sprint 2.0 e persona. Começar pelo papel ou ir direto para o Figma (por ser colaborativo, todos os integrantes podem visualizar e alguns editar) fica a critério do time.
A interface também pode ser desenhada no Adobe XD, Frame, ou qualquer outro que o(a) designer prefira. As telas também podem ser feitas direto pelo(a) front end do grupo.
Para usar como inspiração para as telas de site: Figma Store e H69 Design (para landing page),Template, UI Store Design, Uplabs, Dribble e Behance. Para aplicativos: Mobbin (agrupa as interfaces de aplicativos conhecidos) e os aplicativos: Material Design Templates e Material UI Design Templates, que mostram templates de interfaces por temas.
Se o time tiver com tempo sobrando, é bom testar o MVP com pessoas conhecidas mesmo, só para ter uma ideia vaga da usabilidade, mas lembre-se de explicar o contexto do usuário para que a pessoa entenda suas tarefas.
3.1 Entregas do Hackathon:
Muitos hackathons pedem a gravação do vídeo demo do MVP funcionando e para isso, além da interface, é necessário o código, que também deve ser colocado no GitHub.
Depois de decidido o que será feito e começado o código é hora de montar a apresentação do vídeo pitch, que pode ser feito contando uma história. Nesse momento é bom rever a jornada do usuário sprint 2.0, usar o pixar storytelling e adaptá-lo para montar a história do seu personagem. É sempre bom colocar algumas perguntas que gerem algum tipo de empatia, dentro do contexto da história, como por exemplo: “João precisava de um empréstimo no banco para expandir o seu negócio, mas não conseguiu crédito por não conseguir comprovar sua renda, você ficaria frustrado com isso, não ficaria?“. Além de um bom storytelling é sempre interessante fundamentar sua estória com dados estatísticos, que devem ser da sua própria pesquisa exploratória (desk research) e respostas do questionário do google forms.
Uma tendência que tenho percebido nos vídeos pitch de hackathons é o uso de animações, sendo os principais programas usados para isso: Animaker, Powtoon, VideoScribe e Benime (para celular), as versões gratuita podem ser limitadas a dias, número de projetos ou itens, mas valem a pena. Para usar banco de imagens gratuitas: Freepik e Undraw. Banco de vídeos gratuitos: Coverr, Pexels e Pixabay. Para remover o fundo de imagem: Removebg
Para edição de vídeo no celular: Inshot e CapCut. Para gravar o vídeo pitch e o vídeo demo, podem-se usar os gravadores tela: Powtoon, Loom e Ezvid para windows. Para gravar a tela do celuar: XRecorder.
Para montar a apresentação em PDF do pitch: business model canvas, que tem template pronto para usar no Miro (mais detalhes) e Canva.
Agora é mandar tudo, cruzar os dedos e esperar…
Espero ter te ajudado um pouco nessa jornada do hackathon, e claro caso tenha uma opinião diferente da minha, por favor, escreva nos comentários vou adorar saber!
#uxdesign #uidesign #designthinking #hackathon
