Empieza por un recorrido real
Imagina una empresa de reparaciones en Budapest. Un cliente nuevo necesita entender el servicio, enviar fotografías y solicitar una cita. El técnico necesita consultar sus trabajos, registrar lo que ha hecho y continuar cuando falla la conexión. Son recorridos distintos. Escribe por separado sus pasos, la información necesaria y las posibles dificultades. Que ambos pertenezcan al mismo negocio no significa que necesiten la misma interfaz. Comprueba estas ideas con las personas que realizan las tareas, antes de convertirlas en una lista de pantallas.
Considera la web para el primer contacto
Una web o aplicación web es una buena candidata cuando el cliente llega mediante una búsqueda o un enlace compartido y quiere resolver una tarea ocasional. MDN explica el acceso mediante direcciones web y la posibilidad de aplicaciones web progresivas instalables. En el ejemplo de reparaciones, empieza con páginas de servicios claras y una solicitud breve. Haz que ese recorrido funcione bien en el teléfono antes de añadir cuentas, paneles o programas de fidelización cuya necesidad todavía no está demostrada.
Comprueba el motivo para crear una aplicación móvil
Una aplicación móvil merece atención cuando resuelve una necesidad concreta que se repite en el teléfono. Pide al técnico que describa un día normal: qué información debe permanecer disponible, cuándo añade fotografías y qué ocurre después de una interrupción. Prueba el comportamiento más dependiente del dispositivo en los teléfonos que utiliza realmente tu público. La instalación, los permisos, el inicio de sesión y la recuperación de un trabajo pendiente forman parte del producto. No son detalles que deban dejarse para después del lanzamiento.
Construye ambas cuando los recorridos lo justifiquen
Una web pública y una aplicación móvil pueden atender a personas distintas y compartir las mismas reglas de negocio. En nuestro ejemplo, el cliente envía la solicitud desde la web y el técnico gestiona el trabajo aceptado desde el móvil. Define qué significan solicitud, cita y trabajo terminado antes de conectar las interfaces. La guía de arquitectura de Android recomienda separar responsabilidades. Aplica esa disciplina al producto: asigna responsables para los datos, los errores y los cambios, de modo que las dos experiencias no se distancien con el tiempo.
Planifica los idiomas y el mantenimiento
Una empresa húngara que atiende a clientes europeos puede empezar por los idiomas que sea capaz de mantener correctamente. Revisa el recorrido completo en cada uno, incluidos los mensajes de confirmación, los estados vacíos y los datos de contacto. Deja espacio para etiquetas más largas. Decide quién atenderá el soporte, actualizará los contenidos y preparará las siguientes versiones. Elegir una plataforma también implica trabajo continuo: documenta qué dispositivos, navegadores y tareas deben seguir funcionando después de cada cambio importante.
Prepara un encargo que se pueda comprobar
Antes de pedir una estimación, entrega al equipo un público principal, un recorrido completo y una lista corta de restricciones reales. Separa el comportamiento imprescindible de los extras atractivos. Acordad cómo decidiréis si la primera versión está lista y qué queréis aprender cuando la utilicen personas reales. La siguiente plataforma debería responder a una necesidad que aún no esté resuelta. Que un competidor tenga una aplicación no justifica, por sí solo, añadir otro producto al trabajo de tu empresa.
- Identifica la tarea y a la persona que la realiza.
- Anota los dispositivos, idiomas y condiciones de conexión relevantes.
- Describe con claridad el éxito, las interrupciones y los fallos.
- Elige una primera versión pequeña, un responsable y un momento de revisión.