O desafio

O desafio era propor uma solução que ajudasse a conectar jovens da periferia ao primeiro emprego.

O desafio foi escolhido devido à relevância do tema e possível impacto social. Ao final, nós desenvolvemos um protótipo de um site de vagas que foca em aumentar a qualificação dos jovens oferecendo sugestões personalizadas de cursos gratuitos.

Cenário atual

Com uma taxa de desemprego de 22,8% entre os jovens de 18 a 24 anos no Brasil, (maior que o dobro da média geral do país de 11,1%) (PODER 360), o desafio pode ser classificado como um wicked problem, ou problema capcioso, pois há muitos fatores e stakeholders envolvidos, e não é possível encontrar uma única solução que resolva tudo (ALINE MELO).

Também é preciso levar em consideração que, quando falamos de primeiro emprego e jovens de periferia, há muitas questões e preconceitos que tornam esse processo ainda mais difícil. Algumas dores desses jovens que identificamos com pesquisas primárias e secundárias foram:

• Falta de experiência
• Falta de qualificação
• Falta de indicações
• Dificuldade de acesso a equipamentos e computadores
• Preconceito em relação a cor, sexualidade e lugar onde moram (distância do trabalho)

Diante desse cenário complexo e do tempo limitado para execução do projeto, foi necessário focalizar as pesquisas em um objetivo e público específico. Detalhes sobre os critérios utilizados para essa priorização serão abordados a seguir:

Usuários

Consideramos os próprios jovens de periferia que procuram um primeiro emprego como nosso ator principal. Nesse estágio inicial, nossa maior preocupação era garantir que a solução tivesse o potencial de ajudar esses jovens a cumprir seus objetivos.

Por isso, focamos em buscar entender exatamente que objetivos são esses, e em que contexto eles estão inseridos.

Conhecendo o usuário

Nosso primeiro passo de pesquisa sobre a proposta do tema, foi buscar informações em fontes secundárias sobre algumas das principais dores que os jovens de periferia podem experienciar para encontrar um primeiro emprego. Sobre isso, encontramos diversos artigos falando sobre questões de preconceitos estruturais (PT); baixos índices de escolaridade (NA PRÁTICA) e dificuldade de acessar internet em casa (PORTAL APRENDIZ).

No entanto, ainda tínhamos muitas dúvidas, principalmente sobre como essas questões se manifestam no dia a dia do nosso público, e por isso decidimos contactar diretamente potenciais usuários através de técnicas de pesquisa primária.

Pesquisa quantitativa

Para recrutar pessoas para a nossa pesquisa e responder as dúvidas da matriz CSD, compartilhamos um questionário pelas redes sociais (Whatsapp, páginas do Facebook e Instagram). Ele estava dividido em sessões, com perguntas objetivas e discursivas, e ao final também pedíamos para a pessoa deixar o número do celular caso ela se dispusesse a responder mais perguntas futuramente.

Na primeira seção do formulário, fizemos algumas perguntas para filtrar as pessoas que faziam parte do público-alvo que estávamos procurando:

Qual a sua idade? — Queremos pessoas jovens. Também é útil para determinar qual a faixa etária que vamos considerar como “jovem”.

Você mora em periferia? — Queremos pessoas que moram na periferia

Qual a sua situação profissional? — Queremos pessoas que estão buscando um primeiro emprego. Mesmo assim, não descartamos as respostas de quem já conseguiu um. Nesse caso, direcionamos essas pessoas para uma nova seção em que perguntamos sobre quais foram as principais dificuldades que elas enfrentaram nesse processo e o que as ajudou a ter sucesso.

Ainda na primeira seção, também pedimos algumas informações sobre raça, gênero, escolaridade e acesso a internet. Nosso objetivo era confirmar se existia uma relação entre esses dados e a dificuldade de encontrar um emprego, como apontado pela nossa pesquisa anterior, e identificar esses possíveis usuários para futuro contato.

Algumas das perguntas feitas para quem já teve um primeiro emprego:

O que você acredita que te ajudou a ingressar na vaga de emprego? — Insights para futuras soluções e identificar aliviadores de dores

Quanto tempo você demorou para encontrar o primeiro emprego? — Uma métrica para medir a dificuldade de conseguir o primeiro emprego e relacionar com as outras informações

Algumas das perguntas feitas para quem ainda está buscando um primeiro emprego:

O que você acha que está te dificultando a ingressar no mercado de trabalho? — Identificar pontos de dores dos usuários

Geralmente, por onde você busca ou fica sabendo de oportunidades de emprego? — Identificar canais aos quais os usuários têm acesso

Obtivemos 23 respostas no total e 6 respostas que passaram pelos 3 filtros. Não foi a quantidade que gostaríamos, mas dentre os dados que conseguimos coletar, alguns dos que mais chamaram a atenção foram:

O gráfico 1 mostra que uma solução online pode ainda ser viável, apesar das nossas preocupações, principalmente se pensarmos nela para o formato mobile, vinculada a redes sociais (gráfico 4).

Além disso, no gráfico 2, identificamos que os jovens acreditam que indicação e qualificação são os principais fatores que os ajudaram a ingressar numa vaga de emprego. Apesar de todas as pessoas que ainda não encontraram um emprego terem a tendência a culpar fatores externos a elas, como falta de oportunidades e poucas vagas (gráfico 3).

O restante das dúvidas foi sanado por meio de entrevistas individuais. Nesse sentido, o formulário foi muito útil como fonte de informações para nos ajudar a elaborar perguntas para entrevistas e recrutar pessoas para uma pesquisa qualitativa.

Pesquisa qualitativa

Após fechar o formulário da pesquisa quantitativa, separamos 6 contatos de jovens de periferia que estão buscando um primeiro emprego, e conseguimos marcar entrevistas individuais com 3 deles.

As entrevistas foram realizadas de forma virtual com um roteiro semi-aberto, que dividimos em 5 sessões:

• Introdução: Perguntas iniciais para quebrar o gelo: onde a pessoa mora, se ela está estudando, etc.
• Motivação: Entender as dores que o jovem pretende sanar com um emprego, seus objetivos a longo e curto prazo e que tipo de emprego ele está buscando.
• Tarefas: Entender como é a jornada do usuário e o papel de soluções digitais, para verificarmos se o digital realmente seria o melhor caminho.
• Dores: Identificar a percepção do usuário sobre o que ele acha que está prejudicando a sua busca por um emprego e que soluções ele já tentou buscar.
• Qualificação: Esse tema foi apontado como um possível aliviador de dores na pesquisa quantitativa, por isso decidimos explorar mais essa questão perguntando sobre os requisitos que são pedidos nas vagas de emprego às quais a pessoa entrevistada já se candidatou, e o que ela fez no caso de não possuir algum desses requisitos.

Pedimos consentimento para gravar todas as entrevistas, e depois dividimos e agrupamos as falas dos entrevistados em clusters por tema. Usamos essa técnica para identificar pontos em comum nas falas dos possíveis usuários e poder começar a organizar e sintetizar as informações em um quadro geral.

Os principais aprendizados dessa etapa foram:

• Os entrevistados têm tendência a procurar um primeiro emprego no final/logo após o Ensino Médio;
• Eles buscam um emprego para ajudar a família, ou para ter um dinheiro sobrando para transporte e atividades de lazer;
• Nessa época, eles não buscam um emprego com a ideia de formar uma carreira, mas para atender seus objetivos imediatos;
• Ao buscar um emprego, eles dão preferência a vagas aos quais eles tenham as qualificações necessárias (por exemplo, se a pessoa sabe inglês, provavelmente vai buscar uma vaga que exija isso, se ela não tiver, vai eliminar essas opções);
• Quando perguntados sobre as suas dores, eles culpam fatores externos a eles, e quando perguntados sobre o que eles poderiam fazer para melhorar as suas chances de conseguir um emprego, a única coisa que mencionaram foi fazer cursos, mas falaram isso de forma desanimada, pois acreditam que cursos são muito caros. Às vezes eles chegam a buscar por cursos e conteúdos gratuitos, outras vezes só assumem que isso não existe ou não será viável;
• Em geral, eles buscam por empregos nas redes sociais, foram citados grupos de facebook e páginas de emprego no twitter;
• Dificuldade de acesso a internet não é o problema, o problema é ter acesso a computadores.

