Tiempo estimado: 1-2 horas. Recomiendo hacer este ejercicio con las partes interesadas clave.

Empecemos con la premisa de que se le ha encargado la creación de una aplicación móvil. Lo primero que debes preguntarte es: «¿Qué problema estoy resolviendo y para quién lo estoy resolviendo?». Las respuestas a esta pregunta compuesta sentarán las bases de tu diseño, ya que te proporcionarán información que podría impulsar las características y funciones de tus diseños. Estas respuestas también te ayudarán, sin duda, a decidir cuál será el MVP (producto mínimo viable) de tu diseño.

Por ejemplo, puede que tengas un montón de características en la hoja de ruta del producto, pero sólo necesitas centrarte en las características esenciales para lanzar con éxito la primera versión de la app. Puedes empezar preguntándote «¿Qué características y funciones necesitamos crear para que nuestro grupo demográfico objetivo pueda completar su objetivo/tarea?»

Para responder a esta pregunta, puedes crear un flujo de usuario basado en el «camino feliz» de tu usuario principal (puedes centrarte en todos los casos extremos más adelante). Recomiendo una pizarra en la que primero escriba todos los pasos clave del usuario. Una vez que tengas esos pasos clave escritos, puedes empezar a crear bocetos de alto nivel de estos pasos. Esto te ayuda a determinar qué asequibilidad necesita el usuario en cada paso del camino y mantiene a raya el desplazamiento del alcance.

Nota: Intenta evitar hacer bocetos sin escribir primero el flujo del usuario. Nuestras mentes pueden ser muy creativas y desviarse del camino si nos lanzamos directamente a dibujar.

Aquí tienes el aspecto que puede tener este ejercicio después de haber escrito tu flujo de usuario y haber creado bocetos debajo de él. Recuerda que no tiene que ser bonito, pero debe transmitir tus ideas lo suficiente para que pases al siguiente paso, los wireframes digitales.

Ejemplo 1

Ejemplo 2

Ejemplo 3

Segundo paso: Wireframes digitales de baja fidelidad

Tiempo estimado: 2-3 días, dependiendo del alcance del MVP.

Una vez que tengas tus wireflows del MVP resueltos, el siguiente paso es crear wireframes ligeramente más detallados. Puede crear un prototipo en papel o pasar directamente a los wireframes digitales (si la velocidad es esencial, suelo pasar a los wireframes digitales).

Nota: Si está trabajando con una marca establecida, podría ser posible utilizar componentes de un sistema de diseño existente y podría pasar directamente a la alta fidelidad, paso 3, a continuación.

Recomiendo crear artboards para las pantallas clave que descubrió en su ejercicio de bocetos. El número de pantallas que necesita aumentará a medida que avanza en el proceso de wireframing de bocetos, wireframes de baja fidelidad, a wireframes de alta fidelidad.

Tablas de arte en Adobe XD, una plataforma para el diseño y la creación de prototipos de sitios web, aplicaciones, juegos y más.

Para los wireframes digitales de baja fidelidad, utilice la herramienta de diseño de su elección para crear formas simples y utilizar fuentes básicas para crear sus wireframes. También hay muchos kits de interfaz de usuario por ahí que pueden acelerar este proceso y crear diseños de baja fidelidad que son un poco más atractivos visualmente. También recomiendo utilizar un tamaño medio de mesa de trabajo que pueda funcionar en la mayoría de los tamaños de pantalla de los teléfonos. Si usted tiene los datos de su objetivo demográfico y lo que el tamaño del teléfono es predominantemente utilizado por ellos, a continuación, vaya con ese tamaño de la pantalla.

Utilizo un tamaño de 875 x 667px de artboard cuando se utiliza Adobe XD (o cualquier herramienta de diseño, ya que la mayoría tienen tamaños preestablecidos incorporados), ya que es el «camino medio» de los tamaños de pantalla (especialmente para el iPhone). Me parece que este tamaño funciona bien para el iPhone 8 y el iPhone X, y me parece que esto funciona bien para Android también.

Aquí hay un ejemplo de pantallas de baja fidelidad en acción:

Múltiples tablas de arte representan un flujo de usuario en Adobe XD.

