¿Deben las aplicaciones de iPhone y Android ser trazadas por separado?

Después de haber trabajado mucho tanto en Android como en iOS, recomendaría crear conjuntos de wireframes separados para ambas plataformas. Las interacciones y las expectativas del usuario en ambas plataformas son muy diferentes.

Algunas de las cosas que es posible que desee tener en cuenta incluyen (hablar sobre ello desde una perspectiva de Android para facilitar las cosas):

Tamaño de pantalla:
Los teléfonos Android vienen en todas las formas y tamaños. Android ha creado cuatro cubetas de pantalla fijas dependiendo del tamaño y la resolución de la pantalla (densidad de pantalla baja, media, alta y extra alta) y requiere que los fabricantes de teléfonos confirmen estas cubetas de densidad para garantizar que las aplicaciones escalen bien. Sin embargo, desde la perspectiva de un diseñador, esto significa que ahora tiene que diseñar para una pantalla tan pequeña como dos pulgadas a una que tenga más de 7 pulgadas. Y también tamaños de pantalla ambiguos, como 5 pulgadas, que se encuentran entre la categoría de tableta y teléfono. El diseño de una aplicación escalable (o quizás receptiva es la palabra correcta para usar aquí) requiere una buena cantidad de pensamiento para garantizar que el usuario obtenga una experiencia consistente independientemente del dispositivo que se utilice.

Variaciones de hardware:
Algunos teléfonos Android tienen un teclado QWERTY deslizable (lo que significa soporte obligatorio para el modo horizontal), algunos tienen una tecla de búsqueda dedicada pero otros no (los teléfonos Samsung son notoriamente infames por esto). Estas variaciones también deben tenerse en cuenta para que su aplicación funcione de manera consistente para todo tipo de usuarios.

Sistema operativo:
Dado que Android es de código abierto, la mayoría de los fabricantes de hardware personalizan el sistema operativo Android con el fin de diferenciar sus productos a los ojos de los clientes. Esto conduce a inconsistencias en el aspecto de una aplicación y, a veces, en ciertos dispositivos. Con Ice Cream Sandwich (Android 4.0), Google ha tratado de cerrar esta brecha hasta cierto punto al hacer obligatorio que el tema stock Ice Cream Sandwich (Holo) se incluya con todos los envíos del sistema operativo; sin embargo, este problema sigue siendo relevante (persistirá) durante muchos meses más), ya que menos del 2% de todos los dispositivos Android ejecutan Ice Cream Sandwich.

Estas variables aumentan la complejidad en gran medida y dan lugar a muchas variaciones, todas las cuales deben tenerse en cuenta al desarrollar para Android.

Por otro lado, dada la naturaleza estandarizada del iPhone (mismo sistema operativo central para todas las configuraciones de iPhone y un conjunto fijo de interacciones), el diseño es una tarea más simple. Ya no tiene que preocuparse por las diferentes características del hardware, y la única variable real que debe tenerse en cuenta es la resolución de la pantalla, ya que los dispositivos más antiguos carecen de una pantalla de retina.

Para empezar, es posible que primero desee crear wireframes para iPhone, ya que las interacciones están bien documentadas y son más fáciles de entender (variables menores para trabajar).

También puede hacerlo al revés, comience con Android y luego transfiera su aplicación a iOS; sin embargo, su velocidad en ese caso se reduciría y pasaría innecesariamente más tiempo debatiendo las opciones de diseño (Android, a pesar de las pautas recientemente publicadas aún tiene muchas áreas grises en términos de interacciones y uso de elementos) que podrían aclararse una vez que haya pasado por el proceso en otra plataforma donde, debido a las limitaciones / reglas de la plataforma, se ve obligado a diseñar su aplicación dentro de ciertos límites. Además, Android acaba de sufrir una metamorfosis importante: iOS se ha mantenido más o menos constante en términos de sus interacciones y experiencia de usuario desde su lanzamiento inicial. Validar su diseño y suposiciones sería más fácil con los usuarios de iOS.

Una vez que haya completado este proceso para iOS, es posible que desee dedicar un tiempo a familiarizarse con Android, desarrollar una comprensión y apreciación de las variables que afectarían el diseño de su aplicación y luego diseñar un diseño escalable que funcione a la perfección en una miríada de dispositivos que el ecosistema de Android tiene ofrecer.

Algunos enlaces para ayudarlo a comenzar:

  • Portar su aplicación iOS a Android: http: //www.androiduipatterns.com… (un poco anticuado desde que se lanzó Ice Cream Sandwich en diciembre, sin embargo, sigue siendo una gran lectura)
  • Pautas de la interfaz humana de iOS: http://developer.apple.com/libra…
  • Pautas de diseño de Android: http://developer.android.com/des…
  • Diseño de interacción para Android: http://www.androidpatterns.com/
  • Patrones de iPhone: http://pttrns.com
  • Patrones de Android: http://androidpttrns.com

Personalmente, creo que es mejor diseñarlos por separado. La razón principal es que siento que es una experiencia de usuario más intuitiva adherirse a los patrones de IU con los que el usuario está familiarizado desde el sistema operativo.

Un ejemplo obvio de tal diferencia entre Android e iOS es la navegación “hacia atrás”. En Android, esto tiende a implementarse usando un botón de hardware dedicado, mientras que en iOS generalmente se hace usando un botón “atrás” en la barra de encabezado. Si bien es posible imitar el comportamiento de iOS en una aplicación de Android, la mayoría de los usuarios de Android estarán más familiarizados con el uso del botón de hardware.

Debes hacer diferentes especificaciones. Como algunas personas ya destacaron, existen diferencias significativas en los paradigmas (claves de hardware, navegación general, etc.) y los usuarios finales esperarán una experiencia alineada con su plataforma de elección. Para Android, también deberá considerar las resoluciones de pantalla, el paisaje y el soporte de trackball de manera diferente que para iOS. Al mismo tiempo, iOS le dará más transiciones y similares de fábrica.

Más importante aún, considere el contexto de las partes interesadas y los miembros del equipo a los que se entregan sus especificaciones, muy probablemente diferentes equipos de ingeniería / control de calidad. Casi de cualquier manera que se configure el equipo y el proceso, será más fácil comunicarse dentro de las pistas separadas; e iterar / expandir / revisar el diseño si mantiene sus especificaciones separadas. Yo diría que lo mismo es cierto para otras partes interesadas (por ejemplo, la gestión de productos), incluso si las dos plataformas tienen una gestión compartida y se trata en paralelo.

Si este es su primer proyecto móvil, ponga su énfasis principal en una plataforma a la vez. Termina resolviendo la mayoría de los asuntos desafiantes y estratégicos en el primero, y luego adopta de manera apropiada para la otra plataforma. Obtendrá una segunda iteración en su propio diseño (de forma gratuita) cuando se acerque a la otra plataforma, y ​​abrace sus aspectos específicos en ese momento (aún tendrá una estructura de alto nivel dada por la primera plataforma que se puede usar en comunicación con el equipos).