Com essas informações, conseguimos traçar um perfil do nosso usuário ideal, que resumimos no mapa da persona abaixo. Nas próximas etapas, usamos o que foi aprendido na pesquisa com os usuários para justificar nossas escolhas na geração e priorização de ideias e desenvolvimento do produto.

Oportunidades e alternativas de solução

Após a pesquisa com usuários, elencamos 5 oportunidades baseados nas dores que foram identificadas:

• Como nós podemos conectar jovens de periferia à qualificação técnica para que eles cumpram os requisitos das vagas de emprego que desejam?
• Como nós podemos providenciar o acesso a computadores para que os jovens de periferia possam praticar e qualificar qualificações importante?
• Como nós podemos baratear o custo de locomoção para que os candidatos da periferia possam ser aprovados nas primeiras fases de processo seletivos?
• Como nós podemos conectar jovens de periferia àqueles que podem lhes indicar para vagas de emprego, para que eles possam ter vantagem em processos seletivos?
• Como nós podemos fazer jovens de periferia ganharem experiência para que eles possam ter vantagem em processos seletivos?

Depois, realizamos uma sessão de brainstorm em que cada membro do grupo contribuiu com uma ou mais sugestão de projeto para cada um desses tópicos. Nosso objetivo nessa etapa era abrir as possibilidades para várias alternativas de projeto, e estimular o envolvimento de todos os membros do grupo na construção da solução.

Para decidir qual das ideias listadas era mais apropriada para nosso público (e para nós), utilizamos uma matriz de priorização impacto x esforço (imagem abaixo). Nela, consideramos o potencial de cada solução de ajudar o usuário a conseguir um emprego (vertical) e a dificuldade de execução (horizontal).

A solução

Optamos por seguir pela opção que consideramos menos esforço e de maior impacto (canto superior direito no gráfico):

Uma plataforma de emprego que oferece sugestões de cursos gratuitos de acordo com as vagas que os usuários interagem na plataforma.

Chamamos o nosso produto de Qualificaí, a partir da palavra “Qualificação”, tema que permeia a nossa solução.

Fluxo do site e wireframes

Para garantir que todos os membros do grupo estavam alinhados, foram tomadas decisões do plano mais geral para o mais específico. Assim, antes de desenhar a interface, nós começamos desenvolvendo o fluxo do site, com objetivo de determinar como os usuários navegam por ele e quais telas precisávamos desenvolver.

Nesse momento, nós não precisávamos desenvolver todas as páginas, mas apenas as telas do fluxo principal, com fins de MVP.

Essas telas foram desenvolvidas primeiro no formato de wireframe, para que, em conjunto, nós tivéssemos facilidade de decidir os elementos que estariam em cada página e o espaço que cada um deles ocuparia na tela.

Tanto para o fluxo, quanto para os wireframes, nós optamos por utilizar ferramentas digitais (figma), que facilitassem a colaboração à distância e que permitissem que todos pudessem editar os documentos ao mesmo tempo.

Fluxo principal e telas a serem feitas:

• O usuário encontra uma postagem em um grupo de rede social divulgando uma vaga (com um link para o nosso site).
• O link redireciona a pessoa para a página que contém uma descrição e detalhes da vaga no nosso site.
• Ao clicar em se inscrever na vaga, é requisitado um primeiro login, de acesso rápido, para adquirirmos leads.
• Depois da pessoa ser redirecionada para se inscrever na vaga, o nosso site exibe uma página que chamamos de sucesso de inscrição.
• Agora, o usuário pode querer usar o sistema de busca por vagas. Nessa página há algumas sugestões de busca filtradas, baseadas nas respostas que obtivemos na etapa de pesquisa com os usuários (ex: vagas para menos de 18 anos, vagas perto da minha casa, vagas que combinam com meu perfil...)
• Ao fazer uma busca ou selecionar uma das opções de filtragem, o usuário é direcionado para a página de resultados da pesquisa, que mostra uma listagem de vagas pelas quais ele pode se interessar, e cursos gratuitos que correspondem aos requisitos pedidos pela maioria das vagas dos resultados.
• Ao selecionar uma vaga, o usuário volta para a página com detalhes da vaga selecionada, e ao selecionar um curso, ele é direcionado para a página do curso.

Uma observação interessante sobre a página de Primeiro login, é que ela se chama Primeiro login porque, eventualmente, seria interessante se os usuários preenchessem mais informações sobre eles mesmos para que pudéssemos oferecer sugestões mais personalizadas de vagas e cursos, mas não queríamos exauri-los com um formulário longo nesse momento em que eles estão acessando o site pela primeira vez.

Mesmo assim, pensando nos objetivos de negócio, é muito importante que adquiramos leads, então nós decidimos manter uma etapa de login inicial com as informações mais importantes, muito rápido de preencher, e deixamos a opção de poder usar filtros e sugestões personalizadas como um recurso não-obrigatório para heavy users que estariam dispostos a preencher um formulário mais longo. No entanto, assim que os novos usuários se inscreverem numa vaga, o site passa a lhes mostrar um popup lhes lembrando de preencher seu perfil.

Sobre os aprendizados dessa fase, é interessante mencionar que foi nessa etapa que vimos que seria mais interessante que o projeto se tratasse de um site mobile e não um aplicativo. Isso porque queríamos aproveitar o comportamento habitual dos usuários de buscar vagas nas redes sociais, usando postagens de grupos de Facebook e páginas de Twitter para direcioná-los para a nossa solução.

Ora, um aplicativo representaria uma grande interrupção no fluxo, pois, ao primeiro contato, o usuário teria de verificar se teria espaço no celular e esperar o tempo de download, o que demanda certo tempo e poderia ocasionar a perda de interesse pela vaga. Com um site mobile, no entanto, conseguimos deixar essa etapa do fluxo mais rápida.

Importante exaltar que chamamos a atenção dos jovens com vagas e não cursos, porque, como vimos na nossa pesquisa, nosso público-alvo não costuma procurar por cursos, por não acharem que eles se adequam a sua realidade. Por isso, achamos importante apresentar sobre os cursos em um contexto aliado com as vagas, para que possam parecer mais interessantes, sirvam de guia para quem está perdido tentando entrar no mercado de trabalho, e mostrar que existem cursos gratuitos sim!

Guia de estilos

Cores

Antes de partir para o desenvolvimento das telas em alta fidelidade, definimos as cores base do nosso site e do brand.

A cor azul foi escolhida por ser uma cor neutra, para comunicar com todos os gêneros, transmitindo seriedade e segurança. Já a cor accent, ou secundária, foi escolhido o laranja, sendo essa uma cor ligada à jovialidade (nosso público) e alegria. Além disso, são cores complementares no círculo cromático, o que faz ter uma boa harmonia e contraste. Ao utilizar as cores na UI, criamos variações de tons das cores escolhidas.

Para compor toda a interface, configuramos uma escala de cinza para background e outros detalhes.

Também definimos no guia de estilo as cores possíveis para os textos. Na cor Black text não utilizamos a cor 100% preto para não comprometer a harmonia da tela e a leiturabilidade.

Além disso, foram configuradas cores helpers(cores de apoio), que são utilizadas principalmente para dar feedback visual ao usuário sobre alguma informação. O vermelho passa a ideia de perigo ou erro, por isso erros mais graves são entendidos facilmente com essa cor. Verde é entendido como positivo, então utilizamos esta cor em mensagens de sucesso. Amarelo segue a linha de “atenção”.

