Audihero

Sobre o projeto

Audihero é um projeto criado durante o programa Apple Developer Academy (antigo BEPiD) no ano de 2015. A principal função do aplicativo é ler histórias em quadrinhos visuais como audiodescrições, utilizando dubladores para os personagens, efeitos sonoros e descrições de cenas, criando uma experiência imersiva para pessoas cegas ou com baixa visão e incluindo-os ao mundo das histórias em quadrinhos.

Metodologia

Challenge Based Learning (CBL)

métodos e Ferramentas

Desk Research, Questionários, Entrevistas, Pensamento Lateral, Brainstorm, Análise de Similares, Card Sorting, Wireframe, Paper Prototype, Mood Board.

Time

1 Designer (eu) e 3 iOS Developers

Minha Função

UX / UI Designer e Sound Editor

Desafios

"Criar um aplicativo inovador rentável"

"Como incluir pessoas cegas ao mundo dos quadrinhos?"

1. Guiding Questions

A metodologia CBL foca todo o processo na criação das Questions, tudo é uma pergunta que precisaremos responder depois. Portanto, o primeiro passo é perguntar-se tudo o que puder a respeito do assunto escolhido. Assim, categorizamos a primeira rodada de Guiding Questions com os seguintes tópicos:

Consumidores
Indústria de Quadrinhos
Escritores Independentes
Mercado de Quadrinhos

Para cada tópico, o time descobriu várias questões para as quais não sabia a resposta. Após anotar e categorizar tudo, passamos para os nossos processos de pesquisa.

2. Desk Research

Essa etapa foi bastante importante para descobrir o porquê das Histórias em Quadrinhos serem uma área interessante para se explorar, qual o valor que tinha para as pessoas e descobrir como a "Era dos Super-heróis" na televisão estava ajudando a vender histórias em quadrinhos ao redor do mundo.

Unica imagem do Freekpik (prometo)

3. Questionário

Foi criado um questionário no Google Forms para conseguir dados de potenciais consumidores no Brasil, com questões para entender o tipo geral de público que iríamos focar. O questionário foi publicado em grupos geeks do Facebook e aceitou respostas por apenas 2 dias.

Algumas questões que foram essenciais para nossa solução posterior foram:

Por que você gosta (ou não) dos quadrinhos?
Como os quadrinhos influenciam a sua vida?
Quais sãos os aspectos positivos e negativos dos quadrinhos para você?
O que você mudaria para tornar os quadrinhos melhores?

O questionário teve 180 respostas, o que para mim, como um estudante, foi bastante surpreendentes. Nos posts em que eu havia compartilhado tive alguns feedbacks muito positivos como o de que o questionário "parecia uma conversa simples".

1. Análise do Questionário

Eu classifiquei e separei todas as respostas subjetivas em diferentes quadros para ter uma ideia geral sobre qual o tipo de público alvo nós tínhamos. Os principais destaques que consideramos para o questionário foram:

O gênero f/m do publico foi bastante balanceado (58% masculino e 42% feminino)
Dentro desse grupo, as pessoas preferem mangás a quadrinhos.
As histórias geralmente os ensinam algum problema social do qual não tinham conhecimento.
Embora fossem inspiradoras para os leitores, algumas histórias eram impossíveis de se tornar reais.
Algumas pessoas gostariam de ver algum tipo de animação nos quadrinhos, pois acham difícil de imaginar o movimento entre os quadros;
Algumas pessoas gostariam de adicionar som para uma experiência imersiva.

Após ter os quadros sintetizados, nosso time conversou sobre o que víamos com as respostas, o que o público desejava e onde estava a lacuna no mercado que gostaríamos de preencher com alguma solução inovadora. Tivemos ideias como:

Netflix para Quadrinhos
Audiocomics (que já existia)
App para criação de quadrinhos

Então eu tive um insight, relacionado a algo que eu já havia feito anteriormente, a minha "bagagem".
‍
‍Por que não fazer com que os Quadrinhos sejam acessíveis para pessoas cegas?
‍
‍Alguns meses antes eu havia estudado sobre acessibilidade e a ideia simplesmente surgiu. Audiodescrições são bem diferentes de Audiolivros. Cada cena precisa ser detalhada, cada ação entre os quadros já é difícil para uma pessoa regular imaginar, seria mais difícil ainda descrever para uma pessoa não-visual. Tínhamos novas perguntas, muitas questões, um bocado delas. Por conta disso, fizemos uma segunda rodada de Guiding Questions.

2. Mais Questions

A segunda rodada foi um pouco mais difícil pois eu precisava encontrar pessoas que fossem cegas e geeks, para conhecer melhor o seu estilo de vida, preferências, dificuldades e assim em diante.

Felizmente, a Universidade local (UFAM) tinha uma pessoa perfeita: um homem por volta dos seus 30 anos, que era desenvolvedor de software e também um fã de super-heróis.

Eu separei as perguntas essenciais que eu tinha para ele, então minha equipe e eu fizemos um protótipo de papel com botões em relevo, e eu seria a pessoa que faria o leitor de tela do protótipo, com o objetivo de responder algumas perguntas bem rápido, já que o nosso prazo estava bastante apertado (não podíamos fazer uma segunda pesquisa, mas eu precisava muito) e deveríamos ter começado a desenvolver nossa Prova de Conceito no iOS. De qualquer forma, o protótipo foi "inútil", mas a entrevista que conseguimos fazer graças a isso trouxeram tantos insights que não precisaríamos de mais pesquisas.

Também adicionamos outros stakeholders para as guiding questions, como sonoplastas, músicos, dubladores, investidores e nós mesmos.

3. Protótipo / Prova de Conceito (PdC)

