Evitando más práticas no design iOS e Android

Quantas pessoas comuns você já viu usando dispositivos iOS e Android ao mesmo tempo ? Os números oficiais de acordo com este estudo variam entre 10% e 20%, mas o número também inclui usuários de Mac, não apenas usuários de dispositivos móveis. Na prática, as pessoas tendem a usar apenas um telefone ou tablet em um determinado período de tempo. Se eles estiverem usando dois dispositivos, na maioria das vezes, ambos estarão executando o mesmo sistema operacional.

O que isso significa é que não há necessidade de fazer cópias perfeitas em pixels do design da interface do usuário de um aplicativo, tentando acomodar as duas plataformas, completas com dezenas de tamanhos de tela, proporções e resoluções diferentes (não vamos nem exibir entalhes, barras de status , barras de navegação, botões de hardware, etc.).

Pelo contrário, mesmo que um usuário esteja olhando para o mesmo aplicativo no iOS e no Android, é provável que ele prefira experimentar a sensação nativa em ambos. É por isso que a abordagem adotada por muitos gerentes de projeto e proprietários de produtos no desenvolvimento móvel geralmente não é a ideal e precisa ser ajustada.

Por que isso ainda é um problema?

Mas por que as partes interessadas e os gerentes ainda tomam decisões que frequentemente degradam a experiência do usuário, prejudicando seus próprios produtos? Era compreensível no início da década, quando todos ainda estavam se familiarizando com o desenvolvimento para iOS e Android, mas esse problema irritante persiste até hoje.

A principal razão para essa situação pode ser a preocupação expressa por gerentes de projeto e desenvolvedores móveis de que seus usuários possam ficar confusos se virem o mesmo aplicativo em outra plataforma e perceberem que ele não fornece exatamente a mesma sensação e interface do usuário. É justo dizer que, até certo ponto, essa linha de pensamento faz sentido, pois algum grau de semelhança é necessário e bem-vindo. No entanto, ir longe demais e, em casos extremos, fazer clones exatos de aplicativos para diferentes plataformas, na verdade, tende a fazer muito mais mal do que bem.

O objetivo final deve ser encontrar o equilíbrio certo — não force a consistência perfeita de pixels, mas mantenha as ideias de design comuns e mantenha o mapa de navegação do seu aplicativo semelhante para ambas as plataformas; forneça os mesmos recursos e o mesmo fluxo de trabalho, mas tente manter o comportamento nativo sempre que possível.

Todo mundo adora um botão personalizado ou uma animação sofisticada aqui e ali, mas os elementos nativos são o que as pessoas estão acostumadas e acham mais fácil e intuitivo de usar.

Foco nos usuários, não na aparência

Para encontrar uma boa abordagem para resolver esse dilema, devemos começar do final da linha – o usuário final. Pesquisas nos dizem que os usuários de Android e iPhone são pessoas muito diferentes e, se estamos visando o UX ideal, devemos tentar entrar em seus padrões de uso.

A partir do orçamento médio que as pessoas decidem gastar em tecnologia por mês ( iPhone: $ 100,88, Android: $ 50,83 ) , passando pelo número de selfies que fazem por dia iPhone: 12, Android: 7 e chegando aos textos que enviam todos os dias iPhone : 57, Android: 26 , é fácil perceber que as diferenças são substanciais, a ponto de podermos concluir que existe uma divergência de comportamento, que determina a forma como as pessoas usam seus dispositivos.

Então, em que devemos nos concentrar ao projetar aplicativos para ambas as plataformas ao mesmo tempo?

Primeiro de tudo, vá para elementos nativos sempre que possível. Mesmo se você estiver usando uma estrutura de plataforma cruzada, a maioria dos componentes é baseada em visualizações nativas puras; então, a menos que você realmente precise de algo personalizado, atenha-se ao básico. As pessoas gostam de usar o que estão acostumadas e você economizará algum tempo de desenvolvimento para recursos mais importantes (e revisões de código!).

As visualizações personalizadas podem definitivamente trazer personalidade e exclusividade ao seu aplicativo, desde que mantenham as mesmas ideias gerais e sensação de uso como as genéricas - muito pouco e seu aplicativo é chato, muito e é desnecessariamente chamativo e difícil de usar.

Às vezes, mesmo um pequeno toque com uma visualização personalizada um pouco diferente pode ser um divisor de águas para o seu aplicativo, mas se você preencher todas as telas com novos elementos para os usuários explorarem, eles podem ficar sobrecarregados e se perder enquanto procuram informações importantes. Não é por acaso que esses pequenos toques são chamados de “polimento!”

Como abordar diferentes componentes de design

Como regra geral, lembre-se sempre de que cada plataforma tem suas próprias diretrizes de design. O conjunto de abordagens do Android está pisando no Material Design, enquanto a Apple confia no Human Interface Design. Entrando nos componentes específicos que devemos considerar ao planejar nosso projeto, há várias partes principais para focar:

1. Estilo geral: a menos que estejamos falando de um aplicativo multiplataforma, devemos considerar seguir as diretrizes gerais de estilo para cada plataforma. No geral, os designs do iOS tendem a ser mais planos, enquanto o Android opta por uma abordagem mais em camadas.

   Historicamente falando, as plataformas móveis vêm se influenciando há uma década ou mais, e você pode identificar facilmente alguns conceitos do Android no iOS e vice-versa. Por exemplo, quando os sensores de impressão digital começaram a aparecer no mundo móvel, os fabricantes estavam ( e ainda estão ) experimentando o tamanho e a localização do sensor, tentando torná-lo confortável para o maior número possível de usuários. Ao mesmo tempo, designers e desenvolvedores também estavam se adaptando ao novo recurso, então, no final, os elementos visuais e o feedback são praticamente idênticos em ambas as plataformas (exceto algumas abordagens exóticas).

2. Especificações de hardware e padrões de navegação: este é provavelmente um dos exemplos mais marcantes dos pontos negativos da clonagem total do seu aplicativo. A maioria dos dispositivos Android ainda tem o conforto de uma barra de navegação adicional (seja hardware ou software em dispositivos diferentes), incluindo um botão Voltar. Como o iOS não oferece isso, os aplicativos precisam considerar onde e quando fornecer o botão Voltar, geralmente no canto superior esquerdo de cada tela.

   O botão de menu (o botão quadrado neste exemplo) também pode fornecer funcionalidades adicionais para aplicativos Android. Onde isso é relevante? Por exemplo, ao abrir o menu de configurações ou um recurso de navegação semelhante.

   

   Até recentemente, os iPhones também apresentavam o tradicional botão Home da Apple, mas desde a introdução do iPhone X, ele foi deixado de lado e o fluxo no iOS agora é baseado em gestos. Se deslizar é uma parte importante do seu aplicativo, certifique-se de dar espaço suficiente entre a borda do contêiner do aplicativo e a área de passagem que você permite para evitar coincidências complicadas.

   Caso seu aplicativo dependa de funcionalidades específicas de hardware, como Bluetooth, NFC ou fones de ouvido com fio, você deve sempre considerar a variedade de especificações de hardware diferentes às quais oferece suporte. Tente fornecer feedback adequado ao usuário quando ele tentar interagir com um recurso específico. Se por algum motivo você precisar fornecer um recurso específico de hardware para apenas uma das duas plataformas, certifique-se de informar seus usuários sobre a diferença.

3. Elementos globais (barras de status, cabeçalhos, etc.): componentes que aparecem em todas as páginas do seu design, como a barra de status, o cabeçalho de navegação e assim por diante, devem ter como objetivo estritamente fornecer um sentimento nativo, portanto, não devemos alterar a altura e o estilo dessas barras. Existem pequenas diferenças na forma como os elementos globais são estilizados em ambas as plataformas. Por exemplo, o Android usa texto alinhado à esquerda enquanto o iOS usa um título centralizado. A barra de status é um componente nativo, portanto, você não precisa se preocupar com isso, mas lembre-se de diferentes entalhes e proporções de tela ao planejar a seção superior do seu aplicativo.

   

   

4. Navegação: as boas e velhas diretrizes do Material Design do Google sugerem a navegação no menu da gaveta em aplicativos Android, com a navegação inferior ficando para trás, mas ainda sendo uma opção viável. O iOS tende a usar apenas uma barra de guias, o que pode limitar suas opções de navegação de nível superior, mas fornece uma visão clara de todas elas de uma só vez. Nesse caso, ambos os sistemas operacionais fornecem componentes semelhantes que podem ser usados ​​dependendo da complexidade do seu aplicativo, mas a diferença visual nos dois sistemas deve direcioná-lo naturalmente, por exemplo, a barra de navegação global no Android e sua falta no iOS.

   A rápida evolução do hardware móvel nos últimos anos introduziu muitas variáveis ​​e incógnitas: telefones de tela inteira, entalhes de diferentes formas e tamanhos, aumento do uso de gestos para navegação em todo o dispositivo e assim por diante. Todas essas mudanças fornecem poder sem precedentes para o usuário, mas podem ser uma dor quando estamos tentando descobrir todos os casos de uso de uma determinada tela em nosso aplicativo. Dadas essas preocupações, uma boa abordagem para evitar confusão para nossos usuários seria manter os padrões de navegação simples e consistentes, sem sobrecarregar o aplicativo com muitos gestos, barras e opções de deslizamento em várias direções.

   