Tipografia

A fonte Poppins foi escolhida por ser sans-serif, transmitindo modernidade, possuir muita clareza em sua forma, legibilidade e muitas variações de peso, o que ajuda na hierarquia tipográfica.

Poppins é uma fonte Google, portanto, nos navegadores mais comuns já vem pré-carregada, assim gerando um ganho de performance nos aplicativos web.

No guia de estilo, definimos os Headings de 1 a até 3, tamanho das fontes e espaçamento entre linhas para desktop e mobile separadamente.

Botões

Buscamos deixar todos os botões com bom contraste para legibilidade e espaçamento suficiente para a área de clique.

Botões foram criados no figma em um único componente com combinações de variantes. Essa prática permite uma boa organização para utilizar o componente no layout. Além disso, as variantes foram criadas com autolayout e com a nova função do figma de propriedade do componente. Com isso, definimos propriedades de content, instance swap e boolean. Com a content, podemos mudar a chamada do texto facilmente. Com instance swap, podemos trocar o ícones do botão apenas organizando os ícones por pastas. E com boolean, podemos escolher se o ícone aparece a esquerda, a direita ou em nenhum dos lado.

Componentes de formulários

O formulário necessário até esta etapa foi o input text. Então, criamos apenas ele, porém com variantes. Utilizamos o conceito de design atômico para o .Base input, onde se encontram os componentes separados que, ao ter suas instâncias organizadas juntas, vemos o componente input text com diversas possibilidades.

Neste componente, vemos o título, o input (com placeholder) e uma mensagem de apoio na parte inferior direita. Configurando as propriedades desse componente, é possível escolher quando aparece o ícone de visualizar senha, quando aparece a mensagem, que tipo de mensagem aparece e outras combinações. Sempre visando a escalabilidade e consistência de um futuro design system.

Design System e Escalabilidade

O guia de estilo foi pensado e configurado no figma para ser um início de um design system mais robusto com consistência no design. Pois, utilizamos conceitos de design atômico, e todos os botões, formulários, cores, tipografia, headings, figuras, ícones, cards, itens de navegação, etc, estão componentizados.

Com isso, temos uma escalabilidade muito consistente e prática, para caso seja necessário a criação de novas telas para testes e afins.

Protótipo de alta fidelidade

Próximos passos

Neste case, mostramos como o trabalho de research e conhecimento dos usuários se traduziu em uma boa experiência, com uma solução e telas de interface mobile.

Para conclusão do MVP, o primeiro passo óbvio é testar o protótipo desenvolvido com representantes do público alvo escolhido, para garantir padrões básicos de usabilidade e interação. Depois disso, podemos pensar nas telas fora do fluxo principal e em novas funcionalidades, como ajudar o jovem a montar o próprio currículo, entre outros.

Além disso, futuramente o ideal seria considerar os pontos de contato de outros stakeholders sobre a plataforma, como recrutadores e instituições beneficentes.

Mas já que estamos falando sobre expandir nossa audiência, também é importante ressaltar que será importante fazer um acompanhamento do amadurecimento dos jovens que utilizam a nossa plataforma. Veja, hoje o objetivo deles é conseguir um primeiro emprego, o que esperamos que aconteça, principalmente com o auxílio da nossa solução. Depois disso, suas necessidades serão outras, e então nós temos a oportunidade de lhes oferecer novos produtos e serviços.

Se tiver alguma dúvida ou interesse em falar conosco, pode me enviar uma mensagem por email ou pelo linkedin:

amandalha@gmail.com

www.linkedin.com/in/amanda-carvalho-monteiro-86384520a

E foi com base nisso que eu acabei desenvolvendo o Facileitor, um projeto de UX/UI design para auxiliar redatores a escreverem textos mais fáceis de serem lidos pelo seu público. Nesse estudo de caso, dividido em duas partes você pode acompanhar todo o desenvolvimento do projeto, desde a pesquisa e identificação das dores, até o protótipo e testes de usabilidade.

Na primeira parte eu falo como:

• Descobri que essa dor, particular da minha realidade, atingia outras pessoas e de que maneira;
• Identifiquei a que grupos essas pessoas pertencem e quais suas características;
• Tomei decisões quanto ao público-alvo e escopo do projeto.

Abaixo está um mapa-ilustrativo das etapas da parte 1:

Já na segunda parte, eu explico:

• Sobre o desenvolvimento da solução em si, incluindo detalhes do funcionamento das fórmulas de APIs;
• Características da linguagem visual das interfaces
• Como se passaram os testes de usabilidade e feedback dos usuários.

Abaixo está um mapa-ilustrativo das etapas da parte 2:

Facileitor: Estudo de Caso parte 2

Na primeira parte desse estudo de caso, nós vimos como eu cheguei à conclusão da necessidade de uma ferramenta que medisse fatores quantitativos da leiturabilidade em português, estudo de soluções já existentes e definição do público-alvo. Agora, chegamos na segunda parte, na qual falaremos mais da elaboração a solução em si.

Sumário (parte 2):

• Geração de Ideias
• Sobre as Métricas
• Wireframes
• A Interface e seus Componentes
• Nome e Logo
• Gráficos
• Teste de Usabilidade

Geração de Ideias

“O caminho para ter boas ideias é ter várias ideias e jogar as ruins fora.” — Linus Pauling

Antes de se chegar à conclusão de qual seria a solução final do projeto, foram pensadas em outras possibilidades que poderiam atender as mesmas necessidades do público. Essas foram algumas das ideias que surgiram nesse processo:

• Mostrar variação do nível de leiturabilidade ao longo do texto:

Essa na verdade foi uma das primeiras ideias que surgiu ainda antes da definição do público-alvo. A questão era que todas as formas de medir a leiturabilidade consideravam o texto como um todo, minha ideia era buscar uma forma de representação que mostrasse a diferença entre níveis de leiturabilidade em diferentes partes do texto. Isso foi pensado inicialmente para indicar também a variação do ritmo da leitura, pensando principalmente em obras literárias de várias páginas.

No contexto de textos jornalísticos, no entanto, essa questão já não parecia mais tão relevante, logo a ideia foi descartada

• Processador de texto que mede a leiturabilidade e influencia o redator a escrever na estrutura correta:

Nessa solução, o objetivo não era apenas indicar o nível de leiturabilidade, mas fornecer uma interface que influenciasse o redator a pensar em um assunto por parágrafo (ao separar os parágrafos em caixa) e escrever parágrafos menores (fornecendo, inicialmente, uma caixa de texto pequena).

Chegou-se a desenhar alguns rascunhos dessa solução, mas ela também foi descartada uma vez que se percebeu que seria difícil convencer uma pessoa trocar um processador de texto com o qual ela já está acostumada por outro novo, além de que essa solução já se afasta um pouco da proposta inicial de introduzir elementos quantitativos na análise da leiturabilidade. O ideal seria uma solução que inicialmente permitisse o usuário a continuar a usar os processadores de textos com os quais ele já está habituado.

• Corretor textual, que indica, no texto, problemas relacionados à leiturabilidade e correção gramatical (parte importante também da revisão):

Finalmente, essa foi a ideia escolhida. Ela se assemelha muito aos corretores de estilo, como o Grammarly e o Hemingway app que vimos na parte 1 deste estudo de caso, mas o diferencial é que ainda não existem muitas soluções desse tipo para o português.

O objetivo é mostrar os valores e a interpretação das métricas quantitativas (para o usuário identificar rapidamente o status do texto como um todo, além de poder identificar metas e limites), e indicar no texto os principais pontos de revisão.

Sobre as Métricas

Indicadores Gerais

