Air Lookout é o projeto paralelo que mudou meu processo de design para sempre

Em fevereiro de 2015, comecei a trabalhar em um aplicativo iOS chamado Air Lookout . O objetivo do aplicativo era simplificar e remover qualquer ofuscação de informações sobre a qualidade do ar. Após mais de um ano de trabalho noturno e fins de semana, o lucro líquido total desde o lançamento em 2016 foi inferior a US$ 1.000. Mesmo com esses números, eu reviveria cada hora de trabalho.

A única coisa em que não posso colocar um valor monetário é como a experiência de criar o Air Lookout mudou completamente minha mente sobre o processo de design e desenvolvimento de todos os projetos em que trabalhei desde então.

Uma breve nota sobre a qualidade do ar

A qualidade do ar em todo o mundo é um problema sério. Não importa se você mora em uma metrópole cheia de carros e ônibus expelindo gases de escape ou em uma pequena cidade onde as árvores superam as pessoas. A qualidade do ar afetará sua vida. Vivendo em Salt Lake City, experimentamos uma inversão no inverno. Uma inversão é uma camada de ar quente que retém o ar frio, incluindo quaisquer poluentes aéreos produzidos. Isso cria uma camada de smog no vale de Salt Lake. Essas inversões às vezes podem durar dias ou semanas e, dependendo do clima, podem mudar todos os dias.

Antes de lançar o aplicativo finalizado, mostrado acima, eu tinha um milhão de perguntas que precisava entender antes mesmo de começar a construir um design baseado em soluções e uma quantidade mínima de suposições.

A tarefa geral de criar um aplicativo de qualidade do ar era assustadora. No entanto, quando eu o dividi em pedaços menores, não parecia tão horrível. Na verdade, o primeiro passo: criar um design rápido que pudesse me ajudar a entender a organização das informações, parecia bastante simples. Eu havia executado esse processo inicial centenas de vezes antes para muitos clientes diferentes. Todo projeto começa com um wireframe de quadro branco, e o designer trabalha para criar um design inicial a partir disso. Pelo menos, era o que meus hábitos me diziam.

O número de suposições que fiz no wireframe acima e nos designs iniciais que provei que estavam errados durante todo o processo é surpreendente.

Finja até você (literalmente) conseguir

Carreguei os poucos designs estáticos que fiz - depois de criar meu esboço de wireframe - para o InVision. Com isso, eu poderia abrir o aplicativo falso ao longo do meu dia. Qual foi a sensação de usar o aplicativo enquanto esperava o jantar para cozinhar? Enquanto eu estava entrando no meu carro? Muito rapidamente percebi que havia muitas perguntas recorrentes que eu tinha. O que as cores significam novamente? Laranja é pior que amarelo, certo? Mas o Índice de Qualidade do Ar (AQI) vai de 0 a 500. Por quê? E, sobretudo, as perguntas que sempre tive foram: Como isso afeta o meu dia? Posso me exercitar ao ar livre?

Com base em muitas das perguntas recorrentes que eu tinha sobre poluentes e como eles poderiam afetar meu dia, comecei a adicionar telas falsas no Invision que poderiam funcionar como “folhas de dicas”. O que começou como uma simples definição de poluente, apenas para me ajudar a me lembrar enquanto projetava e desenvolvia o aplicativo, acabou sendo adicionado ao aplicativo como um recurso final. Agora, no aplicativo atual, tocar no nome de um poluente levará o usuário a uma definição com uma lista de fontes de informação e links para mais informações (esse fluxo é mostrado abaixo nas capturas de tela do aplicativo atual). Descobri que, às vezes , informações úteis para o designer ou desenvolvedor também são úteis para o usuário .

Naturalmente, como mostrado no esboço de wireframe anterior, eu gravitei em direção a uma interface do usuário para adicionar e gerenciar locais por meio de CEP. Mas, depois de usar o protótipo falso, achei esse processo árduo. Por que se preocupar em fazer o usuário passar por todo esse fluxo? E se eu dirigisse até Park City para um dia de esqui? Ou Antelope Island para corrida em trilha? Salt Lake City, estação de qualidade do ar, não seria mais a mais próxima.

