Este ano, no FreshBooks, lançamos nosso primeiro aplicativo para iPhone. Nossa empresa existe há quase 10 anos e este é realmente nosso primeiro produto novo desde o lançamento de nosso aplicativo web de contabilidade em nuvem. Tratamos o desenvolvimento de nosso aplicativo para iPhone como uma tela em branco onde poderíamos aplicar alguns dos princípios de design mais recentes de nossa equipe.
Também queríamos reforçar as lições que aprendemos durante o desenvolvimento do nosso produto. Mas, em última análise, a criação do nosso aplicativo oficial para iPhone foi uma oportunidade para aprendermos e crescermos.
Errar é OK
Errar é inevitável ao projetar uma experiência de usuário complexa, como um aplicativo móvel.
Isso é especialmente verdade quando você nunca fez isso antes. Por mais lógicos que seus wireframes possam parecer, ou por mais bonitos que seus modelos possam parecer, alguns de seus designs vão falhar quando você os colocar na frente dos clientes. E, acredite ou não, isso é uma coisa muito, muito boa.
Quando projetamos o aplicativo FreshBooks para iPhone, adotamos o fracasso como parte de nosso processo de design. Abraçar o fracasso significa estas três coisas:
- Reconhecendo que nenhum design é sagrado, por mais grandioso que pareça no papel.
- Reconhecendo que nossos clientes, em última análise, definem o sucesso ou o fracasso de um projeto.
- Reagindo rapidamente quando algo não funciona e iterando até que nossos clientes nos digam que estamos certos.
O resultado líquido é um produto final muito superior e menos incerteza sobre como será recebido por nossos clientes. Então, sem mais delongas, aqui estão três coisas que erramos em nosso aplicativo para iPhone e o que fizemos para corrigi-las.
Tela inicial do iPhone
No início deste projeto, entrevistamos vários clientes FreshBooks existentes para descobrir como eles já usam o celular em suas vidas diárias, os problemas que enfrentam e o que gostariam de ver em uma experiência móvel do FreshBooks. As tendências e insights que observamos durante essas entrevistas, em última análise, informaram um conjunto de princípios de design. Aqui está um princípio de design que desenvolvemos a partir de nossas entrevistas:
Experiência do usuário centrada em tarefas A experiência do usuário móvel será otimizada em torno do conjunto discreto de tarefas de cobrança (rastreamento de tempo, tirar uma foto de recibo, criar uma fatura etc.) que serão mais comuns em contextos móveis.
Adiar cenários mais complicados (por exemplo, edição em massa, gerenciamento de permissões, personalização e configuração etc.) para o aplicativo da Web FreshBooks é aceitável para manter o foco e a simplicidade no aplicativo móvel.
Seguindo esse princípio, nosso primeiro design de tela inicial do iPhone para o aplicativo era composto por um conjunto de blocos que descrevem tarefas importantes no celular, como criar uma fatura, registrar uma despesa, acompanhar o tempo e assim por diante. Tocar em um desses blocos iniciou a tarefa correspondente. Essa abordagem nasceu da ideia de que a otimização em torno da criação rápida era essencial para uma pessoa em um contexto móvel (por exemplo, eles têm apenas 30 segundos no banco de trás de um táxi para registrar suas despesas).
Aqui está nosso design original da tela inicial:
Otimizado para criação rápida: tocar em “Nova fatura” na tela inicial leva o usuário à lista de faturas e cria uma nova fatura em branco. Esse esquema de navegação se desvia dos padrões de design típicos do iOS, bem como do nosso próprio aplicativo da web. Muitas vezes, a arquitetura de informação (IA) é baseada em cobranças (por exemplo, faturas, estimativas, despesas, etc.) em vez de suas tarefas/verbos associados (criar fatura, criar estimativa, registrar despesas, etc.). Abaixo estão exemplos típicos de organização de conteúdo com base em coleções.
Esquemas de navegação tradicionais baseados em coleções. Nosso pensamento era que, ao orientar a tela inicial do aplicativo em torno de tarefas em vez de coleções, significaria que é apenas um único toque para criar uma fatura, registrar o tempo, registrar uma despesa etc., tornando nosso aplicativo uma experiência fundamentalmente centrada em tarefas.
Como erramos
Nossos testadores beta universalmente acharam nossa orientação da tela inicial baseada em tarefas confusa. Ele se desviou muito de seus modelos mentais existentes estabelecidos por nosso aplicativo da web e muitos outros aplicativos para iPhone.
Aqui está um vídeo de teste de usabilidade que capturamos de uma pessoa com problemas para navegar em nosso design original de tela inicial baseado em tarefas:
Modelos mentais quebrados: os testadores beta lutaram com a orientação baseada em tarefas. Observar os testadores interagirem com o aplicativo também expôs uma falha em nosso princípio de design centrado em tarefas. As tarefas de cobrança discretas que identificamos como importantes para dispositivos móveis eram fundamentalmente sobre criação .
Deixamos de considerar a importância de outras categorias de tarefas, como:
- visualização: Verificação do status de fatura ou orçamento, visualização do histórico de um projeto, etc.
- atualização: faturar novamente uma despesa, enviar um rascunho de fatura etc.
Esses tipos de tarefas eram realmente mais comuns do que a criação – especialmente em dispositivos móveis, onde os usuários estavam mais interessados em revisar e editar do que em criar, mas nosso design não enfatizou sua importância.
A solução
A solução, neste caso, foi bastante simples. Adote o mesmo IA que nosso aplicativo web principal.
Em outras palavras, fique com o que funciona.
Fique com o que funciona. Uma arquitetura de informação tradicional é mais fácil de criar.