Evitar malas prácticas en el diseño de iOS y Android

¿Cuántas personas promedio ha visto usando dispositivos iOS y Android al mismo tiempo ? Las cifras oficiales según este estudio oscilan entre el 10 % y el 20 %, pero la cifra incluye también a los usuarios de Mac, no solo a los usuarios de dispositivos móviles. En la práctica, las personas tienden a usar solo un teléfono o tableta durante un período de tiempo determinado. Si están usando dos dispositivos, la mayoría de las veces, ambos ejecutarán el mismo sistema operativo.

Lo que esto significa es que no hay necesidad de hacer copias perfectas de píxeles del diseño de la interfaz de usuario de una aplicación, tratando de adaptarse a ambas plataformas, completas con decenas de tamaños de pantalla, relaciones de aspecto y resoluciones diferentes (ni siquiera mencionemos muescas, barras de estado , barras de navegación, botones de hardware, etc.).

Por el contrario, incluso si un usuario está mirando la misma aplicación tanto en iOS como en Android, es probable que prefiera experimentar la sensación nativa en ambos. Esta es la razón por la cual el enfoque adoptado por muchos gerentes de proyectos y propietarios de productos en el desarrollo móvil a menudo no es óptimo y debe ajustarse.

¿Por qué sigue siendo un problema?

Pero, ¿por qué las partes interesadas y los gerentes siguen tomando decisiones que degradan con frecuencia la experiencia del usuario y, por lo tanto, socavan sus propios productos? Era comprensible a principios de la década, cuando todo el mundo todavía se familiarizaba con el desarrollo de iOS y Android, pero este molesto problema persiste hasta el día de hoy.

La razón principal por la que se presenta esta situación podría ser la preocupación expresada por los gerentes de proyecto y los desarrolladores móviles de que sus usuarios podrían confundirse si ven la misma aplicación en otra plataforma y se dan cuenta de que no proporciona exactamente la misma sensación e interfaz de usuario. Es justo decir que, hasta cierto punto, esta línea de pensamiento tiene sentido, ya que cierto grado de similitud es necesario y bienvenido. Sin embargo, llevarlo demasiado lejos y, en casos extremos, hacer clones exactos de aplicaciones para diferentes plataformas en realidad tiende a hacer mucho más daño que bien.

El objetivo final debe ser lograr el equilibrio adecuado: no fuerce la consistencia de píxeles perfectos, sino que se ciña a ideas de diseño comunes y mantenga el mapa de navegación de su aplicación similar para ambas plataformas; proporcione las mismas características y el mismo flujo de trabajo, pero trate de mantener el comportamiento nativo siempre que sea posible.

A todo el mundo le encanta un botón personalizado o una animación elegante aquí y allá, pero los elementos nativos son a lo que la gente está acostumbrada y les resulta más fácil e intuitivo de usar.

Concéntrese en los usuarios, no en la apariencia

Para encontrar un buen enfoque para abordar este dilema, debemos comenzar desde el final de la línea: el usuario final. La investigación nos dice que los usuarios de Android y iPhone son personas muy diferentes y si nuestro objetivo es una experiencia de usuario óptima, debemos tratar de conocer sus patrones de uso.

A partir del presupuesto promedio que las personas deciden gastar en tecnología por mes ( iPhone: $ 100.88, Android: $ 50.83 ) , pasando por la cantidad de selfies que hacen por día iPhone: 12, Android: 7 y llegando a los mensajes de texto que envían todos los días iPhone : 57, Android: 26 , es fácil detectar que las diferencias son sustanciales, hasta el punto de que podemos concluir que existe una divergencia en el comportamiento, lo que determina la forma en que las personas usan sus dispositivos.

Entonces, ¿en qué debemos enfocarnos al diseñar aplicaciones para ambas plataformas al mismo tiempo?

En primer lugar, busque elementos nativos siempre que sea posible. Incluso si está utilizando un marco multiplataforma, la mayoría de los componentes se basan en vistas nativas puras; así que, a menos que realmente necesites algo personalizado, apégate a lo básico. A las personas les gusta usar aquello a lo que están acostumbrados y usted ahorrará algo de tiempo de desarrollo para funciones más importantes (¡y revisiones de código!).

Las vistas personalizadas definitivamente pueden aportar carácter y singularidad a su aplicación, siempre y cuando mantengan las mismas ideas generales y la misma sensación de uso que las genéricas: muy pocas y su aplicación es aburrida, demasiadas e innecesariamente llamativas y difíciles de usar.

A veces, incluso un pequeño toque con una vista personalizada ligeramente diferente puede cambiar las reglas del juego para su aplicación, pero si llena todas las pantallas con nuevos elementos para que los usuarios los exploren, es posible que se sientan abrumados y se pierdan mientras buscan información importante. No es coincidencia que estos pequeños toques se llamen "pulir".

Cómo abordar diferentes componentes de diseño

Como regla general, recuerde siempre que cada plataforma tiene sus propias pautas de diseño. El conjunto de enfoques de Android está pisando Material Design, mientras que Apple confía en Human Interface Design. Al entrar en los componentes específicos que debemos considerar al planificar nuestro diseño, hay varias partes principales en las que centrarnos:

1. Estilo general: a menos que estemos hablando de una aplicación multiplataforma, deberíamos considerar seguir las pautas generales de estilo para cada plataforma. En general, los diseños de iOS tienden a ser más planos, mientras que Android opta por un enfoque más estratificado.

   Históricamente hablando, las plataformas móviles se han influenciado entre sí durante una década o más, y puedes detectar fácilmente algunos conceptos de Android en iOS y viceversa. Por ejemplo, cuando los sensores de huellas dactilares comenzaron a aparecer en el mundo móvil, los fabricantes estaban ( y todavía están ) experimentando con el tamaño y la ubicación del sensor, tratando de hacerlo cómodo para la mayor cantidad de usuarios posible. Al mismo tiempo, los diseñadores y desarrolladores también se estaban adaptando a la nueva función, por lo que, al final, los elementos visuales y los comentarios son en su mayoría idénticos en ambas plataformas (salvo por algunos enfoques exóticos).

2. Detalles específicos del hardware y patrones de navegación: este es probablemente uno de los ejemplos más llamativos de los aspectos negativos de la clonación total de su aplicación. La mayoría de los dispositivos Android todavía tienen la comodidad de una barra de navegación adicional (ya sea hardware o software en diferentes dispositivos), incluido un botón de retroceso. Dado que iOS no proporciona eso, las aplicaciones deben considerar dónde y cuándo proporcionar el botón Atrás, generalmente en la esquina superior izquierda de cada pantalla.

   El botón de menú (el botón cuadrado en este ejemplo) también puede proporcionar una funcionalidad adicional para las aplicaciones de Android. ¿Dónde es esto relevante? Por ejemplo, al abrir el menú de configuración o una función de navegación similar.

   

   Hasta hace poco, los iPhones también presentaban el botón de inicio tradicional de Apple, pero desde la introducción del iPhone X, se ha dejado de lado y el flujo en iOS ahora se basa en gestos. Si deslizar es una parte importante de su aplicación, asegúrese de dejar suficiente espacio entre el borde del contenedor de la aplicación y el área de deslizamiento que permite para evitar coincidencias complicadas de deslizamiento.

   En caso de que su aplicación dependa de una funcionalidad específica de hardware, como Bluetooth, NFC o auriculares con cable, siempre debe considerar el rango de diferentes especificaciones de hardware que admite. Intente brindar comentarios adecuados al usuario cuando intente interactuar con una función específica. Si por alguna razón necesita proporcionar una función específica de hardware para solo una de las dos plataformas, asegúrese de informar a sus usuarios sobre la diferencia.

3. Elementos globales (barras de estado, encabezados, etc.): los componentes que aparecen en todas las páginas de su diseño, como la barra de estado, el encabezado de navegación, etc., deben tener como objetivo estricto brindar una sensación nativa, por lo que no debemos cambiar la altura y el estilo de esas barras. Existen pequeñas diferencias en el estilo de los elementos globales en ambas plataformas. Por ejemplo, Android usa texto alineado a la izquierda mientras que iOS busca un título centrado. La barra de estado es un componente nativo, por lo que no debe preocuparse por eso, pero tenga en cuenta las diferentes muescas y proporciones de pantalla cuando planifique la sección superior de su aplicación.

   

   

4. Navegación: las buenas y antiguas pautas de diseño de materiales de Google sugieren optar por la navegación del menú del cajón en las aplicaciones de Android, con la navegación inferior detrás, pero sigue siendo una opción viable. iOS tiende a optar únicamente por una barra de pestañas, lo que puede limitar las opciones de navegación de nivel superior, pero proporciona una vista clara de todas ellas a la vez. En este caso, ambos sistemas operativos brindan componentes similares que se pueden usar según la complejidad de su aplicación, pero la diferencia visual en los dos sistemas debería guiarlo naturalmente, por ejemplo, la barra de navegación global en Android y su falta en iOS.

   La rápida evolución del hardware móvil en los últimos años ha introducido muchas variables e incógnitas: teléfonos con pantalla completa, muescas de diferentes formas y tamaños, mayor uso de gestos para la navegación en todo el dispositivo, etc. Todos esos cambios brindan un poder sin precedentes al usuario, pero pueden ser una molestia cuando intentamos descubrir todos los casos de uso de una pantalla determinada en nuestra aplicación. Dadas estas preocupaciones, un buen enfoque para evitar confusiones para nuestros usuarios sería mantener los patrones de navegación simples y consistentes, sin sobrecargar la aplicación con demasiados gestos, barras y opciones de deslizamiento en varias direcciones.

   