Após consultar uma estudante de audiodescrição, descobrimos uma forma de inserir a audiodescrição com a dublagem e os efeitos sonoros sem parecer muito estranho para o ouvinte. Então eu rapidamente fiz um sketch da PdC para que os desenvolvedores pudessem começar a mostrar algo para os patrocinadores do programa. Então eu aprendi como misturar alguns áudios usando o Adobe Audition e gravei minha própria voz lendo o que os quadros diziam. No final, para uma PdC estava bom.

1. Análise de Similares

O primeiro passo foi encontrar produtos similares ao que queríamos desenvolver. Encontramos muitas bibliotecas digitais de quadrinhos com apps (Comix, MangaReader, Comixology), mas nenhuma delas oferecia acessibilidade para cegos. Netflix foi um dos nossos principais exemplos de audiodescrição (após o problema que tiveram com Demolidor) e a Amazon tinha seus audiolivros.

2. Card Sorting

Fiz um card sorting com algumas pessoas com visão para verificar como elas estruturariam as informações de um app com catálogos. No geral, essas pessoas organizaram as informações da mesma forma que a Netflix organizava.

3. Wireframe

Após ter uma visão geral sobre a arquitetura de informação que iríamos adotar no app, comecei a esboçar um wireframe de baixa fidelidade. A navegação foi pensada para ser simples e direta, para que a pessoa cega pudesse navegar com facilidade através da tecnologia de Voice Over. Posteriormente, fiz alguns testes do wireframe utilizado o Marvel App, para corrigir alguns problemas e então fazer uma versão de alta fidelidade.

4. Naming e Logo

Escolher o nome e criar o logo tiveram seus próprios processos durante o desenvolvimento do app. Brainstorming, referências visuais e físicas, entre outros.
‍
Esse projeto teve vários nomes antes de Audihero: Audimix, Quadreams, Heromics. Algumas pessoas até perguntaram se a palavra Audi não poderia ser confundida com a marca de carro.
‍
No final, procurei criar o logo de maneira que pudesse ter uma versão tátil em alto-relevo, impressa em 3D para que nosso cliente pudesse solicitar uma versão da marca com seu herói (ou vilão) representada.
‍
O logo Audihero foi feita para ser sentida através do toque ou até mesmo do olfato.

1. UI Design

Eu entreguei as telas e os assets para os desenvolvedores com todas as informações que eles precisavam para fazer o mais próximo o possível do meu layout.

Para descobrir que cores eu poderia utilizar para o projeto criei um Mood Board com capas de quadrinhos de diferentes décadas. Então peguei as cores mais claras para o fundo com letras escuras pois há diferentes níveis de cegueira, e caso utilizasse um fundo escuro poderia tornar a leitura difícil para pessoas com baixa visão.

2. Telas do App

Recepção

Embora tivéssemos apenas duas histórias com audiodescrições, dublagem e efeitos sonoros, as pessoas que viram o projeto realmente gostaram de como foi apresentado.

Acreditamos que nosso primeiro desafio foi parcialmente alcançado, pois é um produto rentável, mas os custos para produzir conteúdo eram altos demais para continuarmos com ele.

A segunda parte do desafio, a inclusão de pessoas cegas ou de baixa visão, também foi parcialmente alcançado. Nós precisávamos testar mais algumas vezes para ter certeza, mas todos os elementos estavam funcionando corretamente, criando uma história audiodescritiva narrada, tal como especificado nos nossos objetivos iniciais.

Coisas que aprendi com o projeto

Multitasking é difícil, mas não impossível

O conceito inicial era bastante difícil de produzir, uma vez que eu também fui responsável por criar as trilhas de áudio, gravar vozes originais (de pessoas que sabiam tanto Inglês quanto Português), encontrar recursos sob a Creative Commons (efeitos e imagens), Quadrinhos em Creative Commons e organizar tudo isso junto para que os desenvolvedores pudessem focar na programação. Ao menos eu aprendi algumas coisas sobre como mixar faixas de áudio!

Comunicação Apropriada

A experiência de errar foi a única forma de eu aprender a transmitir uma ideia visual para uma pessoa cega. Na época eu não sabia, mas poderia estar muito mais preparado para uma entrevista com cegos (eu li muitos artigos sobre a experiência que os cegos têm sobre o mundo, e ainda assim não foram suficientes).

Em contrapartida, eu estava bastante preocupado que o meu questionário recebesse pouquíssimas respostas durante os 2 dias que eu precisava que ele fosse respondido. A boa notícia é que recebi muitas respostas para embasar as ideias.

Acessibilidade não é prioridade...

Essa é a parte mais triste que tive após o projeto. Eu descobri que muitos sites e aplicativos não se importam em serem acessíveis para pessoas cegas ou de baixa visão. Alguns anos após esse projeto tive a oportunidade de trabalhar como front-end developer e tentei fazer com que os leitores de tela lessem corretamente minhas aplicações, mas o que recebi do meu chefe foi um "não se preocupe com isso".

Saber programar é um grande diferencial

Eu tenho algum conhecimento em programação e desenvolvimento, então eu realmente sabia quando o meu time não conseguiria fazer alguma coisa que eu estava propondo na interface. Embora muitas das vezes eles me dissessem que "não há nada que não possa ser feito até que eu tente fazer".

A comunicação com o time também foi bastante fácil, pois eu conhecia muitos dos jargões que o pessoal utilizava quando estavam explicando a arquitetura que iriam usar, ou como iriam implementar alguma coisa. Assim eu sabia que, por exemplo, devido a uma resposta demorada do servidor eu precisaria adicionar um asset de carregamento, ou ainda se houvessem erros de resposta, eu poderia suavizar com alguma mensagem para o usuário.