Uma vez que foi estabelecido que a solução a ser desenvolvida seria um programa que mediria elementos quantitativos do texto, chegou a hora de determinar que elementos seriam esses, e como eles seriam medidos (viabilidade tecnológica).

Para isso, analisou-se a listagem das métricas disponíveis como APIs no Coh-Metrix-Port, comparando-as com os pontos levantados nas pesquisas. No fim, foram escolhidos 4 parâmetros, são eles: Leiturabilidade, Vocabulário, Quantidade de Informação e Ortografia e Gramática

Leiturabilidade: Medida com o índice Flesch Brasileiro. Na métrica, os valores variam de 0 a 100 e quanto maior, menor é a complexidade do texto (inversamente proporcional).

Vocabulário: Medido com a métrica cw_freq. Essa métrica mede a média da quantidade de vezes que as palavras de conteúdo de um texto aparecem no Banco de Português (BP).

O Banco do Português é um corpus eletrônico que contava inicialmente com 230 milhões de palavras de textos em português (SARDINHA, 2007). Quanto maior o valor da métrica, mais vezes as palavras do texto analisado aparecem nesse corpus, logo mais comum, utilizada e conhecida ela deve ser, e menor a complexidade do texto (inversamente proporcional).

Essa métrica foi escolhida baseada nas recomendações do Para um Manual de Jornalismo Online, que prega pela simplicidade e clareza da linguagem utilizada nesse tipo de texto, e também pelo fato da adequação do vocabulário ter sido apontada como um dos principais fatores para se verificar o nível de dificuldade de leitura, tanto pelos responsáveis pela revisão das notícias do site de agência de notícias do IBGE, quanto por outros profissionais na primeira pesquisa em questionário.

Quantidade de informações: Medida com a métrica cw_words, que mede a porcentagem da ocorrência de palavras de conteúdo em um texto. São consideradas palavras de conteúdo os substantivos, adjetivos, verbos, advérbios e palavras denotativas. Nesse caso os valores variam de 0 a 1, quanto maior o valor, maior a complexidade do texto (diretamente proporcional).

Quantidade de informações: Medida com a métrica cw_words, que mede a porcentagem da ocorrência de palavras de conteúdo em um texto. São consideradas palavras de conteúdo os substantivos, adjetivos, verbos, advérbios e palavras denotativas. Nesse caso os valores variam de 0 a 1, quanto maior o valor, maior a complexidade do texto (diretamente proporcional).

Essa métrica mede o quão informativo um texto é, e foi escolhida baseada nas recomendações do Para um Manual de Jornalismo Online e depoimentos dos editores da Agência de Notícias do IBGE, que chamam a atenção para a necessidade dos textos conterem todas as informações importantes, mas ao mesmo tempo serem objetivos e irem direto ao ponto.

Ortografia e Gramática: O Coh-Metrix-Port não oferece uma métrica que analisa a ocorrência de erros gramaticais e ortográficos, seria necessário analisar as APIs disponíveis para isso em outras plataformas. Por vezes, algumas delas oferecem sugestões de correções para esses tipos de erros e dicionários de sinônimos, recursos que poderiam ser incorporados no programa do projeto também.

Para analisar esse índice, então, a métrica utilizada seria a quantidade de erros gramaticais e ortográficos pelo total de palavras do texto. Nesse caso, a relação entre o valor numérico e a dificuldade de leitura é diretamente proporcional.

A inclusão de um revisor de problemas ortográficos e gramaticais foi definida considerando que essa é uma das partes mais importantes da revisão de um texto, e já é bem comum a inclusão de recursos automáticos desse tipo de revisão em processadores de texto, como no Word.

Embora todas as métricas da Coh-Metrix representem uma dimensão linguística e cognitiva relevantes para se investigar o processo de leitura, é importante lembrar que limitar a quantidade de dados apresentados faz parte da proposta do projeto de apresentar informações de forma simples e de fácil compreensão: com dados de mais de 20 métricas, o usuário ficaria facilmente sobrecarregado.

Marcações

As marcações destacam no texto palavras, frases e/ou parágrafos que mais interferem para aumentar o grau de dificuldade dos indicadores gerais. Elas são divididas em grupos pelos mesmos indicadores, e inicialmente estavam agrupadas dessa maneira:

Leiturabilidade:

• Parágrafos longos (com 400 caracteres)
• Frases longas (com 25 palavras ou mais)
• Palavras longas (com 6 sílabas ou mais)
• Título longo (com mais de 80 caracteres)

Quantidade de informação:

• Parágrafos densos (Parágrafos com índice cw_words 0,6 ou maior)

Vocabulário:

• Vocabulário incomum (palavras com índice cw_freq menor que 10000)

Ortografia e Gramática:

• Principais erros de ortografia e gramática, conforme indicados pela API a ser escolhida.

Os valores foram estabelecidos a partir de referências encontradas na internet, ou então pela observação da forma de textos jornalísticos e textos do portal de notícias do IBGE. De qualquer maneira, esses valores foram importantes para serem usados como critério no protótipo, mas ainda precisam ser melhor estudados.

Wireframes

Após elaboradas as definições projetuais, começaram a ser desenvolvidos wireframes. Wireframes são esboços ou rascunhos das telas do aplicativo usados para organizar seus elementos e a arquitetura da informação (EDITORIAL AELA.IO, 2019).

“Os wireframes, possuem dois objetivos principais:

• Auxiliar o UX Designer na diagramação e aplicação da identidade visual;

• Alinhar a expectativa do cliente quanto ao que o usuário quer e ao projeto criado.” (EDITORIAL AELA.IO, 2019).

Seguem abaixo as imagens produzidas. Mantive o mesmo modelo de três colunas do Grammarly que pareceu funcionar bem Da esquerda para direita: o espaço do texto, no meio explicações sobre as marcações e na direita estão os gráficos e os resultados das métricas. Vale lembrar que a categoria de ortografia e gramática só foi incluída depois.

Geralmente os wireframes não utilizam cores, mas nesse caso seu uso pareceu necessário para demonstrar a ideia de marcações pertencentes a categorias diferentes. A notícia utilizada no exemplo foi retirada do site da Agência de Notícias do IBGE (2021).

Sobre a organização da informação das interfaces, ela se baseou em outros softwares similares de processamento de texto. Como vimos na primeira parte, o público do projeto está acostumado a usar softwares de processamento de texto, como o Microsoft Word, então, seguindo o princípio da familiaridade e padrões de interface, colocar as ferramentas em posições parecidas e utilizar ícones semelhantes poderiam ajudar a facilitar o uso e o entendimento da interface para novos usuários.

Além disso, outra preocupação era colocar todas as informações numa mesma página, aceitando no máximo modais, em casos especiais. A importância disso era para que o usuário pudesse comparar as informações de forma rápida e com facilidade, tendo uma visão geral dos dados das métricas e do texto.

Os wireframes foram utilizados no desenvolvimento do projeto como uma forma de começar a esboçar as ideias para as interfaces do programa e expô-las para representantes do público-alvo, no caso dois jornalistas do IBGE, de maneira a mostrar, com imagens, a solução proposta e coletar feedbacks. A ideia de mostrar para eles uma versão de baixa resolução, com aparência de rascunho, teve o intuito de deixá-los mais à vontade para criticar e propor mudanças.

Ambos os jornalistas pareceram entender bem a função do software e gostaram bastante, no entanto, esses foram alguns comentários que eles fizeram:

• Muitas informações:

Um dos jornalistas comentou que, assim que ele abriu as primeiras telas ele se sentiu bombardeado de informações. No entanto, o outro falou que isso não era problema, porque outros softwares de processamento de texto que eles usam também são assim, então eles já estão acostumados.

