Migrar para crecer
La experiencia de diseñar una interfaz nativa.
En esta nota quiero compartir la experiencia y el aprendizaje de migrar la UI (User Interface) de una aplicación híbrida a nativa; y algunas recomendaciones para que el camino hacia el diseño de apps nativas sea ¡una fiesta!
Antes que nada, un poco de contexto
Esta experiencia fue compartida junto a Paula Mariel Martínez, UI Designer en Flux IT, con la cual trabajé y crecí durante este proyecto. ¡Muchas gracias, Pau!
Nuestro cliente para este desafío es una de las empresas financieras más importantes del país, la cual aspira a ser un Banco 100% digital.
Se nos planteó de su lado un deseo y una necesidad: realizar la migración de su aplicación (híbrida, desarrollada en NativeScript) y convertirla a nativa. Para eso, tuvimos que generar dos versiones desde la UI: una para iOS y otra para Android.
¿Por qué migrar a nativo?
Desde el punto de vista de la experiencia del usuario, brindarle una aplicación nativa ayuda a reducir su curva de aprendizaje, ya que es un producto que maneja los mismos estándares visuales y de navegación que ya acostumbra usar en su smartphone todos los días.
Al hacer esto, se reduce muchísimo el esfuerzo cognitivo que deben realizar: la idea es que los procesos fluyan, que el usuario sólo se concentre en las acciones específicas que debe realizar dentro de la aplicación, sin distracciones.
¡A darle átomos!
Para poder llevar a cabo la migración de una app a nativa necesitábamos interiorizarnos mucho en la materia, por lo cual comenzamos con una profunda instancia de research: analizamos casos con las mejores prácticas, leímos decenas de artículos en Medium, estudiamos aplicaciones con altas calificaciones de los usuarios y profundizamos en los guidelines de cada sistema.
En el caso de Android, cuenta con un design system sólido y súper completo llamado Material Design. Éste fue una fuente de consulta y apoyo permanente (además nos ofreció un bellísimo plugin para sketch). Mientras que para iOS, acudimos a su guideline (más bien su filosofía): Human Interface Guidelines, cuya librería viene integrada con Sketch.
Ambas contábamos con los mismos wireframes y cada una con su “biblia” de consultas, pero había otro factor que sería verdaderamente crucial para cumplir con el objetivo del proyecto: que trabajáramos a la par. Y lo hicimos… literal. Diseñamos sentadas una al lado de la otra desde el minuto cero, debatiendo el uso de cada uno de los componentes. Haciendo proyectos gemelos en esencia, pero diferentes en todo lo demás.
1. Larga vida al Diseño atómico
En primer lugar, debimos generar nuestros símbolos (siguiendo la filosofía de Atomic Design ❤).
2. Grilla de 8px, nuestra regla de oro
Posteriormente, acomodamos nuestro grid (ambas trabajamos en Sketch). Hacerlo fue sencillo: hubo que setearlo en bloques de 8px (todos los componentes debían disponibilizarse sobre esta grilla, incluso de 4px, en el caso de elementos más pequeños).
Para setear la grilla hay que ir a view/canvas/grid settings.
Truquito: una vez seteada, al colocar un elemento en la pantalla se puede desplazar de a 8 px en la grilla, manteniendo apretado shift + cualquier flecha de movimiento.
3. Bienvenidos constraints
Algo muy útil que descubrimos en el proceso fueron los Constraints, los cuales, usando la grilla de 8px, nos ayudaron a generar espaciados entre elementos de manera cross, haciendo el proceso de trabajo mucho más ágil. Recomendamos leer esta nota que nos inspiró a trabajar de esta manera.
Devs y UIs, más unidos que nunca
En el proceso de trabajo aprendimos muchas cosas importantes a tener en cuenta al momento de diseñar aplicaciones nativas; y sobre todo, aprendimos que lo fundamental era mantener un diálogo fluido con nuestros compañeros y compañeras devs.
Hay algunos factores fundamentales para crear un gran equipo de trabajo con nuestros desarrolladores. Uno de ellos (si no el más importante) tiene que ver con las unidades de medida en las que vamos a diseñar y exportar nuestras pantallas. Acá va una breve explicación:
Los píxeles en Android (DP) son equivalente a los puntos en iOS (PT). Medir los elementos en pantalla en DPs o PTs a la hora de diseñar, garantiza que los diseños tengan un tamaño físico constante en dispositivos de densidad variable. Es decir, tu diseño va a verse bien en cualquier tamaño de pantalla.
Por ejemplo, si diseñamos un botón de 44dp (Android) o 44pt (iOS), va a verse del mismo tamaño en todos los dispositivos. Lo que varía de dispositivo a dispositivo es la definición que va a tener el mismo. A mayor densidad de píxeles, mayor resolución.
Parece magia, pero no lo es: es pura matemática.
Los DP en Android
Sketch nos ofrece un tamaño de pantalla base para Android de 360x640 dp. Ahora veamos esto:
Moto G: (720x1280 px) * 160/320 dpi (2x — XHDPI)= 360x640 dp
Nexus 5: (1080x1920 px) * 160/480 dpi (3x — XXHDPI) = 360x640 dp
Galaxy S6: (1440x2560 px) * 160/640 dpi (4x — XXXHDPI) = 360x640 dp
En resumen, 360x640 dp cubre la mayoría de los teléfonos actuales.
Los PT en iOS
En cuanto a iOS, el tamaño base a utilizar fue el del Iphone 8, 375x667 pt. Veamos medidas de algunos dispositivos:
iPhone X: (1125x2436 px) @3x = 375x812 pt
iPhone 8: (750x1334 px) @2x = 375x667 pt
iPhone 6s Plus: (1080x1920 px) @3x = 375x667 pt
iPhone 6 Plus: (1080x1920 px) @3x = 375x667 pt
iPhone 7: (750x1334 px) @2x = 375x667 pt
iPhone 6s: (750x1334 px) @2x = 375x667 pt
Como podemos ver, esta medida es compartida por una amplia gama de smartphones Apple.
Machete: 1 dp = 1px @ (1x en Android es igual a 160 dpi).
1 pt = 1px @ (1x en iOS varía de 132dpi a 163dpi.)
Tip importante: para poder trabajar de esta manera y que los assets se vean correctamente, es necesario trabajar siempre con vectores.
Todo esto nos sirvió en cada una de las instancias del proyecto, tanto cuando el foco estuvo en nosotras, como cuando finalmente se corrió a la etapa desarrollo.
Zeplin, nuestra herramienta estrella
Para cerrar el proceso (que contó con muchas instancias de revisión, feedbacks e iteración) utilizamos Zeplin en la exportación de los prototipos. Es una herramienta súper potente que permite mantener nuestro trabajo ordenado, para ser analizado e interpretado por los desarrolladores; y desde la cual se pueden descargar todos los assets sin la necesidad de recurrir a otras fuentes de consulta (carpetas en drive, correos electrónicos, etc.).
Instalando el plugin en Sketch, podemos exportar las pantallas, hacer que los recursos sean descargables, y los devs podrán bajarlos directamente desde la pantalla en @1x, @2x, @3x en PNG, SVG o PDF.
Es un todo en uno. Es fabulosa (la amamos fuerte!).
Tip: en en el caso de Android, hay que setear la visualización dentro de Zeplin, para evitar confusiones de medidas.
Una apreciación final
El proceso de migración nos llenó de aprendizajes sobre el lado más técnico y puro de las interfaces nativas; nos enseñó acerca de procesos y de la importancia de mantener una comunicación constante entre compañeros de equipo, en todos sus perfiles.
Esperamos que si en algún momento tenés que transitar el camino hacia el diseño nativo, estos tips te puedan ayudar a que el proceso sea mucho más fluído, si bien sabemos que hay extensos recursos y diferentes maneras de abarcar proyectos.
¡Salud, por las experiencias nativas!
