En la entrega anterior de esta serie de artículos sobre consejos a la hora de afrontar proyectos interactivos, había mencionado la importancia de empezar haciendo preguntas sobre el tipo de productos que realizaremos, qué características tendría y cuáles de dichas características son compatibles con los mercados objetivos donde pretendemos comercializar dicho producto.
Para ello, conviene realizar una tabla similar a ésta (con formatos, dispositivos y prestaciones) para ayudar a incluir o descartar tanto mercados como funcionalidades.
Por ejemplo, imaginemos que nuestro cliente desea editar una guía turística interactiva, digital. No sabe si habrá de ser un e-book, una app o qué. Solo sabe que quiere sacar al mercado, a la venta, una de sus guías turísticas en formato digital. Por supuesto, desea la máxima difusión posible y que tenga una serie de elementos interactivos que la conviertan en un producto diferenciado y novedoso. Y también, como siempre, que sea algo B.B.B.
Lo primero que podemos plantear a este cliente es una serie de preguntas simples:
1) ¿Cuál será el entorno de reproducción típico de tu guía? (en casa, en la calle, etc.)
2) ¿Piensa incluir contenido multimedia? (audio, vídeo)
3) ¿Será un contenido offline o dependerá de una conexión? (¡o mixto!)
4) ¿Es una guía de lectura, de consulta, o un manual práctico?
Estas preguntas nos pueden servir para discernir si el producto final se adapta mejor a lo que sería una app para smartphones, un e-book para e-readers o una publicación digital para tabletas, y construir combinaciones posibles, como por ejemplo:
Combinación A: Manual práctico, pensado para entorno móvil (calle), sin necesidad de vídeos pero con gran capacidad interactiva (secciones, mapas, etc.) y con todos los contenidos offline —> Solución más factible: Una app.
Combinación B: Guía de referencia para la lectura, tanto para leer en casa como en movilidad, que no dependa de la conexión, y donde los contenidos sean de alta calidad (vídeos HD, fotos alta resolución) pero donde la interactividad no sea sofisticada —> Una publicación digital para una tablet.
Combinación C: Guía interactiva donde la clave sea el intercambio social “2.0” de la información entre una comunidad de usuarios. Solución más factible —> Web móvil o ‘“Web App”
Una vez que se ha despejado el horizonte en cuanto al tipo de producto a desarrollar, antes de iniciar la programación (en caso de ser una app sobre todo) es preciso realizar un prototipo o “mockup”. Los prototipos son un paso intermedio indispensable. Por un lado, permiten mostrar diferentes propuestas de diseño gráfico de la aplicación, así como lo que se denomina el UX / UI (Experiencia de Usuario, Interfaz de Usuario, sobre todo esto último) y escalar el proyecto en fases separables.
Ejemplo de diseño esquemático de interfaz de usuario para app móvil
Esto es importante, ya que a menudo los proyectos se alargan más de lo previsto debido a que el cliente final no acaba de decidirse por un diseño, una funcionalidad, debe consultarlo con otras personas que deciden o que, simplemente, no sabe bien lo que quiere.
Entonces, antes de invertir una cantidad importante de tiempo y recursos en movilizar a toda una plantilla de desarrolladores, que son los que se limitarán a implementar un diseño según unas instrucciones precisas, es conveniente crear prototipo a modo de “modelos de juguete” para que el cliente se familiarice lo más posible con el aspecto y usabilidad que tendrá su aplicación.
En el caso de un libro electrónico, las posibilidades de diseño de interfaz de usuario se reducen, ya que el libro no es más que un contenido insertado en una aplicación de lectura que ya dispone de su propio interfaz de usuario, cuyo aspecto o funcionalidad queda fuera del presupuesto del desarrollo del proyecto obviamente (a menos que el cliente se empeñe en suplantar “como sea” esa interfaz, cosa que a menudo no es posible). Entonces, en un libro electrónico cobra más protagonismo el diseño gráfico y la arquitectura de la información visual más que el User Interface (UI).
Cuando el producto será una App, es muy probable que el cliente tarde en decidirse por una propuesta de diseño de interfaz u otra. Por eso, conviene presupuestar el diseño de varias propuestas puramente visuales sobre el aspecto que tendrán, al menos, las principales pantallas de la aplicación.
Ejemplo de mockup con conexiones entre pantallas, otra forma más avanzada
de construir prototipos para apps (cortesía de fluidui.com)
El crear un proyecto por etapas es también conveniente desde el punto de vista de evitar las lógicas tensiones de todo proyecto. En el desarrollo de un proyecto interactivo, uno de los puntos claves es la comunicación entre el cliente, el diseñador y el programador.
Por desgracia, con bastante frecuencia los proyectos naufragan por una comunicación defectuosa entre cualquiera de las partes, y no es rara ver cómo hay proyectos que empezaron con buen pie pero que al cabo de un tiempo el cliente decidió reiniciarlo de nuevo con otro proveedor (con éxito incierto) porque acabó “quemado” con el suyo actual, frustrado por una sensación de incomunicación. “El cliente no sabe lo que quiere” –dice el diseñador/programador– mientras que “Esta gente tarda mucho y no hacen lo que les pido” –se queja el cliente–
Para evitar estas situaciones desagradables, es preciso ser consciente de que estamos ante una tarea compleja. Y, como bien decía uno de los más grandes gurús de la simplicidad, John Maeda, la complejidad se empieza a disolver cuando dividimos los complejo en componentes más sencillas.
Siguiendo esta pauta, podemos empezar movilizando únicamente a un diseñador de UI para que dibuje, con la aplicación que le sea más fácil, una serie de pantallas interconectadas donde aparezca el diseño de la interfaz, las diferentes opciones y una serie de elementos simulados. Un prototipo o “mockup”, es decir, una representación ficticia, un guión visual de lo que será luego una aplicación interactiva.
De este modo, en una primera reunión el cliente y el proveedor pueden identificar en una fase temprana posibles problemas de diseño que, de otro modo, hubieran “explotado en la cara” en una fase muy avanzada del desarrollo, donde los cambios pueden no ser viables, donde los plazos aprietan y el presupuesto se acaba. Esta zona peligrosa se suele denominar Development Hell.
Por ejemplo, en esta fase, con el prototipo en forma de diseños en un papel, se puede detectar si los elementos de la aplicación caben físicamente en la pantalla, si la navegación es complicada, si se echa a faltar alguna funcionalidad, etc. sin tener que haber escrito antes ni una sola línea de código. Además, se puede someter al cliente a una elección de un diseño que más le guste de entre varias propuestas.
Una vez haya elegido un diseño y esté del todo de acuerdo con la navegación y elementos de la aplicación (sobre el papel, recordemos), puede ser un buen momento para pasar a la siguiente fase. Antes, se le puede solicitar al cliente que pague un % del presupuesto.
De este modo, nosotros como diseñadores/desarrolladores obtenemos una lógica y saludable recompensa económica (que estimula la motivación a seguir) y el cliente es consciente que ha pagado por algo tangible y que ya es suyo. En caso de que, por los motivos que fueren, éste decidiera no seguir contando con nuestros servicios, al menos ha pagado por algo finalizado (un prototipo) que le puede ser de utilidad para seguir con otra gente sin partir de cero, y nosotros no hemos perdido dinero desarrollando durante un largo tiempo un producto que al final no ha visto la luz y cuyo cobro estaría lícitamente en entredicho.
En la siguiente entrega hablaré sobre cuál es la actitud correcta para afrontar proyectos interactivos.
¡Felices desarrollos!