Além disso, apesar de terem comentado da quantidade de informações, ambos conseguiram interpretar as informações e entender o que estava acontecendo na tela muito bem. Um começou analisando a coluna da direita, com os gráficos, já o outro foi primeiro para a coluna com o texto. Apesar dessa diferença, ela não pareceu muito significativa em relação a cumprir a tarefa de analisar um texto com métricas quantitativas, então o ideal pareceu ser justamente deixar o usuário ter a liberdade de começar o processo por onde achasse melhor.

• Dúvidas sobre como os indicadores são medidos:

Eles tiveram dúvidas sobre como os indicadores eram medidos. Nesse ponto eles ainda não tinham visto a tela que mostra onde ficaria o texto com essas explicações. Depois de mostrá-las para eles, eles acharam que era uma solução razoável, o que só reforça a importância desse recurso e dele estar bem-sinalizadas

Um nota interessante sobre essa tela é que ela usa um modal de uma forma diferente da original. Fessenden (2017) diz que a função original dos diálogos modais era alertar as pessoas para casos que precisassem da ação imediata do usuário, como consertar erros. Nesse sentido, os modals são muito úteis para chamar a atenção do usuário. Alguns dos problemas que esse recurso pode trazer em outros contextos é interromper o fluxo de trabalho, bloquear ou tampar o restante do conteúdo, etc.

O interessante é que, para o usuário acessar essas informações sobre o que os indicadores avaliam em outros programas que já existem, como o Hemingway App e o Grammarly, se faz necessário abrir e acessar outras páginas com as informações detalhadas. Os problemas mencionados de não conseguir visualizar o conteúdo e interromper o fluxo de trabalho, na verdade, são muito maiores quando se abre uma nova janela do que ao usar um modal.

No facileitor, esses modals, na verdade, são uma forma de criar um ambiente de concentração para a leitura de informações um pouco mais complexas. Porém, ao mesmo tempo, eles permitem uma visualização parcial da área de trabalho para o usuário não perder totalmente a noção do que ele estava fazendo e facilitar para que ele estabeleça a relação entre o conteúdo do texto que está lendo com os recursos e funcionalidades do programa.

• Dificuldade de interpretação dos gráficos e marcações:

Voltando aos wireframes, um dos jornalistas comentou que teve um pouco de dificuldade de avaliar que gráficos estavam mostrando um resultado positivo ou não. Segundo ele, os gráficos deveriam ser todos preenchidos da esquerda para direita, sendo à esquerda melhor, mais fácil e à direita pior, mais difícil, o que estaria mais de acordo com o formato de um velocímetro do primeiro gráfico.

Outra questão importante, é que, em algumas das métricas escolhidas, resultados mais baixos indicavam uma leitura melhor e mais fácil, enquanto em outras eram o contrário: resultados mais baixos indicam uma leitura mais difícil. Por isso, também foi necessário fazer adaptações e inverter valores para unificar esse comportamento.

Continuando sobre os pontos que os jornalistas levantaram sobre os wireframes, eles também ficaram confusos sobre quais os reais valores que estavam sendo apresentados nos gráficos, justamente por eles não apresentarem números. Minha teoria era a de que somente a proporção do preenchimento da barra lhes daria uma noção dos valores, e que isso só já seria suficiente, mas eles expressaram vontade de ter mais detalhes e precisão na exposição dos resultados.

Além disso, eles tiveram dificuldade de relacionar as marcações coloridas no texto com as categorias Leiturabilidade, Ortografia e Distribuição do Conteúdo (nome antigo de quantidade de informação). Isso provavelmente ocorreu porque essa distinção é indicada pelas cores e há muita informação cromática acontecendo ao mesmo tempo, porque eu tinha decidido incluir tons vermelhos e alaranjados também para expressar a intensidade dos valores das métricas, isto é, o quanto elas estão atrapalhando a leitura.

Obviamente usar dois sistemas cromáticos ao mesmo tempo não estava dando certo, então eu resolvi manter a distinção das categorias por cor, e repensar como eu poderia fazer para indicar intensidade nos gráficos de outra forma.

Outra dificuldade que eles tiveram também foi perceber que os cards da coluna do meio (com as explicações sobre os problemas apontados no texto) estavam relacionados com as marcações. Eles indicaram que isso era provavelmente porque eles estavam longe do campo do texto, tanto no sentido horizontal (porque elas estão coladas na coluna dos gráficos, e não do texto), quanto vertical (porque elas estão todas no topo da página, mesmo se uma delas tenha ocorrido mais abaixo no texto)

Esses foram então os principais comentários, cheguei a redesenhar alguns wireframes para atender algumas das questões que eles mencionaram, enquanto outras eu deixei para explorar melhor quando estivesse desenvolvendo a interface final.

A Interface e seus Componentes

O Conceito Gráfico para as interfaces foi baseado nas características da situação e tipo de texto com o qual o programa vai trabalhar. Moran (2016) sugere pensar no tom de voz do texto em algumas dimensões de polos opostos, entre eles: sério/engraçado; formal/casual.

A partir das pesquisas decidi que o conceito da interface deveria pender para os polos sério e casual. Sério por causa do conteúdo das notícias e por ser pensado para o ambiente de trabalho. Casual no sentido de que, nas notícias da Agência do IBGE, se busca substituir a formalidade da estrutura de um relatório técnico ou de um release para priorizar uma linguagem mais próxima e acessível ao público.

Em termos gráficos, o quesito de seriedade foi traduzido com uma paleta de cores neutras com tons de cinza azulados para as funções gerais do programa e uma família tipográfica neutra sem-serifa. O uso de elementos neutros na interface de trabalho também tem a função de não desviar a atenção do usuário para que ele mantenha o foco no seu trabalho e no texto.

Para diminuir a formalidade, se decidiu arredondar levemente os cantos dos retângulos e optou-se por uma paleta de cores de tons vivos e pastéis para as marcações, medidores e os índices. O uso das cores vivas também é importante para chamar a atenção do usuário para esses elementos. Já a opção por tons claros e pouco saturados, facilita a leitura no caso das marcações, uma vez que elas ainda permitem níveis adequados de contraste entre o texto e o fundo.

Sobre essa paleta de cores ainda, é importante destacar que elas são duplas de cores opostas. Essa característica ajuda não só a trazer harmonia visual, mas também a facilitar a diferenciação dos indicadores

Outra característica que contribui para o conceito de casualidade é o alinhamento das marcações em relação aos textos, que não é perfeito, mas cada uma é levemente deslocada seguindo um padrão. O alinhamento das marcações foi pensado de forma a ajudar o usuário a visualizar que aquela área tem mais de um tipo de marcação, no caso de superposições.

É importante lembrar que o exemplo da Imagem é um caso extremo com todas as marcações se sobrepondo e esse dificilmente será um cenário comum.

As marcações são retângulos com bordas arredondadas e certo nível de transparência. A transparência é importante pois há situações em que uma marcação pode sobrepor a outra (por exemplo, uma frase longa com palavras difíceis). Por isso, a ordem de sobreposição sempre é: roxo (Quantidade de Informação), azul (Leiturabilidade), laranja (Ortografia e Gramática) e amarelo (Vocabulário). Organizou-se dessa forma pois as marcações de Quantidade de Informação e Leiturabilidade são as que cobrem uma área maior contínua de texto (até um parágrafo inteiro), por isso seria melhor que elas ficassem no fundo.

Além disso, as cores de cada índice foram pensadas de forma que as mais claras (amarelo, laranja) ficassem por cima e não fossem obscurecidas pelas cores mais escuras. No entanto, quando o usuário seleciona para visualizar a explicação de uma marcação específica, ela fica por cima de todas as outras, independentemente de sua cor e categoria.

