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?

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!