Las apps son uno de los mercados que más crece actualmente, uno de esos pocos en los que no existe la crisis (y lo puedo asegurar como profesional de dicho sector). Pase lo que pase, seguirá habiendo smartphones y seguirá habiendo apps. Y si tu app es de calidad, ofrece un valor real al usuario y consigues obtener la visibilidad suficiente, se usará y te la pagarán. Pero para que esto ocurra, debe de haber un trabajo conjunto del diseñador (o equipo de diseño) y el programador (o equipo de desarrollo). Encontramos otras piedras en el camino como el equipo de QA, marketing, atención al usuario… pero nosotros vamos a centrarnos en el tronco del árbol, y más concretamente, en la rama que compone el diseño de interfaz y la experiencia de usuario.
Índice
¿Qué es UI y qué es UX?
En el interior de un diseño completo para una app o un producto de software encontramos muchos factores que interfieren y rincones oscuros. Principalmente podríamos decir que tenemos dos; por un lado, el diseño de la interfaz de usuario y por otro el diseño de la experiencia de usuario.
El diseñador de interfaz de usuario (UI) es aquel que define qué transmite la parte visual de la aplicación (iconos, imágenes, colores, tipografías…). Por otra parte, el diseñador de experiencia de usuario (UX) es el que define qué transmite la estructura y arquitectura la información, el flujo de pantallas y procesos, etc. En una tangente a esto encontraríamos el diseñador de interacción (centrado en la parte funcional de la app) y el motion designer o diseñador de animaciones.
En pocas palabras, podríamos decir que UI es cómo se ve y UX es cómo funciona. UX es “qué tal funciona esto y en qué lugar debe de ir”, mientras que UI es “de qué color debe de ser esto y qué debe transmitir al usuario”.
En los equipos y empresas grandes suele haber personas dedicadas a las distintas disciplinas de forma específica. Es decir, unas personas se dedican a la parte visual y otras a la funcional. En cambio en los equipos pequeños suele ser la misma persona la que trabaja ambos campos; pero claro, siempre destacará en uno por encima del otro (todos cojeamos de una pata).
Manos a la obra, ¿por dónde empezamos?
Es hora de comenzar con el proceso, y como todos los buenos procesos, comienza con una idea. Todos alguna vez hemos echado en falta algo de una app o hemos pensado “ojalá hubiese una app para hacer esto”. Los que nos dedicamos profesionalmente a las apps sabemos rentabilizar esa idea, pero para ello hay que conseguir un producto eficaz, atractivo, original y de calidad.
Un buen punto en el que apoyarnos para empezar nuestro proceso es descargar nuestra idea. Para ello conviene coger unos folios (o una libreta Moleskine, si tienes ideas diaria y constantemente) y expresarla en ellos de forma rápida para que no se nos olvide nada. Esto es plasmar frases, explicaciones y bocetos de la idea que hemos tenido. No hace falta que sea limpio ni tampoco que sea detallado; con que lo entendamos nosotros sobra, y si el grueso del asunto está bien expresado, genial (pues todo lo demás es secundario e irá pivotando durante el proceso).
Esto es algo real; tenemos que tener en cuenta que una cantidad considerable de lo que hayamos expresado en nuestro sketch inicial cambiará durante el proceso. Nuestra idea puede ser una buena idea, pero tenemos que refinarla para conseguir un producto excelente y eficaz, que nos reporte los beneficios que esperamos y que guste al usuario.
Ya he descargado mi idea, ¿cómo le doy forma ahora? Primer paso: planteamiento
A la hora de definir la idea que tenemos, debemos también pensar para qué plataformas irá dirigida. No es lo mismo hacer una app exclusiva de iOS que hacerla también para Android, Windows Phone o para ordenadores (ya sea vía web o vía app de escritorio). Cada una de estas plataformas tiene unos estilos, unas exigencias y unas bases, pero sobre todo unos usuarios específicos. Un usuario de iPhone está acostumbrado a ver las apps de cierta forma, distinta en parte a la que está acostumbrado un usuario de Android o Windows Phone.
Nosotros vamos a centrarnos exclusivamente en iOS en esta ocasión, y vamos a ver qué pasos seguir para que la estructura y arquitectura de nuestra aplicación sea consistente.
Antes de llevar a cabo este proceso, vamos a hacer un poco de benchmarking y a explorar otras ideas similares (normalmente, ya ejecutadas). Tenemos varias vías para hacerlo… por ejemplo, si nosotros tenemos una idea para un cliente de Twitter, podemos descargarnos todos los clientes de Twitter que encontremos en el App Store y hacer búsquedas relacionadas de este tema en Dribbble, Pinterest, Behance, etc. Ahí veremos qué han plantado los demás y de qué manera.
Otro factor que debemos de tener en cuenta es qué tipo de usuarios tendremos en nuestra app y en la usarán estos. No es lo mismo tener de usuario a una ama de casa de 50 años que a un adolescente de 15, al igual que no es lo mismo diseñar una app que se va a usar generalmente sentado y con dos manos que una app que se va a usar en el metro, en continuo movimiento y con una sola mano (pues con la otra, te agarras a la barandilla).
Redactar perfiles de usuario (ficticios, pero representativos) y contemplar el entorno es importante para obtener una visión de lo que nos podemos encontrar “ahí fuera”. Esto consiste en crear falsos usuarios. Por ejemplo: “Juan, de 26 años, que estudia en la universidad y cada mañana pasa 7 minutos en la parada y 16 minutos en el bus (…)”. En ellos contemplamos aficiones, inquietudes, tendencias y costumbres de nuestro personaje, los cuales nos ayudarán a realizar el proceso de la forma más real posible.
Durante el planteamiento también tenemos que redactar una lista de features y características de nuestra aplicación, así como una serie de requisitos e incluso un flujo o proceso de uso de la app, incluso aunque no tengamos definida la arquitectura ni la parte visual. Todo dependerá de la complejidad del producto que vayamos a trabajar y del tiempo que tengamos.
Es posible que muchas de las características que decidamos en esta lista ya las tengan las apps de “la competencia”. Parte de nuestro trabajo será encontrar esa característica estrella que no tengan las demás, o también saber mezclar todas éstas de manera limpia y sencilla para que nuestro producto sea eficaz. No siempre el producto más completo es el que más triunfa; hay que tener todos los puntos en cuenta y encontrar como término medio el equilibrio entre soluciones ofrecidas y simplicidad.
Wireframes: “pasando a limpio” nuestros sketches
Una vez tengamos claro el planteamiento, podemos empezar a desarrollar nuestro wireframe. Los wireframes son muy importantes en el proceso de diseño de una app; en ellos vamos a expresar, esta vez sí de forma limpia y detallada, cómo debe de ser la arquitectura de nuestro producto.
Podríamos hacer esto directamente en el tramo de ejecución de la interfaz, pero entonces partiríamos en esa fase desde cero (sin ningún cimiento previo), por no hablar de que el hecho de tener que definir funcionalidad a la vez que estética podría condicionarnos negativamente en ambas ramas. Zapatero a sus zapatos… y cada cosa en su momento y a su debido tiempo.
A la hora de hacer nuestros wireframes tenemos que conocer cómo suelen estar estructuradas las apps de iOS, pero sobre todo, cómo recomienda Apple hacer esto. Para ello estaría bien que nos leyésemos las guías que ellos mismos distribuyen. Es básico conocer qué elementos y componentes hay predefinidos y para qué funciones.
Los wireframes los podemos hacer por distintos medios. Si los vamos a hacer en papel, recomiendo usar libretas de hojas dotted, las cuales constan de una cuadrícula de pequeños puntos que nos ayudarán a hacer formas perfectas sin interferir en el diseño mediante líneas o franjas (como sí lo hace una libreta cuadriculada común). También podríamos hacernos con una plantilla específica para iPhone o para iPad e imprimirla; esto nos aporta además el contexto del dispositivo, muy útil para enseñarlo a terceras personas y que comprendan las cosas más fácilmente.
Por otra parte, si los preferimos hacer a través de nuestro ordenador, tenemos varias vías; desde programas y servicios específicos para ello como Balsamiq o UX Pin, pasando por otros no tan específicos pero igualmente válidos como Omnigraffle (mi favorito) o Illustrator y acabando en los mismos programas que vamos a usar para ejecutar nuestra UI. Es decir: Sketch o Photoshop. Para todos estos encontraremos recursos de utilidad y medios suficientes para poder cumplir con nuestro trabajo, tales como plantillas y proyectos de ejemplo o kits de elementos y componentes prediseñados.
Es importante que distingamos entre ejecutar un wireframe y ejecutar una interfaz; a la hora de componer un wireframe vamos a centrarnos en definir funcionalidad, flujo y navegación. Tenemos que decidir en qué lugar va cada cosa para poder facilitar el uso de nuestra app y conseguir que ésta sea intuitiva y usable. Por ello, los wireframes se deben de realizar en blanco y negro y sin ninguna interferencia por la parte visual (nada de imágenes, colores, tipografías, etc).
Prototipado, la forma de comprobar que hemos hecho un buen trabajo
Ya hemos dejado bien claro nuestro planteamiento y acabamos de realizar unos wireframes fabulosos para dejar claro en qué lugar debe de ir cada elemento y cuál va a ser el flujo que seguirá el usuario dentro de nuestra app. Ahora, vamos a comprobar si hemos acertado.
Para esto vamos a prototipar nuestros wireframes y presentarlo a personas que no sepan de qué va la cosa (y claro, que encajen con el target al que irá dirigida nuestra app). Muchos esperan a tener la interfaz lista para realizar estas pruebas, pero si haciendo nuestras labores de UX hemos cometido errores y nos esperamos a tener diseñada nuestra interfaz para comprobarlo, habremos perdido mucho tiempo (y en cierto modo, dinero).
Hoy en día existen maravillosos servicios para prototipar nuestros wireframes y presentarlos al público, para que estos lo puedan tocar y así averigüemos si nuestra estructura es intuitiva y funcional pese a carecer de interfaz gráfica o parte visual.
Mi herramienta favorita para prototipar es InVision, la cual es muy útil además para obtener feedback de otras personas (estén dentro de tu equipo o no) sobre los wireframes o pantallas finales de la app de manera interactiva y sencilla.
Con InVision podemos seleccionar zonas de nuestro documento y asignarle una función (generalmente, de ir a otra zona o pantalla) sumada a una animación. También encontramos como alternativas Marvel, la cual está especialmente centrada en mobile mientras que InVision abarca móviles, tablets, webs y, ahora, smartwatches.
OK, todo correcto… ¿siguiente paso?
Ha llegado la hora de materializar nuestra app y ejecutar nuestra interfaz, pues ya hemos comprobado que hemos hecho bien los deberes en cuanto a UX y ahora vamos a intentar repetirlo en UI.
Llegó el momento de definir estilos, colores, iconos, tipografías… mantener la simpleza debe de ser nuestro objetivo principal, pero al mismo tiempo tenemos que conseguir abarcar todas las funcionalidades y objetivos que previamente hemos planteado.
En el caso de iOS, Apple (como hemos visto anteriormente) ya da unas guías de estilos a seguir, pero si cumplimos esto a rajatabla obtendremos una app con carencia de personalidad y distinción. Seguir hasta cierto punto las guías de estilo que nos facilita Apple nos asegura que el usuario sabrá identificar cada elemento y, por lo tanto, sabrá usar nuestra app. Pero parte de nuestro trabajo consiste en fijar los límites de donde acaba lo establecido y donde empieza nuestra forma de obtener distinción y personalidad con respecto al resto de apps.
En la imagen de arriba, de izquierda a derecha, encontramos WhatsApp, Wunderlist y Scanbot. La primera de ellas (WhatsApp) está construida totalmente bajo las guías de Apple, utilizando su tipografía, su paleta de colores, sus iconos, el total de sus elementos… es una app con un diseño absolutamente nativo y por defecto. En el segundo caso, Wunderlist, sigue unas guías mínimas (barra de navegación, barra de tabs, disposición de elementos principales…) pero aporta sus puntos de distinción propios, tales como una tipografía diferente, paleta de colores independiente, iconos propios y otros componentes (como las tarjetas, el fondo personalizado, los checks de diseño propio…) que hacen que la interfaz de esta app sea muy original y propia, pero consistente con el resto del sistema. En el último caso, Scanbot, tenemos una interfaz totalmente propia que no sigue ninguna referencia más allá de los iconos de estilo lineal. Tiene otra estructura totalmente distinta, otra lógica de gestos, una paleta de colores muy marcada y propia y apenas cuenta con elementos característicos del sistema.
Esto no significa que esté mal, e incluso en apps sencillas (como Scanbot, precisamente) puede ser beneficioso.
Para llevar a cabo la ejecución de la interfaz, las alternativas son bastante más reducidas que las encontradas en los pasos anteriores. Los más veteranos usaban (y quizás siguen usando) Adobe Fireworks, pero dado el hecho de que Adobe decidió abandonar su desarrollo hace un par de años, no es un buen punto de partida para empezar a día de hoy. Esto hace que nos quedemos con Photoshop y Sketch. Illustrator también existe y está ahí, pero es un programa que nos pondrá varias barreras al diseñar para pantallas; quizás nos sea más útil durante el proceso de wireframing que durante la ejecución de la interfaz.
Photoshop es quizás el programa más usado en esta labor, pero es cierto que no se pensó para diseñar interfaces sino para retocar fotografías y otro tipo de tareas audiovisuales, por lo que nos encontraremos con muchas herramientas a las que no sacaremos partido y puede resultar muy complejo el proceso en manos de un novato. Por ello nació Sketch, una app centrada especialmente en diseño de interfaz y que nos deja al alcance de la mano todo lo que necesitamos.
La variedad de recursos que encontramos para iOS es descomunal. Dribbble, Tehan+Lax (cerrado y parte del equipo de diseño de Facebook ahora) y otras páginas aportan una infinidad de freebies que nos harán nuestro trabajo más fácil.
¿Seguimos haciendo un buen trabajo? Volvemos a prototipar
Anteriormente hemos realizado prototipos para comprobar que la parte funcional de nuestra app era la correcta. Ahora vamos a hacerlo para comprobar la parte visual. Esto nos servirá también para ver si a nuestro target de usuario le gusta el trabajo que hemos hecho y le resulta agradable; pues una vez hecho el “cómo funciona” debemos de hacer el “cómo se ve”.
Como extra, el prototipo nos servirá también para indicar al equipo de desarrollo con mayor exactitud y “simulación” el flujo de pantallas y les ayudará a comprobar la interacción de un elemento o componente en concreto.
¿Qué hemos sacado en claro?
Con este artículo se pretende hacer ver que el proceso de diseño de una app es más complejo de lo que parece y que consiste en algo más que “abrir un programa y pintar encima”.
“Diseño no es cómo se ve, es cómo funciona”, dijo una vez Steve Jobs. Y es cierto; pero para que algo funcione tienen que estar alineadas por completo las partes visuales y funcionales, y eso sólo se consigue con experiencia, iteración, estudio y… por supuesto, talento.