Mesmo que o programa do projeto tenha sido pensado para ser usado em desktop e não se atenha a detalhes como sua configuração em tamanhos de telas pequenas, como tablets e celulares, ainda assim, há uma grande variação entre os tamanhos e resoluções de telas. Para o projeto, trabalhou-se com a variação de tamanho de 1024 x 640 a 1920 x 1080, porque esses são os valores máximos e mínimos para telas grandes citados pela Microsoft Brasil (2020). Mesmo assim ainda existem computadores com telas maiores, de 5120 x 2880, por exemplo.

Ao pensar em como os elementos são escalados de acordo com as dimensões da tela, é importante ressaltar que alguns devem mudar de tamanho para se adequarem à nova área disponível, e outros não. De acordo com WATHAN e SCHROGER no livro Refactoring UI (2018), às vezes faz mais sentido deixar alguns elementos fixos e ter mais espaço para expandir o conteúdo principal. Por isso é necessário pensar no tamanho máximo que cada componente se expande.

“Espalhar as coisas ou torná-las desnecessariamente largas torna a interface mais difícil de interpretar, enquanto um pouco de espaço extra nas bordas não faz mal a ninguém.” (WATHAN e SCHROGER, 2018).

O uso de 12 colunas e a referência de tamanho de 1040px como valor máximo para expansão do conteúdo foi definida a partir das recomendações de comportamento de grid das guidelines de Material Design.

Nome e Logo

Fácil + Leitor = Facileitor

Fácil e leitor são palavras-chave quando se fala sobre leiturabilidade e as funções do programa, que buscam facilitar a leitura, pensando no público que vai ler o texto (o leitor).

Para o logotipo, foram testadas várias opções, primeiro em preto e branco, e depois com cores. Era importante que o logotipo transmitisse a ideia do programa e sua funcionalidade. No final, a solução escolhida destaca a palavra “leitor”, imitando o recurso de marcação do programa.

Gráficos

Para os gráficos, eu escolhi dar destaque ao índice de leiturabilidade, visto que ele é o tema do projeto e resume bem a questão “o texto está fácil o suficiente para ser lido pelo meu público?”. Por isso, seu formato é maior e com formato diferente: um velocímetro.

“O gráfico de velocímetro é um bom recurso para ser utilizado no a fim de demonstrar uma ideia de progressão.” (NUNES 2019).

Para os outros gráficos, a princípio tentou-se usar o modelo de barra utilizado tanto pelo Grammarly quanto pelo Hemingway App, como exemplos de programas similares que deram certo. Mais tarde decidiu-se utilizar barras curvas de forma a se assemelharem em formato com o velocímetro e criarem uma unidade gráfica entre todos os gráficos.

Os gráficos são divididos em 4 áreas, os valores determinados pelas tabelas abaixo. Em cada índice essas áreas recebem nomes diferentes, como foi estabelecido nas tabelas, na sessão Wireframes, desse estudo de caso. De forma geral, vão todas do nível de leitura mais fácil para o mais difícil. A divisão do medidor em mais de duas partes é importante para evitar a polarização da avaliação do texto entre fácil e difícil, e expor a questão em forma de espectro de facilidade/dificuldade.

A ideia original era usar tons de vermelho e laranja nos gráficos para chamar a atenção do usuário para as métricas que estivessem mostrando valores mais altos. No entanto, como vimos nos wireframes, o uso de dois sistemas de cores não funcionava muito bem, então eu resolvi fazer várias versões experimentando outras variações por cor, mas também outros elementos gráficos.

Baseado no livro Graphic Design the New Basics de Ellen Lupton e Jennifer Cole Phillps (2009). Os elementos escolhidos foram a cor (mais quente quanto maior a dificuldade), o contraste (maior saturação quanto maior a dificuldade) e o tamanho (maior quanto maior a dificuldade).

Depois de inserir as diferentes versões nas interfaces, optou-se por seguir com os que apresentavam somente a variação de tamanho. O motivo foi o fato deles cumprirem bem sua função, além de que os outros, por apresentarem variações tonalidade, deixavam a interface mais caótica e aumentavam a sensação inicial que um dos jornalistas tinha mencionado, de se sentir bombardeado de várias informações ao mesmo tempo.

Teste de Usabilidade

Ao final, para testar se as informações e as funções do programa estavam claras foi feito um protótipo interativo e, com ele, um teste de usabilidade.

Para entender melhor como funciona o protótipo assista o vídeo de demonstração ou acesse o link: https://xd.adobe.com/view/7225afb5-d079-4a90-8f56-786f051f060c-2776/?fullscreen&hints=off

O teste de usabilidade foi realizado individualmente com 5 jornalistas do IBGE via chamada de vídeo com compartilhamento de tela.

“Jakob Nielsen defendeu certa vez que com apenas 5 usuários na amostra seria possível identificar 80% (ou mais) dos problemas críticos de uma interface.” (NIELSEN AGNER, 2018).

Algumas das tarefas que eu pedi para eles realizarem foram:

• Inserir um texto no programa (o texto foi enviado em um documento separado para eles)
• Interpretar os gráficos: dizer que cada um deles está avaliando e como eles chegaram nesses resultados
• Desativar as marcações no texto (todas de uma vez, individualmente e por categoria)
• Guardar o arquivo

Para inserir o texto no programa, o jornalista poderia copiá-lo e colá-lo na área de texto, ou clicar na opção “abrir” no canto superior e selecionar o documento. No entanto, todos os participantes foram pelo caminho de copiar e colar.

Para interpretar os gráficos, eles não abriram a janela com as explicações. Na verdade, dois deles nem encontraram essa opção, o que mostra que ela deveria estar melhor sinalizada, com algum ícone que indicasse que aquela área tinha alguma interação, talvez. Mas de maneira geral, eles interpretaram bem o significado dos gráficos só pelo nome dos indicadores e demais textos na coluna.

Sobre o texto, a única reclamação foi o termo “palavras-chave”. Eles interpretam palavras-chaves como as palavras mais importantes do texto, que indicam seu conteúdo, e não as palavras que mais se repetem no texto, como os algoritmos do Google fazem. Portanto, depois eu alterei “Palavras-chaves” para “Palavras que mais usadas”.

Além disso, outro problema com as explicações foi que alguns dos jornalistas não perceberam que elas eram roláveis, então depois eu fiz alterações na altura da caixa (deixando um espaço mais confortável para a leitura) e tomei cuidado para posicionar as últimas linhas do texto cortadas ou muito próximas da margem, de modo a indicar que há mais conteúdo embaixo

Agora, quando requisitados a esconderem as marcações, todos conseguiram encontrar o botão correto (o símbolo do olhinho) na primeira ou segunda tentativa. Os que conseguiram na segunda tentativa clicaram primeiro em cima do texto “ocultar marcações”, e alguns reclamaram também do tamanho da área de clique. Para resolver essa questão, então, eu aumentei a área de clique fiz ela se expandir para cima do texto também (não está mais limitada só ao símbolo do olho).

Depois, quando eles foram ocultar cada marcação individualmente, eu percebi que os cards se deslocava horizontalmente no estado hover, e isso acabava prejudicando os jornalistas na hora de clicar no símbolo de ocultar, pois eles miravam o mouse no lugar do botão, e quando iam clicar ele tinha se movido de lugar. Tive que, então, mudar as animações dos estados hover, para uma que não deslocasse os cards.

Outro fator que dificultou a visualização foi a sobreposição de marcações azuis. Para diminuir esse problema, foi necessário repensar as categorias pertencentes a cada tipo de marcação de modo a evitar ao máximo a sobreposição de marcações da mesma cor.

A nova configuração ficou assim:

Leiturabilidade:

• Frases longas (com 25 palavras ou mais)
• Título longo (com mais de 80 caracteres)

Quantidade de informação:

• Parágrafos densos (Parágrafos com índice cw_words 0,6 ou maior)
• Parágrafos longos (com 400 caracteres)

Vocabulário:

• Palavras difíceis (palavras com 6 sílabas ou mais e com índice cw_freq menor que 10000)

