¿Una guía digital o tu propia aplicación? Costes y un método para elegir con criterio

Primero hay que determinar qué problema debe resolver la guía digital. ¿Los visitantes tienen dificultades para comprender el contexto de las piezas expuestas? ¿Faltan versiones en otros idiomas, contenidos de audio o una ruta familiar? ¿Los contenidos se quedan obsoletos rápidamente? ¿O el lugar quiere mantener el contacto después de la visita? Cada una de estas necesidades implica un alcance diferente del producto.

El simple hecho de tener un icono en una tienda de aplicaciones no resuelve ninguno de estos problemas. Es como encargar una bonita vitrina antes de decidir qué contendrá. Conviene empezar por describir las situaciones de uso, los contenidos y el proceso de trabajo del equipo, y después elegir la herramienta.

Por tanto, la pregunta adecuada es: «¿Cuál es la forma más sencilla de ofrecer al visitante el relato adecuado en el lugar adecuado y permitir que nuestro equipo lo amplíe después?». Una aplicación propia es una de las posibles respuestas, pero no debería ser la respuesta automática.

La primera opción es un sitio web sencillo al que se accede mediante un código QR. Funciona bien para unas pocas descripciones públicas, pero cuando aumenta el número de rutas, idiomas, grabaciones y colaboradores, pronto surge la necesidad de una interfaz de gestión de contenidos, herramientas de análisis y una navegación común.

El segundo enfoque es una plataforma compartida. El lugar utiliza una aplicación de visitas lista para usar, páginas públicas y una interfaz de administración, pero conserva su propio perfil, sus contenidos, sus exposiciones, sus rutas y su señalética. Las funcionalidades desarrolladas para varios lugares no tienen que encargarse desde cero por cada institución por separado.

La tercera opción es una aplicación móvil propia, acompañada de la infraestructura necesaria. «Propia» no significa simplemente cambiar el color de un botón. Generalmente incluye el diseño de la experiencia de usuario, una aplicación para iOS y Android, un servidor o servicios en la nube, una interfaz de gestión de contenidos, herramientas de análisis, pruebas, publicación y actualizaciones posteriores.

• Sitio sencillo: un alcance limitado y pocos procesos editoriales.
• Plataforma compartida: funcionalidades listas para usar, contenidos propios y una puesta en marcha rápida.
• Aplicación propia: control total, pero también plena responsabilidad sobre el producto.

No existe un precio único para una aplicación, porque el término abarca tanto un catálogo de unas pocas pantallas como un sistema completo con cuentas, pagos, un mapa, un modo sin conexión y una interfaz para el personal. Los datos de Clutch sobre proyectos descritos por sus clientes pueden servir como referencia: la mayoría de los proyectos analizados se situaban entre 10 000 y 49 999 dólares, pero el coste medio alcanzaba unos 90 780 dólares y la duración media del proyecto era de unos 11 meses.

Un estudio de GoodFirms realizado entre 167 empresas de desarrollo de aplicaciones indicaba unos 24 830-59 150 dólares para una aplicación sencilla y 59 508-137 150 dólares para una solución avanzada. Los datos de Clutch y GoodFirms describen el mercado general del desarrollo de aplicaciones. No constituyen un presupuesto para una guía de museo y no deben trasladarse mecánicamente a una oferta destinada a un lugar concreto.

Para comparar ofertas, utiliza un alcance hipotético común: 10 puntos, dos idiomas, una ruta y tres años de uso. Cada proveedor debe presupuestar el mismo alcance y especificar qué sigue siendo responsabilidad del lugar.

• Sitio con códigos QR: comprueba el coste de creación del sitio, del alojamiento y de las actualizaciones, así como la forma de editar los contenidos por tu cuenta.
• Plataforma de suscripción: ten en cuenta la puesta en marcha y la suscripción durante todo el periodo, los límites del plan y los posibles cargos adicionales.
• Aplicación propia: incluye el diseño, el desarrollo de la aplicación y de la interfaz de administración, la publicación, la infraestructura, las actualizaciones y el soporte.

En todos los casos, añade la preparación de contenidos y traducciones, la producción de la señalética, el tiempo de trabajo del equipo y el coste de exportar y transferir los datos si cambias de proveedor. Distingue los gastos puntuales de los recurrentes y comprueba qué elementos ya están incluidos en el precio. Solo este cálculo permite comparar tres años de uso de una solución.

Una aplicación no se convierte en una pieza de exposición terminada el día de su publicación. Apple y Google modifican sus sistemas, los requisitos de sus tiendas, sus políticas de privacidad y las capacidades de los dispositivos. Hay que actualizar las bibliotecas, corregir errores, supervisar la seguridad, probar nuevas versiones y reaccionar cuando un servicio externo cambia su funcionamiento.

GoodFirms indica una media anual de alrededor del 25% del coste de desarrollo para mantenimiento y soporte, sin incluir el desarrollo de nuevas funcionalidades ni el escalado del software. Se trata de una referencia general procedente de un estudio del mercado de aplicaciones, no de una tarifa de mantenimiento para una guía de museo. El alcance del soporte y su precio deben confirmarse en una oferta concreta.

A ello se suman los servicios en la nube, las copias de seguridad, la supervisión, las herramientas de análisis, el envío de mensajes, el almacenamiento de archivos multimedia y la asistencia a los usuarios. El coste de la infraestructura puede ser bajo cuando el tráfico es limitado, pero depende del uso. Firebase y servicios similares ofrecen calculadoras precisamente porque una única cantidad fija no puede cubrir todos los casos.