5. Tipografía: ambas plataformas tienen sus tipos de letra predeterminados: San Francisco para iOS y Roboto para Android. A menos que busque una fuente personalizada, que coincida estrechamente con el estilo general de su aplicación, debe ceñirse a los valores predeterminados. Tenga en cuenta que los usuarios pueden cambiar su fuente de sistema predeterminada y esto no afectará las vistas que haya personalizado con un tipo de letra específico.

   Por ejemplo, es posible que los usuarios disléxicos no se diviertan mucho con su aplicación si han reemplazado la fuente predeterminada con una fuente que satisfaga específicamente sus necesidades. Si está apoyando a usuarios que podrían estar usando fuentes no latinas (como cirílico, árabe, etc.), asegúrese de que sus fuentes personalizadas también proporcionen esos caracteres adicionales. Si te gustan los juegos, probablemente hayas visto esas tablas de clasificación con puntajes altos logrados por jugadores rusos cuyos nombres se destacan debido a su fuente diferente. Este es solo un error menor cometido durante la fase de desarrollo, no una "característica" para jugadores específicos, y aunque probablemente no hará que los usuarios abandonen su aplicación, definitivamente puede resultar en una experiencia de usuario degradada o generar quejas o críticas negativas.

   

6. Otros componentes: botones, transiciones de pantalla, animaciones, microinteracciones, hojas de acción, alertas y todos los demás tipos de controles de flujo están más allá del alcance de este artículo, pero deben seguir el principio general que aplicamos a otros elementos de diseño hasta ahora: ambas plataformas desalientan los elementos personalizados excesivos, ya que pueden distraer y confundir al usuario; Cuando se trata de diseño, la primera impresión suele ser la última para muchos usuarios y por eso es tan importante llamar la atención de los usuarios desde el principio y hacerlos sentir como en casa, por así decirlo.

En el mundo real, puede ver algunas excepciones muy populares a las reglas que discutimos: aplicaciones de iOS que siguen las pautas de Material Design y algunos productos de Android que siguen las pautas de interfaz humana de Apple, pero esas aplicaciones tienen su propio estilo comprobado. Los usuarios están familiarizados con las aplicaciones y su diseño, y para ellos tiene sentido brindar una sensación un poco más personalizada.

Enfoque multiplataforma bien hecho

Por otro lado, si su proyecto se basa en una solución multiplataforma (como React Native, Flutter, Xamarin, etc.), debe considerar cuál sería la plataforma principal en la que desea enfocarse y comenzar desde allí.

En los últimos años, estos nuevos marcos han proporcionado mejoras masivas de productividad en el desarrollo de aplicaciones multiplataforma. Cada vez más empresas están cambiando a este paradigma de desarrollo, ya que proporciona un tiempo de comercialización más corto, una rentabilidad superior y menos barreras técnicas, con las desventajas clave siendo el soporte de funciones limitado y UX subóptimo en algunos casos.

Si bien prácticamente todas las soluciones anteriores para el desarrollo multiplataforma se basaban en vistas web y, por lo tanto, experimentaron serios problemas con la capacidad de respuesta en muchos dispositivos, hoy en día podemos usar componentes nativos incluso en enfoques multiplataforma. Esta importante mejora ha afectado al mercado de muchas maneras y ha acercado un paso más a todas las plataformas móviles hacia la unificación de la experiencia visual del usuario en varios dispositivos y plataformas.

Si decide optar por una solución multiplataforma, puede comenzar como en una aplicación nativa estándar construyendo el esqueleto de su aplicación. Una vez que tenga sus prioridades principales en funcionamiento (establecer dependencias base, crear un MVP, alcanzar hitos específicos del proyecto, lanzar su primera versión, etc.), puede separar fácilmente sus diseños principales para las dos aplicaciones, utilizando la plataforma: herramientas específicas que proporciona cada marco. Según el tamaño de su equipo y el marco de tiempo disponible, incluso podría considerar incluir esos ajustes en la versión 1, solo para evitar confusiones futuras cuando las cosas ya no se vean igual en una versión de plataforma determinada.

Después de todo lo dicho y hecho, debe evaluar cuál de esos principios será válido para su aplicación. Como en casi cualquier esfuerzo en nuestra industria, debe tratar de seguir las pautas, mientras las ajusta ligeramente para que se ajusten a sus necesidades específicas. Por ejemplo, si la navegación por cajones es lo que realmente tiene sentido para su aplicación simple de cinco pantallas, entonces no necesita encontrar soluciones complicadas para cada plataforma. Haga que sea obvio y fácil para el usuario reconocer sus botones y herramientas personalizados, ya sean componentes clave o solo personalizaciones menores.

El buen diseño respeta los hábitos del usuario

En resumen, podemos repetir algo que ya sabemos, el buen diseño es el diseño que respeta los hábitos de los usuarios en cada sistema operativo. Solo un poco de pulido al final puede marcar la diferencia entre una aplicación promedio y una excelente.

Muchas veces, su aplicación no proporcionará suficientes características únicas para ganarse a los usuarios solo con contenido. La mayoría de las personas describirán su decisión de elegir un producto sobre otro con "un presentimiento". Esta categoría de usuarios basa sus elecciones principalmente en cómo se sienten al usar la aplicación al evaluar implícitamente la capacidad de respuesta, la elección de estilo general, la paleta de colores y los componentes visuales individuales que ven en la pantalla.

Por lo tanto, trate de asegurarse de que su producto se destaque no solo en virtud de sus increíbles características, sino también con un empaque de alta calidad que coincida con la calidad de los servicios que brinda.