Com esse novo sistema, diminuirão as situações de superposição de marcações de mesma cor. Restam ainda as circunstâncias de erros ortográficos dentro de frases com erros gramaticais (superposição laranja/laranja) e parágrafos longos e densos (roxo/roxo). Esse último caso, porém, não deverá ser tão problemático, pois independente das circunstâncias, as marcações roxas sempre ocupam um parágrafo inteiro, é muito diferente da situação anterior em que era necessário identificar uma frase ou palavra azul dentro de uma área azul maior.

Cabe-se também refletir mais sobre a inclusão da métrica cw_words no programa, que mede a concentração de informação no texto, levando em consideração a proporção de palavras de conteúdo. Sobre esse índice, pelo menos 2 jornalistas comentaram que textos jornalísticos têm mesmo muitas informações e isso não é um problema, é parte do estilo desse tipo de texto. Uma sugestão foi substituir essa métrica por uma outra que meça somente a proporção de adjetivos e advérbios, pois esses sim devem ser evitados em textos jornalísticos. No entanto, essa mudança ainda não foi aplicada.

Finalmente sobre a tarefa de guardar o documento, todos foram na opção de salvar ou salvar como, no canto superior da tela. Nenhum deles pensou na possibilidade de copiar o texto todo e jogar de volta no Word e salvar lá, apesar de isso também poder ser feito.

Além disso, um jornalista disse que achou o tamanho do título e o espaço entre ele e o resto do texto muito grandes, e outro disse que achou o tamanho da fonte pequeno, medidas que também foram revistas.

Apesar desses pontos, a resposta dos jornalistas foi muito positiva. Quatro dos cinco jornalistas confirmaram que essa ferramenta poderia ajudar eles no seu trabalho. O outro criticou a quantidade de tempo que o uso da ferramenta demandaria devido a quantidade excessiva de marcações, o que pode ter ocorrido na minha tentativa de tentar encaixar todas as variantes de marcações em um texto pequeno.

Para corrigir esse problema, como ele propôs, se poderia rever os limites estabelecidos para os valores das marcações ou permitir que o usuário possa regular o grau de rigor com que elas são feitas, de forma similar ao Grammarly. De acordo com o jornalista, essa função é importante de ser incluída em versões futuras, quando se pensar em expandir o uso da ferramenta para outros públicos e tipos de texto.

Ainda sobre o uso da ferramenta no trabalho, Dois dos participantes foram mais específicos e disseram que a usariam assim que recebessem ou finalizassem o texto, de forma a identificar logo de partida os principais problemas e depois partiriam para uma revisão mais detalhada qualitativa. Um usuário já falou o contrário, que faria primeiro uma revisão qualitativa e só ao final recorreria a essa ferramenta só depois para verificar se ele não deixou escapar nenhum problema.

E foi assim que as telas ficaram com as alterações depois do teste de usabilidade:

É importante lembrar, no entanto, ainda é que elas ainda precisam ser testadas novamente para garantir que as soluções propostas realmente resolveram os problemas de usabilidade encontrados.

Facileitor: Estudo de Caso parte 1

Facileitor é um projeto de UX/UI design que eu desenvolvi no último ano da faculdade (2020/2021) e é sobre programa de desktop que utiliza métricas quantitativas para complementar o processo de avaliação e adaptação do nível de leiturabilidade de textos em português brasileiro.

Sumário (parte 1):

• Introdução
• Desk-Research
• Fórmulas de Leiturabilidade
• Formulários e Pesquisa Quantitativa
• Público-alvo, Entrevistas e Pesquisa Qualitativa
• Análise Sincrônica
• UX Canvas
• Conclusão da parte 1

Introdução

A ideia para o projeto surgiu a partir da minha curiosidade sobre a forma que as pessoas leem e percebem a leitura. Mais especificamente, eu estava intrigada por como eu tinha tanta facilidade para ler alguns livros, enquanto outros podiam me demandar horas e horas para conseguir terminar de ler uma página. Então, a fim de encontrar uma oportunidade de projeto, eu recorri a ferramentas de pesquisa para investigar até que ponto esse fenômeno abrangia outras pessoas, quais características o influenciavam e como profissionais de texto lidam com isso atualmente.

Este relato foi dividido em duas partes: A primeira (essa aqui) trata das pesquisas iniciais; o processo de discovery e análise de outras soluções similares no mercado. Na segunda abordarei as questões do processo de geração de ideias, criação e testes.

Desk-Research

O objetivo dessa primeira pesquisa era juntar bibliografia e entender o que já foi descoberto dentro do campo da psicolinguística sobre a forma como lemos e quais podem ser os principais aspectos que caracterizam o nível de dificuldade de um texto. Essa etapa foi importante também para elaborar perguntas para profissionais da área, em entrevistas posteriores.

Foi com essa pesquisa que eu encontrei o conceito de leiturabilidade, que trata justamente da questão que eu queria abordar:

Leiturabilidade pode ser definida como “a facilidade com que um texto pode ser entendido ou compreendido” (TINKER; MILES, 1963 apud TILLMAN; HAGBER., 2014)

Embora o meu objetivo fosse abordar a questão dentro do contexto brasileiro com textos em português (BR), a maior parte dos estudos dessa área exploram esse assunto baseados na língua inglesa. Inclusive, a principal referência que eu usei sobre leiturabilidade foi um manual da Common Core State Standarts, que estabelece parâmetros para avaliar a leiturabilidade baseado nos anos escolares americanos. Para tal, sua recomendação é usar fórmulas de leiturabilidade, e posteriormente verificar o resultado com uma análise qualitativa.

Fórmulas de Leiturabilidade

As fórmulas de leiturabilidade avaliam características quantitativas do texto, tais como quantidades de palavras, frases e sílabas (ou caracteres), considerando que palavras e frases mais longas cansam e dificultam a leitura.

As fórmulas de leiturabilidade vem sendo desenvolvidas desde a década de 1920 e hoje são usadas principalmente com o auxílio de computadores. São uma maneira rápida de se analisar um texto e estabelecer metas com resultados tangíveis.

248,835 [-1,015 (palavras/frases) — 84,6 (sílabas/palavras) — 21,43] (Exemplo de fórmula adaptado para o português)

Alguns estudos interessantes sobre o assunto:

• Nos anos 1940 foram publicados vários estudos nos EUA mostrando como pequenas mudanças nos níveis de leiturabilidade poderiam aumentar a leitura de artigos de jornais de alta-circulação. Por exemplo, Donald Murphy (1947) descobriu um aumento de 45% na leitura de um artigo sobre nylon quando se reduziu o nível de leiturabilidade de 9 anos de estudo para 6.
• Em 2007 Stefan Martins e Lucia Filgueiras fizeram uma análise de textos retirados de sites de governo eletrônico brasileiros com fórmulas de leiturabilidade. Eles descobriram que a maioria do conteúdo dessa amostra estavam escritos de forma muito mais complexa do que o esperado para o nível médio de escolaridade brasileira.

• Em 2010 foi lançado o Coh-Metrix-Port que foi uma iniciativa de adaptar para o português, diversas métricas relacionadas à leiturabilidade. Mais de 20 dessas métricas são de livre acesso e estão disponíveis como APIs. Isso resolveu o problema de ter de utilizar parâmetros que talvez não fossem apropriados para o contexto brasileiro.

Formulários e Pesquisa Quantitativa

Como é comum em projetos de baixo orçamento, o entendimento do público leitor e da forma como eles leem se deu apenas por meio de fontes secundárias. Porém, me esforcei para entrar em contato com pelo menos alguns professores, revisores, jornalistas e pessoas que trabalham com texto em geral.