Las cuentas en las tiendas de aplicaciones representan solo una pequeña parte de la factura: la cuota estándar del Apple Developer Program es de 99 dólares estadounidenses al año, mientras que el registro en Google Play cuesta 25 dólares estadounidenses en un único pago. Apple señala que los precios pueden variar según la región. Preparar versiones, realizar pruebas, gestionar la publicación y mantener el cumplimiento de los requisitos exige más trabajo.

• actualizaciones y pruebas de las nuevas versiones de iOS y Android
• seguridad, copias de seguridad y supervisión de errores
• alojamiento, archivos multimedia, mensajes y otros servicios facturados según el uso
• gestión de las tiendas, de las condiciones de uso, de la privacidad y de las solicitudes de los usuarios
• desarrollo de la interfaz de administración y de nuevas funcionalidades

Tu lugar puede ser la parada más importante de la tarde del sábado de un visitante, pero rara vez es la única institución que visita durante el año. La petición de buscar una aplicación, instalarla, aceptar permisos y crear una cuenta suele llegar cuando la persona ya está en la taquilla o delante de la primera pieza expuesta.

Por tanto, una aplicación propia debe ofrecer un motivo claro para instalarla: una funcionalidad que se utilice repetidamente, una forma de visita excepcional, un acceso adquirido con antelación o una experiencia imposible de ofrecer en un sitio web. La mera presencia de descripciones y contenidos de audio puede no ser suficiente. Si cada lugar visitado exigiera una aplicación distinta, la pantalla del teléfono pronto parecería un catálogo de los escudos de toda una región.

Una plataforma común reduce esta barrera. El usuario puede conocer ya la aplicación gracias a una visita anterior y acceder a los contenidos públicos sin instalar nada. El lugar conserva su propio espacio y su identidad de marca, pero no pide al visitante que empiece la relación descargando otro programa.

El principal valor de una plataforma común no consiste en dar la misma apariencia a todos los lugares. Se trata de reutilizar aquello que no resulta razonable desarrollar por separado: el inicio de sesión, la compatibilidad con idiomas, el audio, los códigos QR, las rutas, la accesibilidad, las herramientas de análisis, las notificaciones y la aplicación del personal. La disponibilidad de estas funcionalidades depende de la solución y del plan elegidos, por lo que hay que comprobarlas en la oferta correspondiente. El lugar invierte, ante todo, en sus contenidos y en el desarrollo de la visita.

Cuando el sistema se adapta a una nueva versión de teléfono o recibe una mejora de accesibilidad, todos los lugares se benefician. El coste del producto se reparte entre muchos clientes, en lugar de generar una factura independiente para cada institución. Este modelo se parece a una infraestructura de exposición compartida: el marco puede ser estándar, pero el cuadro sigue siendo tuyo.

La plataforma también crea un efecto de red. Un usuario que la descubrió en un museo al aire libre puede encontrar después el mismo perfil y el mismo funcionamiento en un jardín botánico, un castillo o una ruta urbana. Para cada lugar, esto reduce la dificultad de adopción; para el visitante, hace que la experiencia sea más predecible.

La contrapartida es una menor libertad para diseñar funcionalidades totalmente atípicas. A cambio, el equipo no tiene que gestionar su propio ciclo de versiones, su infraestructura ni la compatibilidad con cada nuevo dispositivo. Para muchos lugares pequeños y medianos, este equilibrio es sencillamente más razonable desde el punto de vista económico.

La decisión más segura se basa en el uso real, no en una presentación en una sala de reuniones. Live Story permite publicar un perfil público, unos pocos puntos esenciales o una decena, así como una ruta, sin iniciar un proyecto informático independiente. El plan Community o Lite puede servir como un verdadero proyecto piloto.

Después de unas semanas o unos meses, el lugar sabe más: qué códigos se escanean, si los visitantes escuchan los contenidos de audio, qué idiomas eligen, dónde interrumpen la ruta y qué preguntas hacen al personal. También es posible comprobar si el equipo dispone del tiempo y de los recursos necesarios para ampliar los contenidos con regularidad. Esto es importante, porque ni siquiera la mejor aplicación puede redactar un buen relato en nombre de una institución sin fuentes ni decisiones editoriales.

Si las funcionalidades existentes resuelven el problema, se puede pasar a un plan superior y añadir rutas, accesos, grupos o funciones de comunicación. Si el proyecto piloto revela una necesidad realmente única, los datos de la prueba permiten definir mejor el encargo de una aplicación propia.

Una aplicación propia no es una mala idea. Puede ser la mejor solución para una gran institución o una red con procesos únicos, una marca fuerte, numerosos usuarios habituales y un equipo capaz de hacer evolucionar el producto durante años. Puede ser necesaria para equipos especializados, funcionalidades avanzadas de realidad aumentada, necesidades atípicas de localización dentro de edificios o integraciones que la plataforma no admite.

Sin embargo, hay que disponer de un presupuesto que cubra algo más que el lanzamiento. La institución necesita un responsable de producto, un proceso de creación y validación de contenidos, una responsabilidad claramente definida sobre los datos, un plan de soporte y recursos para las versiones posteriores. Sin ello, una aplicación propia puede convertirse rápidamente en una sala digital cerrada por obras.

Si la mayoría de las necesidades se refieren a descripciones, audio, idiomas, códigos QR, rutas, cuestionarios, accesos y contacto después de la visita, una plataforma compartida suele permitir alcanzar el objetivo más rápido y con un menor coste. Además, la elección no tiene por qué ser definitiva. Un proyecto piloto en Live Story puede confirmar el interés de un plan superior o aportar argumentos a favor del desarrollo de un producto independiente.