Una vez que haya creado sus pantallas de baja fidelidad, probado sus diseños con los usuarios y recibido la aprobación de las partes interesadas, ahora está listo para crear las pantallas de alta fidelidad.

Paso tres: wireframes digitales de alta fidelidad

Tiempo estimado: 1+ semanas. Esto dependerá de si usted tiene un sistema de diseño en su lugar o si usted está creando desde cero a medida que avanza. Este paso también lleva más tiempo, ya que es probable que se añadan más pantallas que en la fase de baja fidelidad.

¡En este paso es donde sus diseños cobran vida! También es la fase en la que tus diseños empiezan a parecerse realmente a una aplicación móvil que funciona y que puedes prototipar, probar, iterar, obtener la aprobación y, finalmente, entregar al equipo de desarrollo.

Consideraciones:

  • Si el producto en el que estás trabajando ya tiene una marca establecida, lo más probable es que saques los colores, los iconos y las fuentes de las directrices de la marca.
  • Si el producto en el que está trabajando no tiene un aspecto de marca totalmente establecido, puede utilizar un kit de interfaz de usuario para acelerar su proceso de diseño.

La siguiente consideración es con qué pantallas empieza. Usted puede comenzar con:

  • Pantallas clave para cada sección de su navegación principal, o;
  • Los flujos de usuario clave para el usuario, o;
  • Priorizar las pantallas que usted diseña basado en el orden del calendario de desarrollo (esto es típicamente donde empiezo, así que puedo trabajar en un método ágil, asegurándose de tener pantallas listas para el traspaso como el equipo de desarrollo necesita).

En este ejemplo, voy a mostrar el proceso de uso de un kit de interfaz de usuario establecido en Adobe XD. Y voy a empezar con el inicio de sesión/registro de usuarios y la creación de perfiles porque los equipos de desarrollo con los que he trabajado suelen empezar con la gestión de usuarios en su proceso de desarrollo de aplicaciones.

El kit de interfaz de usuario que elegí ya tiene una paleta de colores establecida, estilos de caracteres y elementos comunes de la interfaz de usuario (también conocidos como componentes) que se pueden copiar y pegar a lo largo de los wireframes.

Nota: Al principio, recomiendo convertir cualquier elemento que planee reutilizar en componentes (o símbolos). De esta manera, si usted necesita cambiar la flecha hacia atrás de una flecha » ← » a una zanahoria «<«, puede cambiarlo a través del componente maestro y hacer que se actualice a través de todos los wireframes frente a tener que copiar y pegar la edición en cada pantalla que necesita ser actualizada.

Ejemplo de colores, estilos de caracteres y componentes:

Para empezar el proceso, yo empezaría a construir las pantallas de incorporación, registro y perfil del usuario:

Luego, empezaría a construir los elementos de navegación global:

Después de esto, empezaría a crear alambres de alta fidelidad para todos los flujos de usuario de la app, empezando por los flujos priorizados basados en la entrega al desarrollo (o para cualquier elemento que aún necesite pruebas de usuario).

Recomiendo crear archivos de diseño separados para cada uno de los flujos de usuario clave, de modo que se pueda crear fácilmente un prototipo y compartirlo con el desarrollo cuando se trabaja en un método ágil (es decir, un archivo para el registro del usuario y la creación de la cuenta, un archivo para la mensajería, un archivo para la experiencia de búsqueda, etc.).

A medida que los diseños se aprueban y se entregan al desarrollo, recomiendo crear un archivo maestro con todas las pantallas y componentes maestros. Cuando se trabaja en equipo, suelo recomendar que una persona se encargue del archivo maestro para reducir la confusión. De esta manera cada miembro del equipo sabe que están tirando del archivo maestro aprobado cuando se trabaja en la creación de nuevas características y flujos para la aplicación.

Por ejemplo, aquí está una vista de pájaro de un archivo maestro para uno de mis proyectos. Observa que he agrupado y ordenado las pantallas por flujo de usuario y prioridad de desarrollo. Seguiré añadiendo a este archivo maestro a medida que construya la siguiente secuencia de flujos de usuario.

Algunos principios rectores para crear mejores aplicaciones móviles