Diariamente, descobri que só me importava com a qualidade do ar na minha localização atual, não necessariamente na minha casa . E, felizmente para mim, os iPhones vêm com uma API de serviços de localização e GPS de nível de consumidor bastante bom. Portanto, removi todo o local de criação/leitura/atualização/exclusão da interface do usuário e fluxo do aplicativo. Decidi que uma visão geral da localização atual seria a mais rápida e útil para todos. Os únicos usuários que eu poderia imaginar que isso frustraria eram usuários avançados verificando vários locais. Mas um lembrete do meu objetivo original – simplificar a qualidade do ar – acrescentou confiança à minha decisão.

Para testar isso, fiz mais telas falsas para testar no InVision. Em vez de tocar em uma interface de usuário falsa e visualizar o fluxo, configurei o protótipo para passar pelas etapas automatizadas da atualização da minha localização GPS falsa com transições cronometradas. Então, quando eu ia a um café em North Salt Lake ou dirigia até Park City, eu abria meu aplicativo falso e o via atualizar e me mostrava novos dados para o local diferente.

A primeira vez que usei este novo protótipo, pude dizer que foi uma grande melhoria. Quando um dispositivo possui determinados recursos integrados, o uso desses recursos pode resultar em uma melhor experiência do usuário ao projetar menos uma interface . Teria sido difícil chegar a essa conclusão se nunca saísse do Photoshop e não imaginasse que tinha um aplicativo real de qualidade do ar no meu telefone.

Começando com código

Em muitos projetos de clientes, recomendei e supervisionei testes de usuários. Para o Air Lookout , isso não era uma opção. Eu já sabia que haveria uma pequena quantidade de lucro e os testes com usuários certamente estavam fora do meu orçamento. Eu também sabia que teria usuários e feedback assim que lançasse o aplicativo. Qualquer coisa que eu pudesse fazer para simplificar o aplicativo aceleraria isso. Na minha opinião, eu preferiria lançar um aplicativo mais simples e bem feito e obter feedback do usuário em vez de ficar muito tempo trabalhando em um aplicativo muito complicado com as suposições erradas.

Meus hábitos me diziam que o próximo passo depois de usar o protótipo InVision deveria ser a iteração do design. Este teria sido o processo para qualquer projeto de cliente desta natureza. No entanto, eu tinha muitas perguntas sobre a qualidade dos dados e preocupações se eu era capaz de obter os dados de maneira confiável no meu iPhone usando o UIKit. Em vez de retornar ao Photoshop, abri o Xcode.

Para realizar minha funcionalidade desejada, criei um aplicativo iOS de visualização muito simples (e principalmente quebrado) que exibiria dados reais . Inicialmente, o aplicativo nem atualizava sozinho. Eu tive que matar manualmente o aplicativo e reabri-lo se quisesse novos dados. Mas, pelo menos, tinha dados atualizados e relevantes (incluindo minha localização!).

… e de volta ao design

Houve muitas decisões de design que tomei no código enquanto fazia esse protótipo bruto que acabou ficando. O mais notável é o grande bloco de cores mostrando a cor AQI e o texto de localização grande. Eu nunca tinha trabalhado de uma forma em que o processo de desenvolvimento informasse um design visual como este. Mas não tenho certeza se teria descoberto isso enquanto trabalhava em uma ferramenta de design tradicional, como o Photoshop ou o Sketch. Afinal, só mudei a cor de fundo porque estava com preguiça de criar outro UIView para representar a cor AQI.

A partir daqui, foi fácil trazer uma captura de tela para o Photoshop e refiná-la ainda mais. Era muito mais rápido brincar com o espaçamento e os tamanhos de texto no Photoshop em vez de esperar que o aplicativo recompilasse após cada alteração (especialmente considerando que isso foi nos dias do Swift 2).

