Diseño de apps móviles: Del proceso clásico al proceso ágil

En Mobivery llevamos más de 5 años diseñando estrategias de movilidad. Una parte muy importante de la estrategia es el proceso de diseño. La mejora contínua forma parte de nuestro ADN y nos permite aportar cada vez más valor a nuestros clientes y usuarios. En este post explicaremos cómo realizamos este proceso de diseño y cómo va evolucionando paso a paso.

El enfoque “tradicional”

Este proceso consiste en un flujo lineal de entregas, divididas en fases, en las que mediante distintos documentos, se describe la aplicación y su comportamiento. Después de presentar la entrega al cliente, hay un tiempo de espera hasta que recibimos el feedback sobre el trabajo. Es importante señalar, que no se pasa a la siguiente fase hasta que el cliente valida la entrega.

A modo de ejemplo para explicar este proceso, hemos utilizado decompring, una app disponible para iPhone y Android que muestra al usuario los comercios más cercanos a su posición y las ofertas disponibles.

Documentos para el cliente

En primer lugar tenemos el Documento de Navegación, en forma de mockups (prototipo), para entender el flujo de la Aplicación. La razón de ser de este documento es que la persona que lo vea sea capaz de entender cómo va a funcionar la aplicación.

El segundo documento son 2 líneas gráficas (look&feel). Generalmente se dibujan 2 o 3 pantallas tipo para cada una de las 2 propuestas gráficas, de esta manera el cliente puede ver las diferencias entre unas y otras y elegir la que más le guste.

Una vez tenemos el look&feel validado se dibujan las pantallas más representativas de la aplicación, que son las que nos ayudarán a dibujar todos los elementos gráficos del interfaz de usuario para luego ser exportados.

Documentos para el desarrollador

Para que el desarrollador pueda ir implementando diseño, creamos una carpeta con los elementos de la aplicación.

Los desarrolladores necesitan un segundo documento, donde se definen las tipografías y colores de la aplicación.

Es decir, que en total hacemos entrega de 3 elementos al cliente y 2 a los desarrolladores. De los 3 entregables que realizamos al cliente puede pasar 1 semana entre una entrega y otra, esperando la validación de éste. Los otros 2 documentos son exclusivos, se utilizan a nivel interno y no necesitan ningún tipo de validación, puesto que su función es guiar al desarrollador para implementar el diseño correctamente.

Los problemas del enfoque tradicional

Ya hemos explicado el proceso ideal, pero hay contratiempos que no se pueden predecir. Uno de los problemas de utilizar este enfoque tradicional es que se alarga el tiempo desde que empezamos el proyecto hasta que el cliente puede probar la aplicación. Teniendo en cuenta las fases de entrega, sólo para la parte de diseño tenemos un tiempo mínimo de 3 semanas (suponiendo que el cliente “apruebe” todas las entregas a la primera), y al finalizar esas 3 semanas, sólo hemos generado documentación gráfica, pero nada que pueda se pueda probar en real.

También hay que tener en cuenta que, aunque un diseño sobre papel es una buena forma de comenzar a describir la app, la mejor manera de obtener feedback real y válido es pudiendo probar la app sobre un dispositivo.

Pero el principal inconveniente de este enfoque es que dificulta los cambios a mitad de proyecto. Dado que se va avanzando a medida que el cliente valida las entregas, el sistema limita la realización de cambios en las etapas más tardías del proyecto. Este enfoque tal vez sea válido para determinados tipos de proyecto, pero en base a nuestra experiencia en la creación de Apps, los cambios aparecen constantemente en todas las fases del proyecto. Estos cambios son positivos y beneficiosos para el resultado final de la app, pero el enfoque tradicional de proyectos hace que sea difícil y costoso aplicarlos.

El enfoque ágil

En base a la necesidad de hacer frente a los cambios, hemos adoptado una manera mucho más ágil para el diseño y creación de apps. Podemos poner como ejemplo el proceso seguido para desarrollar la nueva versión de GasAll, una app que indica al usuario cuáles son las mejores gasolineras donde repostar.

Aplicando un enfoque ágil, durante un “Sprint” de 2 semanas el equipo trabaja de manera conjunta, diseño y desarrollo, sobre las mismas funcionalidades.

  1. En primer lugar se fija el objetivo a cumplir durante las 2 semanas, eligiendo las 4 funcionalidades más importantes para poder subir la aplicación al Store.
  2. El segundo paso consiste en trabajar la fase de mockups conjuntamente, cliente, desarrolladores y diseñador. Con este sistema de trabajo se asegura el diálogo constante y directo entre el equipo y el cliente. Es decir, que lo que el diseñador dibuja es lo que el cliente necesita. Al mismo tiempo, el equipo de desarrollo es capaz de realizar lo que el diseñador dibuja en el tiempo que se ha fijado.
  3. Una vez el flujo de navegación está dibujado, diseño y desarrollo empiezan por la funcionalidad más importante fijada por el cliente. Por un lado, el equipo de diseño empieza a dibujar el arte final y a exportar elementos, mientras que los desarrolladores empiezan a montar la navegación y la lógica de la App para esa funcionalidad.
  4. Cuando diseño termina el arte final y completa la exportación de los elementos de la primera funcionalidad, desarrollo implementa ese diseño. En paralelo, diseño empieza a dibujar el arte final de la segunda funcionalidad.

En nuestro afán por agilizar procesos hemos eliminado el documento de tipografías y colores, ya que nuestros desarrolladores, gracias al trabajo en colaboración con los diseñadores, han adquirido suficiente sensibilidad visual para no necesitarlo. Una vez está implementada esta parte, el equipo acaba ajustando los últimos detalles.

De esta manera se van implementando las funcionaliades una a una, por orden de prioridad. Al final del Sprint se hace una “Demo” en la que el equipo presenta el resultado de su trabajo y recibe feedback directo por parte del cliente, ya sea de diseño o a nivel funcional.

Os lo ponemos en plan cómic:

¿Por cuál de los dos enfoques nos decantamos?

Después de trabajar con los dos enfoques, nos decantamos por la metodología ágil, los motivos principales son:

  • Permite reducir el tiempo que transcurre desde que el cliente/usuario hace una petición hasta que puede probarlo en un dispositivo.
  • Se facilita la introducción de cambios, aún en etapas tardías del proyecto.
  • El equipo trabaja de forma conjunta compartiendo un objetivo común, lo que repercute favorablemente en la motivación y fomenta la transferencia de conocimiento y el aprendizaje.

Autor: Helena Poch

Apps mencionadas|decompring y GasAll

Anuncios

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s