Como pensamos o redesenho do Wikilegis
Neste post mais técnico, vamos falar como usamos a mentalidade do Design Thinking para perceber melhor problemas ocultos e solucioná-los com eficiência
Antes de mais nada, por que uma nova versão do Wikilegis? A versão anterior não era boa o suficiente?
Aqui no LAB, já nos questionávamos naturalmente sobre isso, nos perguntando por que as contribuições em proposições abertas para consulta pública não eram adotadas com tanta frequência. E por quê? Percebemos que o modelo utilizado não era o ideal, já que exigia um conhecimento de regras de legística dos cidadãos, que tinham que reescrever diretamente o trecho do texto legislativo, ocasionando dificuldades de análise para os consultores legislativos, parlamentares e seus gabinetes. A resposta completa pode ser encontrada no texto que nosso hacker diretor-adjunto, Walternor Brandão, escreveu. Dá uma olhadinha lá!
Analisando previamente
Dito isto, nosso primeiro passo foi uma análise prévia interna com nossa equipe para pensar quais eram os principais problemas afetando o Wikilegis.
Nos questionamos se a plataforma deveria ser uma Wiki, já que tinha esse prefixo em seu nome. Entendemos que não, pois ela se afasta muito do conceito de Wiki, cujo conteúdo é feito colaborativamente, sem controle de acesso e administrado exclusivamente pela própria comunidade. As funcionalidades exigidas para alcançarmos o resultado almejado com a ferramenta precisavam ser mais complexas que as de uma Wiki tradicional, mas mantivemos o nome pela familiaridade com a ideia de “construção colaborativa”, popularizada pela Wikipédia.
A partir daí, identificamos problemas de usabilidade para o cidadão e para o parlamentar, sua equipe do gabinete e consultores legislativos. Decidimos que o foco da equipe ao aprimorar o Wikilegis deveria estar na experiência de uso dos consultores legislativos na etapa de análise pós-participação. São eles que, efetivamente, mergulham nas leis e estão sempre presentes na construção de proposições legislativas da Casa lado a lado com parlamentares e seus gabinetes.
Ora, se os consultores legislativos se sentem sobrecarregados ou não estão confortáveis nesta fase, as proposições abertas para consulta pública não tem de fato sua participação analisada e passada para os parlamentares para consideração. O resultado prático disso é que o cidadão fica a ver navios, esperando uma resposta que nunca vem.
O fato é: acreditamos que o Wikilegis, além de ter que ser acessível aos cidadãos e promover a participação popular, deve ser acessível para a Casa e focado nos parlamentares também. Assim, é mais provável que as contribuições dos cidadãos sejam consideradas por eles.
Organizando as ideias
Como reunir essas informações de forma organizada e construir soluções em cima delas? Encontramos a resposta para essa pergunta no Design Thinking (uma mentalidade). A partir de pesquisas de campo e outras ferramentas desse mindset, identificamos problemas e pudemos idear possíveis soluções.
Tá, mas o que é esse tal de Design Thinking? É uma mentalidade, e não metodologia, para identificar e solucionar problemas, geralmente com trabalho colaborativo e multidisciplinar. Ele consiste em cinco etapas, que podem ser revisitadas (iteradas) a qualquer momento: Empatizar, Definir, Idear, Prototipar e Testar. Grave bem todas elas, retomaremos isso mais tarde!
Existem várias dinâmicas de trabalho (ferramentas) documentadas para cada uma dessas etapas encontradas em várias referências por aí. No nosso caso, usamos o TCU Toolkit para dar os primeiros passos. É um kit bem organizado, e totalmente em português :)
Combinamos uma rodada de ideação com um grupo de sete consultores servidores da Câmara para nos ajudar a descobrir o que poderia tornar o trabalho deles mais fácil e como o Wikilegis poderia contribuir para isso.
A dinâmica consistia em duas etapas de 5 minutos cada: na primeira cada um escrevia, em post-its individuais, problemas e dificuldades de seu trabalho como consultor (a) legislativo (a). Na segunda, escreviam possíveis soluções para os problemas definidos. Este foi um processo similar à metodologia que usamos no Nós do LAB (que foi uma evolução desta abordagem usada no Wikilegis).
Após este momento, abriu-se espaço para debater e clusterizar (organizar em grupos), os post-its. Formaram-se 7 clusters que nortearam todo o restante do processo de redesenho do Wikilegis. Tomamos mais algum tempo para que todos os consultores votassem nos clusters que acharam mais importantes (para priorização) e encerramos a ideação inicial por aqui. Foi incrível como conseguimos registrar um grande volume de insumos em apenas 1 hora.
E acertamos em cheio! Os resultados foram alinhados com nossas suposições de análise prévia interna. Para o Wikilegis evoluir, era necessário dar atenção não só para o cidadão, mas também para os consultores e parlamentares, facilitando não apenas o trabalho de análise das participações feitas no próprio Wikilegis, como também o seu trabalho usual.
Entrevistando os consultores legislativos
Marcamos entrevistas individuais com cada um do grupo de consultores que havia sido formado na rodada de ideação, além de alguns outros consultores da Câmara e do Senado. A intenção das entrevistas era adquirir dados qualitativos, para que gerássemos empatia pelo trabalho dos consultores e mergulhássemos em suas realidades, explorando os problemas que afetam sua rotina.
Andando em círculos nas definições, partimos para um Design Sprint!
Estávamos apenas em três quando esboçamos como deveria ser o fluxo de uso da nossa solução: eu e Petterson Alves, como especialistas de interfaces e experiência do usuário, e Walternor Brandão, como idealizador e gerente do projeto. O restante da equipe de desenvolvimento não estava presente nas reuniões, por estarem atribuídos em outros projetos, e nós não tínhamos a quantidade de pessoas e especialistas necessários para tomar decisões de fato. Por conta dessas adversidades, estávamos apanhando um pouco.
Mas por quê? Imagine que você vai fazer um bolo e tem só a lista dos ingredientes. Se você não é um expert em bolos, provavelmente vai ser difícil seguir uma ordem específica. Por isso, é importante ter as instruções também. As ferramentas do Design Thinking são como ingredientes e, para sair com um resultado concreto, usamos o Design Sprint (metodologia), que é como uma receita com ingredientes específicos.
A ideia do Design Sprint é usar um roteiro claro (nossa receita) que passa pelas cinco etapas do Design Thinking de forma ágil, originalmente em cinco dias com um objetivo específico. O ideal é que a equipe participe na íntegra de todos os estágios de um Design Sprint, mas já existem versões adaptadas, como a da AJ&Smart, que usa apenas quatro dias, dividindo dois dias usando a equipe toda e outros dois com alguns especialistas. Hoje em dia, nos Sprints do LAB, utilizamos o roteiro completo da AJ&Smart no que eles chamam de Design Sprint 2.0. Você encontra todos os passos ensinados em uma playlist do YouTube deles e com o roteiro documentado no Sessionlab (em inglês). Após algumas experiências nossas, este é o modelo de Design Sprint que recomendamos aos nossos parceiros, pois dá mais flexibilidade para gestores participarem das etapas importantes de decisão, necessitando estarem presentes por apenas dois dias, algo mais fácil de se aplicar, especialmente no serviço público, onde a alta gestão normalmente está ocupada em reuniões durante boa parte de sua rotina diária.
Mas nem sempre foi assim, para o Wikilegis, não conhecíamos esse método atualizado, e nos inspiramos em fazer nossa própria receita, usando mais ferramentas lá do TCU Toolkit e também do Google Ventures Design Sprint Kit (em inglês), criando um roteiro personalizado dividido em duas partes.
A primeira que, em dois dias, passava pelas etapas de Empatia, Definição e Ideação, com uma equipe que incluía membros do time de desenvolvimento, e a segunda que passava pelas etapas finais de Prototipação e Testes e foi realizada apenas com especialistas de desenvolvimento de interfaces. Nesta parte decidimos que precisaríamos de uma semana inteira, pois estávamos apenas em dois, eu e Petterson Alves.
Após planejar nosso roteiro, definimos um objetivo claro que deveria ser considerado durante toda a Sprint para não nos perdermos: “Como podemos tornar o Wikilegis útil para os consultores legislativos da Câmara dos Deputados, e por consequência, o cidadão?”.
Eu e Petterson nos dispusemos como facilitadores e, juntos a equipe, colocamos mãos à obra durante dois dias intensos de muitas dinâmicas e aprendizados… Mas deu tudo certo!
Concluímos a primeira etapa entendendo que dois protótipos com funções distintas precisariam serem feitos e testados. Um para a parte de interação com o cidadão, e outro para a parte de interação com o consultor.
Prototipação de baixa fidelidade com Google Docs e teste com usuários
Na Sprint, percebemos que, para atender as necessidades do consultor com novas funcionalidades, precisaríamos mudar o modelo de participação social. Nos inspiramos nos comentários de texto do Google Docs e Medium para desenvolver um formato simplificado de entrada de opiniões utilizando seleção de texto. Além da possibilidade de avaliar as opiniões, similar à oferecida por ferramentas como Pol.is e Tinder.
A forma mais rápida e de baixa fidelidade de prototipar esse modelo foi a criação de um documento no Google Docs com um texto de projeto de lei real com regras para interação. Por exemplo: para opinar, a pessoa só poderia comentar um artigo por vez e, para avaliar opiniões, deveria responder aos comentários existentes com “+1” para “Concordo”, “0” para “Indiferente”, e “-1” para “Discordo”.
Para o teste, contamos com a participação da equipe do LAB e outros parceiros, obtendo dados reais para testar algumas coisas: agrupar comentários parecidos usando um algoritmo de análise de semelhança de textos, agrupar usuários que pensam parecido, e fazer análise de consenso em opiniões. Além disso, estes dados seriam usados no desenho do segundo protótipo, de maior fidelidade, voltado para o consultor.
Protótipo de maior fidelidade com Figma e teste com consultores
Após este teste, usamos os dados adquiridos para desenhar um protótipo de maior fidelidade para a parte do consultor. Optamos por usar o Figma, ferramenta multiuso de design que nos dá flexibilidade para desenhar telas de baixa ou alta fidelidade, além de permitir prototipagem interativa com os elementos do desenho.
O desafio aqui era desenhar as novas funcionalidades pensadas para o consultor de forma não tão básica como um wireframe, mas também não tão detalhado como uma tela de produto final. Era necessário ilustrar funções como: inserir um texto de proposição, abrir uma proposição para participação pública ou privada, convidar pessoas, editar dados sobre a proposição, mostrar opiniões agrupadas, editor de texto legislativo com ordenação automática de dispositivos, versionamento de texto, compartilhar, e visualização de participações para análise.
É importante ressaltar que a funcionalidade de mostrar opiniões agrupadas envolviam um tempo maior de testes com algoritmos de aprendizado de máquina para análise de textos semelhantes, e assumimos que seria algo aprimorado com o tempo durante o desenvolvimento da ferramenta. Essa funcionalidade por fim se mostrou inviável após sua implementação e usamos uma alternativa que não envolvesse inteligência artificial. Pretendemos escrever um post técnico em breve acerca apenas dessa experiência, mas para fins práticos, podemos afirmar que mesmo não conhecendo a complexidade do caminho necessário para alcançar essa solução, podíamos desenhar um modelo dela implementada no protótipo para os consultores.
O resultado final dessa etapa foi um protótipo interativo de média-alta fidelidade, com um onboarding (algo parecido com um tutorial) para cada funcionalidade da ferramenta a fim de explicar melhor para o consultor o que o Wikilegis se prestaria a fazer. Fizemos testes individuais com tarefas claras para testar cada funcionalidade com todos os consultores com os quais interagimos anteriormente. Para eles, a futura versão do Wikilegis prototipada atendia diversas necessidades, tanto para a análise de participações, quanto para auxiliar em atividades corriqueiras do seu dia-a-dia de trabalho. Por fim, se sentiram muito satisfeitos e felizes com atenção que demos a eles e com o protótipo gerado, que foi validado. Sucesso!!
Processo concluído, e agora?
Partir para o tão esperado desenvolvimento!
Eu como desenvolvedor, posso dizer que esta etapa prévia nos gera bastante ansiedade pois queremos muito colocar logo a mão na massa, mas posso afirmar com todas as palavras que parar um tempo para questionar de fato quais são os problemas que precisamos resolver, conversar com o usuário final, entender suas necessidades e idear colaborativamente com um processo bem definido, ajuda MUITO a ter clareza e objetividade na hora de escrever o código e tirar o projeto do papel.
É comum os gestores e outros envolvidos acharem que podem ser um ou dois meses perdidos em que não se desenvolve algo, mas pense que este é um tempo utilizado que norteará melhor seus objetivos e na verdade economizará três meses, seis meses ou até um ano de trabalho de sua equipe que correria o risco de desenvolver uma ideia que só seria validada após sua entrega final. Acredite, é melhor até invalidar seu projeto cedo e partir para outra ideia logo do que gastar muitos recursos desenvolvendo algo sem a certeza de que lá na frente funcionará para seu público-alvo.
Agora nós queremos ouvir você! Que tal conferir como o Wikilegis ficou? Nos mande suas dúvidas, opiniões e sugestões, tanto sobre o Wikilegis em si quanto sobre o processo que norteou seu planejamento. Fale com a gente em nossas redes sociais e comente neste post também o que você achou!