O processo de iteração de design para muitas das visualizações subsequentes acabou seguindo um padrão muito semelhante a esse. Eu criaria um protótipo de trabalho bruto – fazendo improvisações rápidas de design no código – o usaria por alguns dias ou semanas e depois recriaria e modificaria a visualização no Photoshop. Como eu já usei um protótipo antes de qualquer projeto estático, eu era um especialista no que a visão precisava ou não e onde deveriam estar as prioridades e a hierarquia.

Uma das maiores surpresas para mim, desse processo, foi ter que construir um protótipo funcional que exibisse os dados e as leituras corretamente. Acabei entendendo os dados antes mesmo de começar a fase de design estático. Como designer, como eu poderia começar a agir como um especialista em explicar as complexidades da qualidade do ar se eu mesmo não entendo completamente como isso funciona. Criar e usar esses protótipos brutos me deu essa experiência e conhecimento em um curto período de tempo.

…Para todo sempre

Muitas noites, eu ia e voltava entre o Photoshop e o Xcode várias vezes. Eventualmente, parecia confortável usar qualquer ferramenta que parecesse mais rápida para qualquer problema que eu estivesse trabalhando para resolver. Às vezes era código e às vezes era uma ferramenta de design tradicional como o Photoshop. Curiosamente, o Photoshop nem sempre foi a ferramenta mais rápida para encontrar soluções de design visual, especialmente se lidasse com dados dinâmicos.

Postmortem

Depois de lançar o Air Lookout , é difícil dizer se minhas decisões estavam certas. Recebi alguns e-mails de usuários reclamando que a maneira tradicional de pesquisar e adicionar locais está ausente. Estou, no entanto, feliz por ter optado por essa abordagem mais simples. A pesquisa de localização é sempre um recurso que posso adicionar ao aplicativo posteriormente, se houver solicitação de feedback suficiente do usuário. Sinto-me confiante de que minha conclusão – extraída do uso regular de meu protótipo falso – foi a decisão certa.

Da mesma forma, houve muitas decisões de design que acabei tomando no código que acabou no aplicativo final. Sem os blocos de cores (e muitas outras decisões como essa), há uma boa chance de que meu aplicativo se pareça com todos os outros aplicativos de qualidade do ar disponíveis.

Se eu fosse fazer esse processo novamente, valeria a pena construir um protótipo de wireframe interativo com componentes UIKit de estoque. Essencialmente, pulando o protótipo do InVision e começando com um protótipo de código. A partir daí, seria muito mais fácil iniciar o design estático sabendo onde os componentes do UIKit valem a pena ou não têm brilho e ter uma compreensão abrangente dos dados e dos relacionamentos de dados com os quais preciso trabalhar. Então, em vez de usar um protótipo falso do InVision, eu poderia ter uma experiência de aplicativo mais realista com dados reais mais cedo.

Realidade e aplicação

No passado, especialmente quando eu trabalhava em uma agência, eu teria recomendado a exploração e a iteração completas do design antes de desperdiçar o tempo já limitado de um desenvolvedor com a construção de algo baseado em suposições iniciais (especialmente qualquer coisa que provavelmente precisaria ser alterada ou melhorada posteriormente ). No entanto, agora, estou mais intrigado com a possibilidade de designers e desenvolvedores trabalharem juntos para criar um protótipo de aplicativo de wireframe tocável feito com componentes nativos para testar e validar quaisquer suposições ou ideias iniciais.

Talvez uma equipe possa ser formada por indivíduos capazes de projetar e desenvolver para facilitar essa parte do processo (e remover ainda mais a barreira semântica entre as duas funções). Estou confiante de que este é um processo mais eficiente para design e desenvolvimento que dará aos fundamentos de design de qualquer projeto interativo uma base muito mais forte.

Agora, o desafio para mim é descobrir como vender aos clientes nesse processo não convencional.

Nota : O Air Lookout foi lançado em 2016 e pode ser baixado na App Store.