Afrontar proyectos interactivos (2): Empezar a Prototipar

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!

Afrontar proyectos interactivos (1)

Estamos en una época interesante de efervescencia creativa en lo que a contenidos digitales se refiere: e-books, apps, webs, blogs, etc. florecen de manera acelerada llenando de posibilidades ocio y aprendizaje las memorias de los dispositivos móviles de millones de usuarios en un mercado global.



Pero afrontar un proyecto interactivo es, en general, un proceso complejo no exento de riesgos, y como tal tiene que superar una serie de obstáculos que pueden hacerlo naufragar en cualquier instante.

Tanto si se trata de un sitio web, una app o un libro electrónico, los proyectos interactivos digitales tienen una serie de peculiaridades que hay que tener en cuenta desde la misma concepción del proyecto. A menudo, por motivos variopintos, se suele empezar la casa por la ventana y eso es un error que suele pagarse caro al cabo del tiempo.

Es por eso que en esta serie de artículos quisiera sacar a la luz cuáles son —en mi opinión— los puntos más delicados de este tipo de procesos, por si pueden ser de utilidad.

Para empezar, siempre es conveniente hacer un listado básico de requerimientos del proyecto. Para ello, podemos realizarnos una serie de preguntas rápidas:

1) El producto ¿saldrá a la venta pública o es para distribuirlo en un entorno privado? (una intranet de una empresa, por ejemplo).
2) ¿En cuántos idiomas estará disponible?
3) ¿Para cuántos sistemas o entornos estará disponible? (iPad, Android, Ordenadores…)


Con estas tres respuestas se puede concretar bastante la envergadura del proyecto en cuanto a su desarrollo, y se pueden empezar a plantear posibles soluciones tecnológicas ¿por qué?

1) Existen diferentes mercados (AppStore, Google Play, iBookStore, Amazon…) cada uno con sus particularidades y restricciones.

2) Hay que plantearse desde el principio si una aplicación o libro estará en varios idiomas a la vez o habrá una edición por cada idioma, ya que es un condicionante bastante importante que determina el cómo se hará la posterior implementación.

3) Cada sistema suele ir ligado a un mercado o tienda (AppStore a iOS, Google Play a Android,  etc.) pero además cada herramienta de producción puede estar también ligada a una de estas opciones, como es el caso de iBooks Author, que permite desarrollar libros electrónicos disponibles solamente en iBookStore y solamente para iOS y MacOS.

Con frecuencia estas preguntas podrían parecer absurdas para el cliente estándar, o sea el que quiere algo “Que haga de todo, que funcione en todos los dispositivos, que esté en todos los mercados”. Y por supuesto, en un solo producto B.B.B. y para antes de ayer.

Éste es el primer paso delicado en el desarrollo de un proyecto interactivo: decidir qué formato tendrá el producto. ¿Será una app? ¿Será una web? ¿Una web app? ¿Un e-book? ¿Todo a la vez?

Imagen de obra inacabada. (fuente: La Verdad de Murcia)

En este punto, se puede aplicar la filosofía Kaizen: primero se hace, luego se mejora. Desde que se genera el encargo de realizar un proyecto, pesa sobre él una espada de Damocles: que se acabe convirtiendo en un Development Hell, en una obra faraónica que jamás esté terminada. Esta amenaza se cierne en todas las fases del desarrollo y por múltiples motivos, así que en el estadio inicial de conceptualización hay que ser flexibles y desechar (al menos temporalmente) una multiplicidad de opciones o caminos que incrementen desproporcionadamente el coste/tiempo de desarrollo.

Para ayudar a hacer esta criba, se pueden aportar datos estadísticos sobre el mercado: cuál es la penetración de mercado de un cierto dispositivo, cuál es la visibilidad de en qué tiendas de qué tipo de producto, etc.

Hay ideas que se adaptan mejor a un formato app para smartphone, otras que tendrían mejor salida en forma de e-book para iPad, etc. Para apoyar esta decisión, se pueden listar los pros y contras en cuanto a las funcionalidad que ofrece cada plataforma, y contrastarlo con las bondades de cada uno de sus mercados asociados.

Por ejemplo: un videojuego sencillo gratuito puede tener una gran acogida en el mercado Android (Google Play) y no ser prioritario como juego para ordenadores via Facebook, dependiendo de cómo sea ese juego. 

De igual modo, un catálogo de arte puede ser un producto atractivo como un libro para el iPad, pero no tanto como una app para Android. Esto no es para descartar una plataforma pero sí para acotar y priorizar objetivos. Un producto puede salir al mercado en un formato determinado en una fecha determinada y más adelante ampliar su radio de acción a otros mercados y plataformas. Esperar a tenerlo todo terminado y perfecto puede ser una fuente multiplicadora del tiempo de desarrollo, y cuando los productos van asociados a campañas de marketing, la presión sobre éste puede derivar en multitud de males propios de los Development Hells.

En una próxima entrega hablaré de la fase de diseño de prototipos, el inicio del ahora tan manido UI/UX.

Hasta la próxima, ¡felices conceptualizaciones!