5. Tipografia: ambas as plataformas têm seus tipos de letra padrão — San Francisco para iOS e Roboto para Android. A menos que você esteja optando por uma fonte personalizada, que combine perfeitamente com o estilo geral do seu aplicativo, você deve seguir os padrões. Lembre-se de que os usuários podem alterar a fonte padrão do sistema e isso não afetará as visualizações que você personalizou com um tipo de letra específico.

   Por exemplo, os usuários disléxicos podem não ter o melhor tempo em seu aplicativo se tiverem substituído a fonte padrão por uma fonte que atenda especificamente às suas necessidades. Se você estiver dando suporte a usuários que possam estar usando fontes não latinas (como cirílico, árabe etc.), certifique-se de que suas fontes personalizadas também estejam fornecendo esses caracteres extras. Se você gosta de jogos, provavelmente já viu aquelas tabelas de classificação com pontuações altas alcançadas por jogadores russos cujos nomes se destacam por sua fonte diferente. Este é apenas um pequeno erro cometido durante a fase de desenvolvimento, não um "recurso" para jogadores específicos e, embora provavelmente não faça com que os usuários abandonem seu aplicativo, pode definitivamente resultar em uma experiência do usuário degradada ou resultar em reclamações ou críticas ruins.

   

6. Outros componentes: botões, transições de tela, animações, microinterações, folhas de ação, alertas e todos os outros tipos de controles de fluxo estão além do escopo deste artigo, mas devem seguir o princípio geral que aplicamos a outros elementos de design até agora— ambas as plataformas desencorajam elementos personalizados excessivos, pois podem distrair e confundir o usuário; quando se trata de design, a primeira impressão é geralmente a última para muitos usuários e é por isso que é tão importante atrair a atenção dos usuários desde o início e fazê-los se sentir em casa, por assim dizer.

No mundo real, você pode ver algumas exceções muito populares às regras que discutimos – aplicativos iOS que seguem as diretrizes do Material Design e alguns produtos Android que seguem as diretrizes da Interface Humana da Apple, mas esses aplicativos têm seu próprio estilo comprovado. Os usuários estão familiarizados com os aplicativos e seu design e, para eles, faz sentido fornecer uma sensação um pouco mais personalizada.

Abordagem multiplataforma bem feita

Por outro lado, se o seu projeto for baseado em uma solução multiplataforma (como React Native, Flutter, Xamarin, etc.), você deve considerar qual seria a plataforma principal na qual deseja se concentrar e começar a partir daí.

Nos últimos anos, essas novas estruturas forneceram grandes melhorias de produtividade no desenvolvimento de aplicativos multiplataforma. Mais e mais empresas estão mudando para esse paradigma de desenvolvimento, pois ele fornece um tempo de lançamento mais curto, melhor custo-benefício e menos barreiras técnicas, com as principais desvantagens sendo o suporte limitado a recursos e UX abaixo do ideal em alguns casos.

Embora praticamente todas as soluções antigas para desenvolvimento multiplataforma fossem baseadas em visualizações da Web e, portanto, apresentassem sérios problemas com capacidade de resposta em muitos dispositivos, hoje em dia podemos usar componentes nativos mesmo em abordagens multiplataforma. Essa grande melhoria afetou o mercado de várias maneiras e aproximou todas as plataformas móveis de unificar a experiência visual do usuário em vários dispositivos e plataformas.

Se você decidir optar por uma solução multiplataforma, poderá começar como em um aplicativo nativo padrão, criando o esqueleto do seu aplicativo. Depois de ter suas principais prioridades em execução (configurar dependências de base, construir um MVP, atingir marcos específicos do projeto, lançar sua primeira versão, etc.), você pode facilmente separar seus projetos principais para os dois aplicativos, usando a plataforma- ferramentas específicas que cada framework oferece. Dependendo do tamanho da sua equipe e do prazo disponível, você pode até considerar incluir esses ajustes na versão 1, apenas para evitar futuras confusões quando as coisas não parecerem mais as mesmas em uma determinada versão da plataforma.

Depois de tudo dito e feito, você deve avaliar quais desses princípios serão válidos para seu aplicativo. Como em quase qualquer empreendimento em nosso setor, você deve tentar seguir as diretrizes, ajustando-as levemente para atender às suas necessidades específicas. Por exemplo, se a navegação na gaveta é o que realmente faz sentido para seu aplicativo simples de cinco telas, você não precisa criar soluções complicadas para cada plataforma. Torne óbvio e fácil para o usuário reconhecer seus botões e ferramentas personalizados, sejam eles componentes-chave ou apenas pequenas personalizações.

Um bom design respeita os hábitos do usuário

Para resumir, podemos repetir algo que já sabemos – bom design é o design que respeita os hábitos dos usuários em cada sistema operacional. Apenas um pouco de polimento no final pode fazer a diferença entre um aplicativo médio e um ótimo.

Muitas vezes, seu aplicativo não fornecerá recursos exclusivos suficientes para conquistar os usuários apenas com o conteúdo. A maioria das pessoas descreverá sua decisão de escolher um produto em detrimento de outro com “um pressentimento”. Essa categoria de usuários baseia suas escolhas principalmente em como se sentem ao usar o aplicativo, avaliando implicitamente a capacidade de resposta, a escolha geral de estilo, a paleta de cores e os componentes visuais individuais que veem na tela.

Portanto, tente garantir que seu produto se destaque não apenas por suas incríveis características, mas com embalagens de alta qualidade para combinar com a qualidade dos serviços que presta.