Num primeiro contato, formulei um questionário com perguntas abertas (dissertativas) e fechadas (múltipla escolha, com respostas prontas), que foi repassado em redes sociais. Depois de alguns dias, o documento foi respondido por 30 pessoas que trabalham com leitura, revisão, produção textual (ou similares) no Brasil.

Nessa etapa esperava-se colher respostas o suficiente para reconhecer segmentos mais específicos do público; definir um público-alvo inicial; e descobrir como as pessoas da amostra avaliam ou trabalham com a questão da leiturabilidade (mesmo no caso daqueles que nunca ouviram falar no termo). As respostas foram analisadas à mão ou então com o auxílio de ferramentas do Google Forms.

Respondendo essas perguntas, os resultados da pesquisa indicaram que, no Brasil a análise da leiturabilidade está, sobretudo, restrita a uma análise qualitativa, e os fatores avaliados podem variar dependendo da propensão de quem a faz (considerando que mesmo “vocabulário”, o fator mais mencionado, estava presente em menos de 15% das respostas). Além disso, os usos e vantagens das aplicações das fórmulas de leiturabilidade e análises quantitativas podem ser mais explorados no contexto brasileiro.

Público-alvo, Entrevistas e Pesquisa Qualitativa

O público-alvo não estava totalmente claro no início do projeto, pois, como visto na pesquisa quantitativa, uma grande variedade de pessoas e profissões poderia se beneficiar da solução. No entanto, no contexto de um mínimo produto viável, preferiu-se investigar mais a fundo uma situação específica como ponto de partida, para depois, em desdobramentos futuros, expandir as possibilidades e situações de uso.

O cenário escolhido foi a redação de notícias de sites de instituições públicas, com foco no estudo do caso da Agência de Notícias do IBGE (Instituto Brasileiro de Geografia e Estatística), de onde foi possível contatar alguns jornalistas. No início do projeto conseguiu-se estabelecer contato com dois jornalistas da Agência, e, ao final do projeto, foi possível realizar os testes de usabilidade com outros três, um total de cinco pessoas.

Além da facilidade de contato com os servidores da Agência de Notícias do IBGE, a escolha desse cenário se deu principalmente pelo fato deles buscarem se comunicar com uma audiência grande diversos níveis de escolaridade, situação na qual os princípios de leiturabilidade são de grande relevância (KLARE, 1963). Além disso, garantir o acesso e a compreensão desse tipo de texto, que trazem dados e explanam a situação atual do país, é muito importante numa sociedade democrática.

Nas primeiras entrevistas com os jornalistas do IBGE, o objetivo era confirmar (ou negar) a importância da leiturabilidade nesse contexto, entender como eles trabalham com ela, e tomar conhecimento de características gerais do público e do fluxo de trabalho na Agência.

Abaixo seguem algumas das principais características que eu aprendi sobre o público-alvo e seu contexto:

O objetivo da Agência de Notícias do IBGE é otimizar a comunicação e divulgação dos resultados das pesquisas desenvolvidas pelo Instituto. Estes são considerados dados sensíveis e têm data e horário para serem postados, de forma que ninguém receba informação privilegiada e todos tenham acesso ao conteúdo ao mesmo tempo.

No site da Agência são publicados notícias e releases. Os dois buscam simplificar a linguagem do laudo técnico, e costumam ser produzidos ao mesmo tempo. A diferença é que os releases se destinam à comunicação com a imprensa, contendo todas as informações importantes, em ordem de relevância, mas ainda podem manter algumas expressões e linguagem técnica do laudo. Já as notícias se destinam a população brasileira em geral. Nelas há maior preocupação em humanizar os dados e adaptar a linguagem de forma a serem mais bem compreendidas por qualquer pessoa. Diferente dos releases, as notícias tentam abordar somente um ou mais aspectos relevantes dos resultados da pesquisa.

Algumas pesquisas são divulgadas todos os meses, como taxa de desemprego e inflação, enquanto outras têm um intervalo de tempo maior. Mesmo assim, segundo os jornalistas entrevistados, o prazo para produção, revisão e publicação dos releases e notícias em ambos os casos costuma ser confortável.

Antes de redigidos os releases e as notícias, a equipe de editores e jornalistas se reúnem com os técnicos que desenvolveram a pesquisa (estatísticos, geólogos, pesquisadores etc.) para discutirem os resultados obtidos e como divulgá-los. Depois disso, dividem-se as tarefas na equipe: redação de release, notícia(s) e produção de gráficos, tabelas e imagens.

Após redigidos, as notícias e releases são revisados pelos editores que verificam se os dados e a estrutura do texto estão corretos; linguagem e o vocabulário adequados; gramática e questões de português; e se todas as informações presentes são pertinentes ao assunto. Depois os técnicos também verificam se os dados foram expressos de maneira correta.

No caso de edições, elas podem ser realizadas pelos próprios editores ou discutida com os jornalistas. Quando aprovado, as publicações são colocadas no sistema poucos minutos antes da hora de publicação, onde todos da equipe podem acessá-la e fazer alterações, e depois são colocadas no site.

Além disso, pode-se dizer que a relevância da leiturabilidade nesse contexto foi confirmada, já que foi constatada a preocupação dos jornalistas entrevistados com a adequação da linguagem e tornar as informações acessíveis para um público diverso, principalmente no caso das notícias.

Análise Sincrônica

Na Análise Sincrônica, buscou-se analisar programas de computador voltados para a escrita e análise de textos, e que levassem em consideração elementos quantitativos. Esse tipo de pesquisa foi importante para conhecer que tipo de ferramentas e abordagens existem dentro do tema proposto. Os programas analisados foram: Microsoft Word; Hemingway App; Grammarly e Language Tool.

O Microsoft Word é um software de processamento de texto, usado para manipular um documento de texto. O usuário insere o texto por meio da digitação, e o programa fornece ferramentas para copiar, colar, deletar, formatar, entre outras.

Já o Hemingway App, o Grammarly e o Language Tool são corretores de estilo com opções de formatação limitadas, mas que destaca algumas palavras e frases no texto inserido pelo usuário, que podem estar dificultando a leitura do texto. Essas marcações são feitas com cores diferentes, de acordo com as diferentes categorias e critérios de marcação, que podem ser advérbios em excesso, frases muito compridas, entre outros. Esses softwares também podem apresentar sugestões de melhoria do texto e mostrar uma média do nível de leiturabilidade do texto. É importante lembrar que, dentre esses três programas, somente o Language Tool está disponível para a textos em português.

UX Canvas

A partir de todas essas informações, foi elaborada uma visualização no modelo de UX Canvas para mapear os diversos aspectos que influenciam na experiência do usuário e necessidades do projeto:

Conclusão da parte 1

E assim concluímos a etapa das pesquisas iniciais. Na segunda parte desse artigo abordarei as etapas de criação e testes de usabilidade: detalhes da interface, rascunhos iniciais, protótipos, etc. Também vou explicar sobre como se deu a definição do artefato, e o preenchimento de outros campos do UX Canvas.

Diferente da maior parte dos projetos do mercado, não havia uma restrição quanto ao tipo de solução que deveria ser desenvolvida, eu tive a liberdade de explorar vários caminhos levando em consideração as características do contexto proposto. Na verdade, no início minha intenção era apresentar uma proposta de representação visual, sem trabalhar com interfaces digitais. Isso só veio a ser depois de estudar mais sobre o assunto e o contexto, e reconhecer que a capacidade do computador de promover interação e disponibilizar um feedback instantâneo seria importante para que a solução tivesse uma função prática e pudesse ser incorporada no dia-a-dia dos usuários.

Porém, mesmo entre as interfaces há várias formas de você expor as informações, propor uma interação ou até uma experiência e é sobre isso que eu vou falo no início da continuação deste artigo. Uma versão mais resumida também pode ser encontrada na minha página do behance.

Clique aqui para ir para a parte 2!

Facileitor