“Integra”: facilitando o acesso a materiais escolares através da colaboração entre pais, responsáveis e doadores (Programa de Formação Season 1 — Grupo FCamara)
Apresentação e problemática
Todo ano, a FCamara oferece um Programa de Formação divido em algumas etapas. A última destas etapas é o Hackathon, no qual os candidatos aprovados são divididos, por sorteio, em Squads compostas por UX Designers e Pessoas Desenvolvedoras.
As Squads recebem um desafio contextualizado e têm o objetivo de desenvolver uma solução digital para o problema apresentado.
A problemática apresentada pela empresa foi a seguinte:
“Nós sabemos o quanto é complicado para os pais poderem comprar material escolar para seus filhos. Os preços aumentam de semestre para semestre. Principalmente quando falamos de educação pública, onde a dificuldade é ainda maior e vem por diversos fatores…”
E a entrega exigida foi a criação de uma aplicação onde:
“… Os pais irão cadastrar seus filhos que estudam em escolas estaduais e municipais, e também a lista de material escolar que precisam e não tem condições de comprar.
Usuários avulsos e anônimos podem acessar, buscar a escola com base em alguns critérios de busca, visualizar a necessidade dos alunos carentes e fazer a doação dos itens que um determinado aluno esteja precisando.”
A empresa deu a opção de entregarmos uma aplicação web responsiva ou um aplicativo que solucionasse o problema.
Precisávamos, também, entregar no mínimo 3 telas do projeto, sendo protótipo e desenvolvimento.
Metodologias utilizadas
Ao longo do projeto, foi utilizada uma combinação dos processos de Design Thinking e Design de Interação, de acordo com noções da Interaction Design Foundation.
Os processos utilizados foram escolhidos à medida em que as necessidades do projeto foram se apresentando, não constituindo, necessariamente, uma linearidade nas etapas.
No Design Thinking, as etapas gerais do processo são:
- Empatizar
- Definir
- Idear
- Prototipar
- Testar
Já no Design de Interação, de acordo com a Interaction Design Foundation, o processo pode ser visto, em linhas gerais, através das etapas:
- Necessidades/Desejos do Usuário
- Análise
- Design
- Prototipação
- Implementação e Entrega
Tendo esses frameworks em mente, o projeto foi desenvolvido em cinco fases, combinando aspectos de ambas metodologias.
Fase 1: Empatizar + Necessidades e Desejos dos Usuários
Matriz CSD
Como ponto de partida para a conceituação do nosso projeto, decidimos utilizar a Matriz de Certezas, Suposições e Dúvidas (CSD) em relação aos dois tipos de usuários da nossa plataforma, ou seja: Mães/Pais/Responsáveis e Doadores. Isso nos permitiu formalizar reflexões, insights e pontos de aprofundamento para conduzir o restante da pesquisa e contribuir para a tomada de decisões ao longo do projeto.
Pesquisa qualitativa com potenciais usuários e stakeholders (entrevistas)
Para confirmar nossas hipóteses e conseguir novas descobertas, foram realizadas entrevistas com potenciais usuários e stakeholders. Três entrevistas foram conduzidas ao longo da primeira e da segunda semana do Hackathon. Essas entrevistas foram com pessoas que se encaixavam nos perfis de usuário-doador, usuária-mãe e stakeholder.
Rebeca, potencial Usuária-Mãe
Na entrevista com Rebeca, mãe de 3 crianças que estudam na rede pública e, também, ex-funcionária (merendeira) de escola pública, pudemos confirmar a enorme dificuldade que este segmento de público possui em relação ao reajuste de preços de materiais escolares, ocorridos semestralmente. A partir da conversa, ficamos a par, também, sobre as dificuldades relacionadas à busca por melhores preços e ao processo de se programar com antecedência para procurar e comprar tais materiais.
Além disso, um dos pontos mais relevantes levantados em nossa conversa foi sobre a mudança de paradigma causada pela pandemia. Nas palavras de Rebeca, “hoje o material escolar é a conexão de internet”. Descobrimos que, por limitações de recursos, Rebeca se vê na situação de ter que disponibilizar seu próprio celular para que suas três crianças possam estudar e acompanhar as aulas.
Ou seja, através desta entrevista, pudemos corroborar a complexidade da problemática com a qual precisávamos lidar: o ambiente de ensino, bem como suas condições, estavam alterados e era crucial que a equipe levasse isso em conta.
Rafael, potencial Usuário-Doador
Rafael, de 36 anos, é engenheiro numa empresa de médio porte e atualmente é aluno de pós-graduação (EAD) em Engenharia de Materiais. Ele é casado e tem um filho de 5 anos que estuda em uma escola particular. Na entrevista, ele nos contou que sabe o quanto é trabalhoso para uma família comprar materiais escolares, tanto para encontrar todos os produtos da lista que a escola exige num só lugar, como também para achar bons valores no mercado.
Além disso, Rafael afirmou ser primordial dar bons subsídios para o seu filho estudar e se desenvolver na escola. Ele disse que, juntamente com a esposa, faz voluntariado há alguns anos na comunidade. Ainda, falou que gostaria de ajudar de forma direta alunos menos favorecidos. Nos disse que se sente bem em trabalhar como voluntário, porque vê que ajudando, mesmo que com pequenas atitudes, tem o poder de transformação na sociedade. Também nos contou que não tem o costume de doar dinheiro; ele disse que até poderia fazer isso, mas para doar dessa forma precisaria ter muita confiança no processo de doação. Sua opinião é que, no momento atual, da pandemia, o futuro do Brasil está cada vez mais incerto.
Pascoal, potencial Stakeholder
Durante a primeira semana, também entrevistamos o empreendedor social Roberto Pascoal, CEO da Omunga. Roberto foi bem solícito em nossa conversa e nos apresentou apontamentos relevantes sobre estratégia de negócios, captação de investimentos e formação de parcerias, bem como a necessidade de estarmos em constante contato com nosso público, pois “apenas o público pode nos mostrar o que precisa, de fato”.
Além dessas contribuições, Roberto também nos atentou à necessidade de definirmos com maior precisão a amostragem do nosso público-alvo. Ele foi categórico ao afirmar que deveríamos pensar em valores concretos, ou seja: vamos atender todas as escolas do Brasil, ou apenas de uma cidade? Se vamos atender apenas uma cidade, quantas escolas desta cidade vamos atender? Se for apenas uma escola, todos os alunos seriam contemplados, ou apenas uma parcela? Entre outras contribuições.
Pesquisa quantitativa (análise de dados relacionados à problemática)
Além das entrevistas que fizemos para a pesquisa qualitativa, também utilizamos o relatório do Brasil Giving 2020 como base para nossa pesquisa quantitativa, a fim de contextualizar e extrair dados relevantes à problemática e ao andamento do projeto.
O relatório do Brasil Giving é uma pesquisa realizada anualmente pela CAF (Charities Aid Foundation) e pelo IDIS (Instituo para o Desenvolvimento do Investimento Social), que investiga o engajamento dos brasileiros em relação à doação.
Em linhas gerais, descobrimos que 78% dos entrevistados declararam que fizeram algum tipo de doação, sendo que 53% destes doaram dinheiro para ONGs. Com relação às suas motivações, frases como: “porque faz com que eu me sinta bem” e “porque me preocupo com a causa’’ estiveram presentes em cerca de 52% das respostas.
A pesquisa apontou que a doação em dinheiro permanece como o método mais comum para realização de doações, sendo utilizado por 2/3 (65%) dos doadores entrevistados. Entretanto, quando estes dados foram comparados com os levantamentos de 2018 e 2019, foi percebido um crescimento na utilização de canais online, como: conta bancária ou cartão de crédito (de 16% para 23%), plataformas digitais (de 12% para 16%) e tecnologias contactless (de 7% para 12%).
Esses resultados sugerem que, embora o dinheiro permaneça dominante, as doações usando tecnologias digitais estão se tornando cada vez mais comuns no Brasil.
Entretanto, doações direcionadas para indivíduos representaram apenas 10% do levantamento feito pelo relatório, o que sugere uma propensão maior para doações e apoios direcionados a instituições. Dentre estas, as principais causas para doações e patrocínios estão o apoio a crianças ou jovens (39%).
Por fim, descobrimos que oito em cada dez pessoas (80%) concordam que as organizações sociais e organizações sem fins lucrativos “devem fazer parcerias com empresas para atingir seus objetivos”.
Personas (Pais/Responsáveis, Doadores)
A partir das pesquisas realizadas, foram elaboradas duas personas: a persona da Mãe trabalhadora e a persona do Doador altruísta, ambas reunindo características específicas levantadas na pesquisa qualitativa e características gerais levantadas na pesquisa quantitativa.
Fase 2: Análise + Definição
Mapeamento de atores envolvidos
As pesquisas ratificaram algumas hipóteses que já tínhamos estabelecido sobre o problema, principalmente quanto à complexidade logística de uma iniciativa deste tipo. Seria um empreendimento que, para manter boas práticas de usabilidade, eficiência e design de serviços, teria que levar em conta os principais atores dentro do ecossistema do nosso produto.
Definimos estes atores como:
- Pais/Mães/Responsáveis
- Doadores
- Escolas
- Fornecedores de materiais
- Serviços de logística
Ideia-Chave
Diante de um ecossistema tão amplo como o que foi apontado em nosso mapeamento, somado às descobertas realizadas em nossas pesquisas, percebemos que um serviço que conseguisse contemplar necessidades e demandas de atores variados precisaria de uma integração robusta.
Com a palavra “integração” em mente, percebemos que este deveria ser o conceito-chave por trás de nossa marca. Algumas artes iniciais foram esboçadas para formalizar essa ideia e, durante esse processo criativo, optamos pelo nome “Integra”.
Posteriormente, as artes iniciais foram refinadas até chegarmos em uma logo que conseguisse transmitir a ideia de integração entre Pais/Mães/Responsáveis e os Colaboradores (Doadores e Parceiros). Esta logo será apresentada adiante.
Roadmap de funcionalidades
Ainda pensando na natureza do projeto e na amplitude do ecossistema, foi utilizado um roadmap de funcionalidades para que a equipe conseguisse estabelecer metas e prioridades, além de objetivos a médio e longo prazo com relação às funcionalidades do produto.
Isso também serviu para que a equipe definisse claramente o que entregaríamos ao final do Hackathon, como Menor Produto Viável (MVP).
Fase 3: Ideação + Design
Conceito de Serviço/Service Design;
A partir das reflexões trazidas pelas pesquisas e outros passos das etapas anteriores, a equipe decidiu formular um conceito de serviço, de acordo com boas práticas de Service Design. Nosso conceito de serviço foi estabelecido como o seguinte:
“Nossa PLATAFORMA ajuda PAIS E RESPONSÁVEIS que precisam de AUXÍLIO NA AQUISIÇÃO de:
a) MATERIAIS ESCOLARES e
b) DISPOSITIVOS DE TELEFONIA E COMPUTAÇÃO, através da
- DIVULGAÇÃO da carência desses produtos,
- CAPTAÇÃO de recursos de doadores e
- INTEGRAÇÃO da logística na aquisição e entrega desses produtos.”
Deve ser ressaltado que a elaboração do conceito de serviço ocorreu em sincronia com as percepções alcançadas na confecção do Roadmap e, também, na própria formulação da Ideia-Chave, citada anteriormente.
Em linhas gerais, a dinâmica deste projeto não teve uma natureza exatamente linear, o que é respaldado tanto pelo Design Thinking, como em outros métodos de design centrado no usuário.
Business Model Canvas
Com o conceito de serviço e o roadmap de funcionalidades em mãos, a equipe utilizou a Business Model Canvas para formalizar os principais pontos e características relevantes ao serviço como um todo.
Isso nos permitiu enxergar de maneira holística a natureza do nosso projeto, o que gerou na equipe um entendimento comum sobre as diretrizes (implícitas e explícitas) de usabilidade do nosso produto. Cada decisão deveria estar norteada tanto por boas práticas de design UX e design de interação, como também pelos pontos propostos pelo design de serviços.
Canvas da proposta de valor
Para que pudéssemos explorar com mais atenção as tarefas, dores e ganhos de nossos usuários e definirmos com maior precisão como nosso produto/serviço agregaria valor para estes aspectos, foram utilizadas as Canvas de Proposta de Valor para os dois tipos de usuário da plataforma, a saber: Mães/Pais/Responsáveis e Doadores.
Canvas de valor da Rebeca (Mãe)
Canvas de valor do Rafael (Doador)
Branding e Logo
Após nos debruçarmos sobre o conceito de marca e o conceito de serviço, havia chegado a hora de desenvolver visualmente a mensagem que gostaríamos de comunicar. Como mencionado anteriormente, isso foi feito através da elaboração de uma logo inicial e, em seguida, de um refinamento sobre a mesma logo.
O resultado final foi este:
Guia de Estilo (I)
Juntamente com a nossa logo, também foi elaborado um guia de estilo para nortear o processo de design de interface da plataforma, bem como a parte de desenvolvimento front-end.
Este guia de estilo, entretanto, passou por adequações ao longo do processo devido a questões como: limitações de tempo e formação, e necessidade de entregas ágeis e dinâmicas.
Fase 4: Prototipação
Sketches, rabiscos, wireframes
Todos os processos de design de interfaces estiveram intercalados com o ritmo de trabalho dos desenvolvedores, o que possibilitou uma colaboração dinâmica e ajudou a minimizar riscos de retrabalho ou desperdício de tempo e recursos.
- Baixa-fidelidade
- Média-fidelidade
- Alta-fidelidade
Guia de Estilo (II)
De acordo com a evolução dos desenvolvedores, foi possível compreender melhor as limitações e necessidades visuais da implementação, portanto o guia de estilo foi complementado com novos componentes, como os botões.
Validação do layout com desenvolvedores
O processo de validação de layout ocorreu constantemente ao longo de todas as etapas de evolução do projeto, pois era necessário garantir um entendimento comum do que era possível ou não de ser implementado em termos de código, levando sempre em conta as limitações de tempo, formação e imprevistos técnicos.
Os desenvolvedores contribuíram ativamente para o design da interface, comunicando o que estava ao alcance de suas habilidades técnicas, ou não, e explicando claramente quais soluções propostas pelo design seriam viáveis ou não de serem implementadas.
Fase 5: Teste + Implementação & Entrega
Teste de Usabilidade (baixa-fidelidade)
Foi conduzido um teste de usabilidade com as telas em baixa-fidelidade criadas pela equipe UX.
A decisão por conduzir este teste em baixa-fidelidade ocorreu diante da necessidade de validação dos wireframes e da agilidade na condução do projeto, tendo a equipe escolhido garantir a realização de um teste, mesmo que em baixa-fidelidade, em contraponto a correr o risco de não realizar teste algum.
A apresentação de telas e a condução do teste com uma potencial usuária trouxe à tona informações importantes tanto para tomada de decisões em termos de Design e Desenvolvimento, como também para enriquecer a persona anteriormente elaborada.
O teste foi conduzido através de vídeo-chamada na plataforma Google Meet, onde o entrevistador compartilhou sua própria tela com a entrevistada, apresentando: 1) o contexto que estávamos avaliando (cadastro de novo usuário) e 2) as telas elaboradas em baixa-fidelidade, pertinentes ao mesmo contexto.
A usuária foi orientada a explicar, em voz alta, quais passos tomaria para se registrar na nossa plataforma, dando insights sobre possíveis melhorias no design de interface, em UX Writing, no design de interação e, também, contribuindo para a análise heurística.
Limitações & Melhorias
A equipe discutiu, em conjunto, quais foram as limitações encontradas ao longo do projeto, assim como melhorias que poderiam ser implementadas em fases futuras de desenvolvimento. Em linhas gerais, separamos nossas limitações e melhorias em três categorias: tempo, formação e comunicação.
Limitações & melhorias de tempo
Foi consenso entre todos os membros que o tempo proposto pelo Programa de Formação não foi ideal para que implementássemos as soluções mais dinâmicas e adequadas para o projeto. Isso acarretou dificuldades técnicas e de gestão, principalmente em relação ao entrosamento da equipe como um todo, o que poderia ter sido evitado caso o Hackathon tivesse uma duração maior.
Limitações & melhorias de formação
Todos, sem exceção, encontraram limitações técnicas e teóricas em suas respectivas áreas de atuação. Na parte de UX, por exemplo, a falta de familiaridade com o Roadmap de Funcionalidades impediu que a gestão do projeto fosse executada de maneira mais fluida.
Na parte de Desenvolvimento, houve limitações tanto dos responsáveis pelo Front-End, como do Back-End, por exemplo, na parte de integração entre os dois tipos de código e adequação às limitações que surgiram na fase de Back-End (o que acabou influenciando tanto o Front, como o Design). Além disso, a equipe foi reduzida pela metade, com a saída de duas integrantes, cada uma responsável por uma Stack. Isso fez com que os Desenvolvedores restantes ficassem sobrecarregados e precisassem se adaptar a técnicas ainda não dominadas.
Limitações & melhorias de comunicação
Pelo fato de nós ainda não termos tido a experiência de ter trabalhado em um projeto juntos (e pelo pouco tempo), alguns dias foram necessários até que estivessem todos alinhados de forma concreta. Vale ressaltar, entretanto, que todos, sem exceção, foram extremamente educados e compreensivos, sempre escutando a opinião de cada um e, juntos, buscando a melhor solução e entendendo as limitações de cada um.
A questão de conciliação de horários e rotinas da equipe também foi um fator determinante para o desempenho de nosso trabalho. Além disso, os ambientes utilizados por cada equipe eram, de certa forma, “distantes” da realidade de cada um. O pessoal de Desenvolvimento teve de se habituar à dinâmica do Adobe XD, assim como o pessoal de Design teve de se habituar à dinâmica do GitHub, por exemplo.
Muitos bloqueios de comunicação ocorreram a partir desse tipo de situação, o que sinalizou uma falta de entendimento comum (entre todos) das funções e limitações de cada equipe.
Por fim, concordamos que a existência de um briefing mais detalhado, anterior à execução do projeto, permitiria que a equipe tivesse direcionamentos mais concretos e assertivos sobre a execução. Além disso, consideramos que seria muito proveitoso para os envolvidos se tivéssemos tido a oportunidade de participar de dinâmicas de grupo anteriores à execução.
Conclusão
Com esta experiência, em um próxima oportunidade, já saberíamos com mais rapidez por onde iniciar. Teríamos mais noção sobre o “passo a passo”, bem como sobre a divisão otimizada das tarefas.
Sem dúvidas, o Programa de Formação da FCamara traz aos candidatos uma oportunidade de crescimento e aprendizado profissional que se assemelha intensamente com a realidade do mercado de trabalho. Todos os membros da equipe sentem que aprenderam bastante com o Programa e que, agora, estão prontos e capacitados para participarem de mais projetos da mesma natureza, seja na parte de Design ou Desenvolvimento.
Este artigo e o projeto referido foram realizados com a colaboração das seguintes pessoas:
André Lacerda (Desenvolvimento)
Ariel Pirangy (UX/UI Design)
Guilherme Fittipaldi (Desenvolvimento)
Shanya Koffke (UX/UI Design)
Links:
