Si tienes un taller de cocinas a medida y tus clientes te preguntan qué plano deben aprobar o cuándo será la instalación, empieza por distinguir dos situaciones. Si solo necesitan enterarse de un avance y tu equipo puede avisar a tiempo, un mensaje claro puede bastar. Si varias personas necesitan consultar el mismo plano vigente o dejar una aprobación que autoriza al taller a fabricar, conviene diseñar un lugar común donde se vea qué cambió y a quién le toca actuar. Si el taller corta una pieza con el plano anterior, puede tener que repetir el trabajo.
La primera pantalla puede resolver tres preguntas. ¿Qué pasó? ¿Quién tiene el siguiente paso? ¿Qué puede hacer el cliente aquí? Empieza con una etapa, por ejemplo la aprobación del plano. Así puedes probar si el recorrido funciona antes de llevar al portal todas las etapas del proyecto.
Imagen de portada generada con IA. Una escena ficticia muestra cómo se comparan un plano impreso y una versión en tableta durante una instalación.
Elige cuánto debe resolver la primera versión
- Mensaje en un momento acordado. Úsalo si hay pocas novedades y el cliente solo necesita enterarse. Por ejemplo, alguien del taller confirma la visita cuando ya acordó el horario con el instalador.
- Vista de consulta. Tiene sentido si el cliente vuelve a buscar el plano vigente o una fecha y tu equipo puede mantener esa información al día. Muestra quién actualizó el dato o cuándo se confirmó si eso ayuda al cliente a saber si sigue vigente.
- Flujo de aprobación. Considéralo si la respuesta del cliente determina qué puede hacer el taller. Quien aprueba debe ver la versión que está revisando. Quien fabrica necesita poder comprobar cuál se aprobó antes de usarla.
Una pantalla que se actualiza sola ahorra captura si ya existe una fuente confiable de datos. Si la fecha vive en conversaciones y nadie tiene la última palabra, primero asigna quién la confirma. Puedes empezar con una actualización manual a cargo de esa persona y evaluar la integración cuando el proceso sea estable.
Qué cambia cuando el cliente pide un ajuste
Imagina un taller que publica el plano v2 de una cocina. La vista dice «Te toca decidir» y ofrece «Revisar plano». Al abrirlo, el cliente puede aprobar esa versión o explicar qué quiere cambiar. En este ejemplo pide mover un cajón. Cuando el sistema guarda el comentario, la vista confirma que llegó y cambia a «El taller revisa». La siguiente decisión del cliente llega cuando el taller publica el plano v3.
Define qué evento cambia cada estado antes de diseñar la pantalla. En el ejemplo, una aprobación queda vinculada a la versión que el cliente vio. Si el taller publica una versión nueva que requiere otra aprobación, el equipo puede consultar la anterior en el historial y debe confirmar cuál autoriza la fabricación. Haz lo mismo con la fecha de instalación. Si falta confirmación, muestra «Por confirmar» y quién se encarga de dar el aviso.
Si el portal reúne varias tareas, empieza con pocos estados y reserva las acciones para lo que el cliente ya puede hacer. El sistema de diseño del gobierno británico distingue las tareas disponibles de las que dependen de otro paso. Guía para diseñar listas de tareas.
Qué pedir y cómo probarlo
Dibuja la pantalla con un proyecto ficticio y pídele a alguien de tu equipo que haga de cliente. Dale una instrucción concreta, como «Pide que muevan el cajón y dime quién tiene el siguiente paso». Observa si encuentra el plano vigente, entiende que su comentario se recibió y sabe cuándo le toca volver. Después simula que alguien abre el enlace del plano v2 cuando el v3 ya está disponible. Comprueba que la vista indica cuál es el vigente y que el taller puede distinguir lo pendiente de lo aprobado.
Si la confirmación del envío aparece en la misma pantalla sin mover el foco, el criterio 4.1.3 de las pautas de accesibilidad web pide que la tecnología de asistencia pueda anunciar ese mensaje. Incluye una prueba con lector de pantalla y verifica que la confirmación se anuncie una vez que se guardó el comentario. Guía del W3C sobre mensajes de estado.
Si necesitas coordinar estados, accesos y sistemas, el trabajo de diseño de experiencia e interfaz (UX/UI) puede empezar con un mapa de tareas, responsables y reglas de aprobación, seguido de un prototipo que se pueda probar en el celular. Comparte un ejemplo sin datos personales, explica dónde guardas los planos y señala quién confirma cada paso. Pide que la propuesta separe el prototipo, la implementación de la interfaz y la conexión con el sistema que guarda archivos y aprobaciones. El alcance publicado de Branding Bull incluye este tipo de trabajo de diseño de portales y documenta apoyo a la experiencia de portal y móvil de Redtail. Web y aplicaciones móviles de Branding Bull.
Si estás evaluando un portal, puedes compartir con Branding Bull una muestra anonimizada de cómo aprueban un plano hoy. Con eso podemos conversar sobre qué conviene probar primero y qué sistema tendría que alimentar esa pantalla.
