Desarrollo de una app móvil para empresas, paso a paso

El descubrimiento aclara qué problema debe resolver la app. ¿Quién es el usuario, cuándo y por qué la abrirá, y por qué no puede cubrir esa necesidad un sitio móvil o una herramienta existente? Un proyecto que arranca sin respuestas honestas suele acabar en una app que nadie abre una vez publicada.

En esta fase también se mapean los sistemas existentes: ¿dónde están los datos de los usuarios, con qué sistema interno debe hablar la app, la aprobación de quién hace falta? Piense en una app de socios y reservas para un grupo de spas. Si la información de reservas está en un programa distinto en cada sede, el verdadero trabajo de la app es hablar de forma segura con ese programa. El número y la naturaleza de estas conexiones condicionan cada paso posterior.

El alcance es la lista escrita de funciones de la primera versión. El error más común es intentar meterlo todo. El enfoque más sano es lanzar la versión más pequeña que complete la tarea principal del usuario y ordenar el resto según datos de uso reales.

Al escribir el alcance, las funciones se reparten en tres grupos: imprescindibles, deseables y para más adelante. Si esa división no queda por escrito, cada petición añadida por el camino amplía el alcance sin que nadie lo note. La ampliación gradual del alcance es la razón más habitual de que los proyectos se retrasen.

• Escribir la tarea principal del usuario en una frase
• Marcar cada función como imprescindible, deseable o para más adelante
• Enumerar los sistemas internos y proveedores con los que se conectará la app
• Decidir de antemano cómo se solicita un cambio de alcance

El diseño no es solo apariencia. Es construir el flujo. ¿Por qué pantallas pasa el usuario para terminar una tarea, qué ve cuando algo falla, qué ocurre cuando se pierde la conexión? Estas preguntas se prueban en un prototipo en el que se puede hacer clic antes de escribir una línea de código, porque cambiar un flujo sobre el papel es mucho más barato que cambiarlo en el código.

El prototipo se enseña a unos pocos usuarios reales. Las personas de dentro de la organización conocen el flujo y no se desvían de él. Lo que hay que aprender es dónde duda alguien que ve el producto por primera vez. Aquí también se considera la accesibilidad: un tamaño de texto legible, contraste suficiente y zonas de toque cómodas no son detalles que añadir después.

El desarrollo se organiza en periodos cortos y al final de cada uno se muestra una pieza que funciona. Así las sorpresas llegan pronto y no tarde. Las pruebas tampoco son una fase que se deja para el final. Acompañan al desarrollo: comprobaciones automáticas, ensayos en dispositivos reales y una mirada a distintos tamaños de pantalla.

En las apps empresariales, las pruebas importan sobre todo para las conexiones. Aunque un enlace de pago, de notificaciones o de un sistema interno funcione bien, hay que ver qué ocurre con una red lenta o durante una caída. Si el equipo de campo de un fabricante de suelos usa la app sobre todo in situ con poca señal, el comportamiento sin conexión es el corazón del producto.

La prueba de aceptación se hace con el propio equipo de la empresa. Quienes conocen el flujo de trabajo real encuentran huecos que el equipo técnico no puede ver. Si se recorta el tiempo dedicado a este paso, los fallos se descubren después de que la app llegue a la tienda.

Enviar la app a la tienda es una fase con su propio proceso de revisión, cuyos plazos no se pueden prever con exactitud. Por eso la fecha de lanzamiento se planifica dejando margen para la revisión. Las normas de las tiendas y las declaraciones de privacidad también se preparan antes de publicar, ya que una declaración que falte puede llevar al rechazo de la app.

La publicación es el comienzo del trabajo, no su final. En el primer periodo se vigilan los informes de cierres inesperados, las opiniones de los usuarios y los datos básicos de uso. La app sigue viviendo con las actualizaciones del sistema operativo, la renovación de bibliotecas y las funciones nuevas. Si el plan de mantenimiento no se habla antes de publicar, la app envejece en silencio.

El primer error es saltarse el descubrimiento e ir directo al diseño. Un proyecto que no conoce el problema construye un producto bonito pero innecesario. El segundo es incorporar tarde a quienes toman las decisiones. Una objeción de la dirección en mitad del desarrollo es el cambio más caro que existe.

El tercer error es centrarse solo en la fecha de lanzamiento y no planificar el mantenimiento. El cuarto es avanzar sobre suposiciones sin hablar nunca con usuarios. El quinto es construir una estructura que depende de una sola persona. El código, las credenciales de acceso y las cuentas de las tiendas deben estar siempre a nombre de la propia organización.

No toda necesidad exige una app. Cuando los usuarios leen información de vez en cuando y no necesitan funciones del dispositivo como la cámara o las notificaciones, suele bastar un sitio móvil o una aplicación web bien hechos. Y si no está seguro de con qué frecuencia volverán los usuarios a su producto, lo sensato es hacer primero una pequeña prueba.

El criterio: ¿realiza el usuario esta tarea una y otra vez y aportan valor las funciones del dispositivo? Si ambas respuestas son sí, una app tiene sentido. Si no, la inversión estará mejor empleada en otro canal. Para ver cómo se comporta su sitio actual en el móvil, nuestro test de velocidad web le da gratis una primera impresión.