Ahora que sabes cómo empezar a wireframear tus experiencias digitales, es el momento de subir de nivel tu enfoque de diseño. Si estás creando una experiencia para dispositivos móviles, en sistemas operativos como iOS y Android, hay algunas consideraciones clave a tener en cuenta. A continuación te ofrecemos algunos consejos generales (y algunas opiniones personales) sobre el diseño de aplicaciones móviles y cómo dedicar menos tiempo a diseñar para cada tipo de dispositivo del mercado. Si buscas más inspiración, también puedes consultar estos ejemplos de wireframes para sitios web y aplicaciones móviles.

Creo firmemente que un diseño debe ser lo más ubicuo posible. Así que siempre que sea posible, animo a un diseño agnóstico del sistema operativo. He aquí por qué:

  • Si un usuario cambia de un teléfono Android a un iPhone, no debería tener que aprender dos formas diferentes de utilizar una aplicación que resuelve la misma necesidad. La solución debería seguir siendo la misma. Ya sé que puede haber diferencias en los gestos y en las prestaciones específicas de cada dispositivo, pero creo que una aplicación debe ofrecer la misma interfaz de usuario y el mismo flujo de trabajo, independientemente de su sistema operativo. Y las funciones importantes no deberían ocultarse demasiado en los menús contextuales; eso es simplemente una mala UX.
  • Es costoso diseñar, desarrollar y mantener dos (o más) experiencias totalmente diferentes (especialmente cuando la experiencia podría ser la misma independientemente de la plataforma).
  • Al diseñar y mantener las diferentes experiencias, éstas pueden empezar a ser muy diferentes. Esto puede perjudicar a la marca y dificultar el seguimiento y la implementación de los comentarios y las características.

Entonces, ¿cómo crear diseños ubicuos y ser agnósticos de los dispositivos? He aquí cómo lo hago:

  1. Trata mis diseños móviles como si estuviera diseñando para la web móvil. Mis diseños son responsivos porque hay infinitos tamaños de pantalla y densidades de píxeles (estos cambian tan rápido como las empresas pueden diseñarlos). Como diseñadores, no tenemos tiempo para diseñar para cada densidad de píxeles y no creo que mis clientes quieran pagar por ese tiempo, de todos modos. Por lo tanto, utilizo una anchura de la mesa de trabajo de 375, que funciona para la mayoría de los modelos modernos de iPhone y Android.
  2. Me ocupo de la extraña forma de la pantalla del iPhone X y del iPhone 11 diciéndole al equipo de desarrollo que simplemente extienda el color de fondo de la cabecera hasta la parte superior.
  3. Tengo la suerte de tener varios tipos de teléfonos diferentes a mi alcance, por lo que puedo probar mis diseños a través de la aplicación móvil XD utilizando un USB. Esto es útil porque puedo probar los tamaños de las fuentes, los puntos táctiles de la UI y la visibilidad del contenido de la pantalla cuando el teclado está levantado. También puedo probar la línea de «plegado» y asegurarme de que el contenido importante, como las CTA y el contenido importante, permanece visible y no desaparece de la parte inferior de la pantalla.
  4. Intento utilizar sólo gestos que sean universales, por ejemplo, tocar, deslizar, pulsar y mantener. Creo que deberíamos ser capaces de centrarnos en la mejor experiencia de usuario independientemente del sistema operativo.
  5. Utilizo SVGs para todos los iconos y logotipos para que se vean muy bien en cualquier resolución de pantalla.
  6. Utilizo estructuras de navegación y menús que sean universales y no demasiado específicas para el sistema operativo.

La única vez que tengo que diseñar wireframes que sean específicos para un dispositivo es cuando estoy haciendo un prototipo y llamo a una función nativa del dispositivo, como la cámara. Incluso eso puede variar de un teléfono a otro y del sistema operativo.

La mayoría de mis clientes comienzan con iOS. Probamos y validamos el diseño y, una vez que va por buen camino, entonces desarrollamos para Android. ¿Y sabes qué? Intentamos no cambiar la UI en absoluto, ni los flujos de usuario. En su lugar, nos centramos en la marca, el aspecto y la sensación, las características y las funciones, y los flujos de usuario. Todo vuelve a lo más importante: la experiencia del usuario principal.

admin

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

lg